Zero Trust para agentes de IA: ¿en nombre de quién actúa el agente?
Los agentes de IA ya llaman APIs, leen archivos y ejecutan acciones. La pregunta de identidad que hay debajo ya sabemos cómo responderla.
Un agente de IA agenda una reunión, consulta una base de datos y levanta un ticket. Tres sistemas recibieron tres solicitudes. Cada uno registró una identidad. La pregunta que vale la pena hacer es cuál identidad registraron, y si eso sirve de algo una semana después cuando alguien pregunte qué pasó.
En la mayoría de los despliegues tempranos la respuesta es una cuenta de servicio con una API key de larga vida, compartida entre todos los usuarios del agente. Eso no es un problema de IA. Es la misma cuenta de servicio sobreprivilegiada que llevamos quince años intentando eliminar, reintroducida porque el agente tenía que funcionar para el viernes.
Qué hace distintos a los agentes
Dos cosas, en realidad.
El agente actúa en nombre de alguien. Una persona solicita, el agente ejecuta. Si el sistema de destino solo ve al agente, se perdió la cadena de delegación, y con ella la posibilidad de exigir que el agente no haga algo que el usuario solicitante no podría hacer.
Las entradas del agente no son confiables de una forma en que las de un script no lo son. El contenido que el agente lee — una página web, un documento, un correo — puede contener instrucciones. Eso significa que el radio de impacto de una inyección de prompt es exactamente el conjunto de permisos que le otorgaste al agente.
Junta las dos cosas y el objetivo de diseño queda claro: el agente no debería tener privilegios propios permanentes.
Cómo se aplican los principios
Verificar de forma explícita. Cada acción del agente debería llevar una identidad que nombre tanto al agente como al usuario por el que actúa. Los flujos de token on-behalf-of ya existen en OAuth para esto. Conviene usarlos en lugar de inventar algo.
Mínimo privilegio, acotado por tarea. No “el agente puede leer el CRM”, sino “esta invocación puede leer estos registros, durante los próximos cinco minutos”. Los tokens de vida corta y alcance estrecho convierten una inyección de prompt en un incidente acotado en vez de uno abierto.
Asumir la brecha. Registra cada llamada a herramienta que haga el agente, con la cadena de delegación intacta. La pregunta de auditoría después de un incidente nunca es “¿se ejecutó el agente?”. Es “¿qué tocó, con autoridad de quién, y por qué la política lo permitió?”.
Lo que sigue sin resolverse
La aprobación humana para acciones de alto impacto es el control obvio, y funciona hasta que el volumen hace que la gente apruebe sin leer. Decidir qué acciones ameritan de verdad una persona, y diseñar la solicitud para que quien revisa pueda evaluarla, es más difícil que la plomería de los tokens.
No creo que la identidad de agentes sea una disciplina nueva. Creo que es IAM, con un solicitante al que se le puede convencer de cosas. Esa es la parte que nuestros modelos actuales todavía no contemplan.