Los agentes de IA son confused deputies. Es un patrón de seguridad de hace 38 años, y la respuesta es igual de antigua: pon un broker — una capa intermedia confiable, observable, determinista, auditable, infalsificable, de scope reducido, dirigida por políticas y no-IA — entre el agente y las SaaS APIs que necesita llamar; el broker guarda las credenciales que tu agente no debería tener.
En 1988, Norm Hardy publicó un artículo corto que describía un incidente real de su época en Tymshare. Un compilador Fortran llamado FORT vivía en un directorio del sistema llamado SYSX. Para recolectar estadísticas de uso, el compilador necesitaba escribir en (SYSX)STAT, así que el sistema operativo le había concedido a FORT una "home files license" que lo autorizaba a escribir cualquier archivo dentro de SYSX. El archivo de facturación del sistema, (SYSX)BILL, también vivía allí. Un usuario que invocara el compilador podía proporcionar un nombre de archivo para recibir la salida de depuración opcional. Un día, un usuario proporcionó (SYSX)BILL. El compilador pidió al SO que abriera ese archivo para escritura; el SO, observando la home files license, lo permitió. Los datos de facturación quedaron sobrescritos. El compilador hizo exactamente lo que estaba diseñado para hacer. El defecto era arquitectónico.
Hardy llamó a esto el problema confused deputy: un programa privilegiado (el deputy) tiene autoridad propia; un llamador menos privilegiado le pide que haga algo; el deputy se confunde sobre qué autoridad debería usar, y usa la suya. La solución es quitarle esa autoridad al deputy por completo y ponerla detrás de una capa separada que medie la llamada bajo demanda. Esa capa es el broker.
38 años después, cada agente de IA que tu empresa ejecuta es un confused deputy. Y la mayoría corre sin un broker.
Por qué los agentes de IA empeoran esto
El FORT de Hardy tenía un solo canal de entrada: la línea de comandos. Un agente de IA moderno tiene decenas: cuerpos de email, páginas web recuperadas, PDFs subidos, salidas de herramientas de servidores MCP, mensajes de agentes pares en sistemas multi-agente. Cualquier cosa que aterriza en la ventana de contexto puede emitir instrucciones, y por diseño el agente las trata todas como legítimas.
Eso rompe un supuesto del que depende el control de acceso tradicional: que el llamador controla la entrada. En una aplicación web, el llamador (la sesión autenticada) y la entrada (el cuerpo de la solicitud HTTP) vienen del mismo sitio. Para un agente, el llamador es quien sea que dé forma al prompt, lo que significa que un atacante que pueda escribir un email o manipular un resultado de búsqueda también es un llamador.
En noviembre de 2025, los investigadores de seguridad de PromptArmor demostraron cómo se ve esto en producción. Escondieron instrucciones maliciosas en fuente de 1 píxel dentro de una guía de integración. Cuando un desarrollador apuntó el IDE Antigravity de Google a esa guía, el agente eludió su propia protección de archivos basada en .gitignore ejecutando cat desde la terminal. Luego filtró el contenido de archivos .env a una URL webhook.site controlada por el atacante, vía el propio sub-agente de navegador de Antigravity. El usuario había configurado todo correctamente. La sandbox aguantó. El agente simplemente no podía distinguir lo que el usuario pedía de lo que la entrada le decía.
La misma forma que el FORT de Hardy, décadas después: autoridad amplia, entrada no confiable, ninguna manera de separar las dos.
La comunidad tiene respuestas. Solo están dispersas.
Esto no es un problema nuevo. La comunidad de seguridad lleva décadas escribiendo respuestas:
Capability-based security (Dennis & Van Horn, 1966; más tarde el lenguaje E y el trabajo de Mark Miller con Caja en Google). El principio: no concedas autoridad ambient basada en identidad o ubicación; pasa capabilities explícitas e infalsificables para cada recurso al que el programa puede tocar. Una capability une qué puedes hacer y con qué puedes hacerlo, y no se puede confundir con nada más.
Brokered Credentials (codificado en el OWASP LLM Top 10). No pongas tokens de API en el contexto del LLM. Una capa intermedia confiable hace la llamada en nombre del agente; el modelo decide qué hacer, el broker maneja el cómo. La prompt injection que pide al modelo imprimir sus credenciales no consigue nada útil. Las credenciales no están ahí.
El Phantom Token Pattern (Curity, originalmente para OAuth en microservicios). El agente sostiene un handle de sesión opaco, no el bearer token real. Un proxy valida el handle, lo intercambia por la credencial real en el borde de red y la reenvía río arriba. Si el agente filtra su entorno, el atacante recibe una cadena que caduca cuando termina la sesión.
Just-in-time credential injection (sistemas de workload identity como Aembit). Acuña una credencial de corta vida y scope reducido por llamada, en lugar de emitir tokens de larga duración.
Nada de esto falta en la literatura. Lo que falta son los defaults. La mayoría de las plataformas de agentes siguen entregando al modelo un OAuth token, sin broker en medio, y esperando lo mejor.
Cómo funciona el broker de Zero
No inventamos ninguno de los patrones anteriores. Los conectamos en un único broker que corre por defecto para cada agente en Zero. Es la capa intermedia confiable que esos patrones describen, construida para una plataforma de agentes de IA. Cada llamada que un agente hace a un connector pasa por él. Cada connector es una SaaS externa (Slack, GitHub, Notion y demás).
El broker se sitúa entre cada agente y cada connector. Las credenciales reales viven solo en el lado del broker de la línea discontinua.
Tres capas:
1. Aislamiento de credenciales
La sandbox del agente nunca sostiene una credencial real de un connector. Cuando conectas una SaaS a Zero, el OAuth token o la API key vive en el lado del broker. La sandbox recibe una cadena placeholder que se parece lo suficiente a un secreto de entorno para que las herramientas existentes sigan funcionando, pero que ningún SaaS upstream aceptaría.
Cuando el agente hace una solicitud a un host de connector registrado, el broker hace coincidir la solicitud, resuelve el template de auth del connector e inyecta la credencial real en el borde de red. La solicitud sale aguas arriba con auth válida; el agente nunca tuvo nada útil. Un agente comprometido por prompt injection que vuelque sus variables de entorno entrega al atacante un placeholder, no el token de SaaS.
Es el patrón Phantom Token, aplicado a los agentes de IA.
2. Connector policy gate
Un connector en Zero debería ser más que un interruptor on/off. Cada connector describe las API bases que cubre y cómo debe inyectarse la auth. Donde el servicio upstream publica un mapeo estable de scope a endpoint, el connector también puede describir qué permission nombrada cubre cada method y path. El slack-api-ref de Slack es un buen ejemplo.
Así, cuando un agente conectado a Slack llama a chat.postMessage, el broker puede mapear esa solicitud a chat:write. Cuando lee logs de auditoría, eso es admin.analytics:read. Por agente, permission_policies define cómo se comportan esas permissions nombradas: allow, deny o ask. La política se aplica en el broker antes de la inyección de auth, no como una pista para el modelo. Si el agente intenta hacer una llamada cubierta por una permission denegada, quizá porque fue prompt-injected, la llamada nunca alcanza la red upstream.
No todos los connectors logran esa resolución actualmente. Algunas APIs upstream no publican un mapeo estable de scope a endpoint. La API GraphQL de GitHub es el caso canónico: el lado REST se puede mapear, pero el lado GraphQL aún no. Para esos connectors, el broker sigue controlando la inyección de credencial y el camino de red, mientras el permission gate recae sobre la política más gruesa a nivel connector o host que la plataforma efectivamente puede hacer cumplir. Llenamos esos huecos a medida que los datos upstream se vuelven disponibles. No reclamamos cobertura que no hayamos construido.
Los tokens no llevan autoridad ambient. La autoridad la otorga el broker por agente, en la resolución más fina que el servicio upstream soporte. Esa es la mitad capability-based de la respuesta.
3. Loop operativo y auditoría
Least privilege solo funciona si el modo de fallo es usable. Los agentes crecen. Seis semanas después, un agente de research que empezó leyendo de Notion puede necesitar escribir un resumen de vuelta. Los modos de fallo comunes en otras plataformas: el agente corre en silencio sin la nueva permission y se rompe, o el operador concede demasiado por pánico y nunca recupera lo otorgado.
Una solicitud denegada de connector devuelve un 403 estructurado: connector, method, path, base URL y los nombres de permission cuando el broker puede identificarlos. El system prompt del agente le dice cómo diagnosticar la denegación y cómo pedir exactamente la permission que acaba de tocar, lo que produce una URL de grant de un solo clic para el usuario o admin. Eso mantiene el camino de escalación atado a la permission concreta solicitada, en vez de convertirse en "concédelo todo y ya".
Las solicitudes de cambio de permission se ponen en una cola. Owners y admins pueden aprobarlas o rechazarlas desde el dashboard; las aprobadas actualizan la política del agente, y el siguiente retry pasa. La mayoría de las plataformas se saltan este loop. Sin él, "least privilege" se queda en las diapositivas en vez de correr en producción.
El mismo camino del broker alimenta la auditoría. Los logs de red por-run registran la actividad de red de la sandbox: HTTP, TCP, DNS, además de observaciones de paquetes de bajo nivel para tráfico no-TCP. Las solicitudes matcheadas por connector incluyen metadatos estructurados de broker: connector, permission matcheada cuando esté disponible, resultado allow/deny, metadatos de resolución de auth y flag de billable. Si alguien luego pregunta "¿qué hizo este agente el martes a las 3pm?", reconstruyes la respuesta desde esos registros. La prevención deja pasar cosas. El registro de auditoría es cómo descubres qué pasó.
Lo que no hemos resuelto
Incluso con todo lo anterior, un agente con chat:write legítimo puede ser convencido de publicar un mensaje vergonzoso en un canal al que ya tiene acceso. El broker reduce el radio de daño; no lo elimina.
La otra mitad de la respuesta: aprobación de acciones de alto riesgo, validación de salida y tratamiento de los retornos de herramientas como no confiables por defecto. Ese trabajo está en el roadmap, no en el producto todavía. Quien diga que ha resuelto confused deputy de extremo a extremo te está vendiendo algo.
Esto debería ser la base, no una feature
Capability-based security existe desde los años 70. Brokered credentials están en el OWASP LLM Top 10. Los phantom tokens son anteriores a la era LLM. Nada de esto falta porque nadie supiera la respuesta. Falta porque las primeras plataformas de agentes optimizaron para "haz que la demo funcione" y empujaron la seguridad a una release posterior, que a menudo nunca llegó.
La próxima generación de plataformas debería apuntar más alto. Los tokens no deberían entrar al contexto del modelo. La autoridad debería enumerarse por agente. La escalación de privilegios debería pasar por un humano. Cada acción debería ser auditable de extremo a extremo. Nada de eso es novedad. Todo eso debería ser la base.
Cuando elijas una plataforma de agentes, "¿es segura?" no te lleva a ningún lado. Cada vendor dice que sí. Una mejor pregunta: muéstrame tu broker, y guíame por lo que pasa cuando un agente pide un scope que no tiene.
El broker está delante de cada agente en Zero por defecto. El inventario de connectors, los mapeos de scope, las permission policies y la lógica del broker viven en el repositorio fuente de Zero. ¿Falta un connector? Abre un issue.
Referencias
Fundamentos
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (el paper fundacional de los sistemas capability)
- Mark Miller et al., Caja: capability-based security para la web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Incidentes citados
- PromptArmor, Google Antigravity Exfiltrates Data, noviembre de 2025
- Simon Willison, análisis y cobertura, 25 de noviembre de 2025
