Problema
En productos colaborativos, la interfaz suele ocultar acciones que un rol no puede usar. Con agentes, esa protección es insuficiente: la acción también puede llegar por API, evento, reintento o herramienta directa.
Un invitado no ve “eliminar sala”, pero un agente que actúa en su nombre descubre el comando en el schema de una herramienta. Si el backend confía en que la UI ya filtró la acción, la colaboración tiene dos sistemas de permisos: el que las personas ven y el que las máquinas pueden explotar.
Tesis
La política visible y la política efectiva deben ser la misma. La UI explica el permiso; el runtime lo impone. Si divergen, el agente descubre una capacidad que el usuario nunca vio.
La distinción clave: ocultar una acción mejora la experiencia; denegarla en el punto de efecto protege el sistema. Son responsabilidades distintas.
Framework
Buzz, el workspace self-hosted de Block para humanos y agentes, usa habitaciones, identidades criptográficas y un registro firmado de eventos. Sus issues públicos muestran un reto universal: mantener permisos coherentes entre controles visibles y ejecución real.
La decisión de autorización debe combinar sujeto, recurso, acción y estado. Un agente puede pertenecer a una sala, pero no moderarla; puede redactar una respuesta, pero no publicarla tras perder membresía. Evaluar el permiso al iniciar la tarea no basta si la ejecución dura minutos.
Por eso el log debe registrar qué política se evaluó y con qué atributos. “403” demuestra que algo fue negado; no permite explicar por qué.
Señal medible: número de acciones cuya autorización solo existe en frontend.
Por que importa ahora
Los agentes participan en los mismos espacios que las personas y operan por caminos distintos a la UI. El control debe evaluarse en cada comando, con identidad, membresía, rol y estado actuales.
Esta coherencia también protege producto. Cuando API y UI aplican reglas distintas, los usuarios encuentran conductas imposibles de explicar y soporte termina tratando incidentes de autorización como errores intermitentes.
Anti-ejemplo
“El botón no aparece para invitados.” Un agente no necesita pulsar el botón si la ruta o herramienta todavía acepta la orden.
Tampoco sirve confiar en instrucciones como “no uses esta herramienta salvo que seas admin”. El modelo puede equivocarse; el runtime conoce el rol y debe hacer cumplir la regla.
Protocolo (3 pasos)
- Modela capacidades. Define acciones por rol y recurso.
- Impón en backend. Autoriza cada operación en el punto de efecto.
- Prueba divergencias. Ejecuta la misma acción desde UI, API y agente.
Incluye cambios de estado durante la prueba: revoca la membresía entre planificación y ejecución. Un sistema seguro vuelve a autorizar en el momento del efecto.
| Superficie | Función | Regla |
|---|---|---|
| UI | comunicar permiso | nunca autoriza sola |
| runtime | permitir o negar | fuente de verdad |
| log | demostrar decisión | identidad y motivo |
Relacionado
- Agent Identity: el pasaporte operativo que separa agente útil de riesgo invisible
- Safe Outputs: agentes útiles sin permiso de escritura
Fuentes consultadas
Proximo paso
Selecciona cinco acciones con efecto real y ejecútalas desde todas las superficies disponibles. Cualquier diferencia de autorización es deuda crítica, no un bug visual.