Todo agente de IA tiene tres identidades. Los peores fallos ocurren en la que nadie nombró
Su nombre, la persona para la que actúa y el rol de nube con el que corre responden a preguntas distintas. Google, Databricks y Zenity muestran por qué cada una necesita un responsable.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
Esta semana, la industria dio a los agentes de IA direcciones de correo, identidades con atestación criptográfica y registros de auditoría escritos bajo su propio nombre. En la misma semana, unos investigadores mostraron cómo un conjunto de agentes podía quedar expuesto sin tocar nada de eso. Lo que importaba era el rol que el runtime del agente tenía en la nube por debajo.
Esas dos historias no están en tensión. Tratan de identidades distintas, y la confusión entre ellas es, a nuestro juicio, la brecha de diseño más común en los programas de agentes empresariales hoy. La “identidad del agente” no es una sola cosa. Todo agente en producción tiene al menos tres, cada una responde a una pregunta diferente, normalmente la emite un equipo distinto y falla de una manera distinta.
Las tres
El principal propio del agente: ¿qué agente actuó? Este es el nombre del agente en el directorio y en el registro de auditoría. Los agentes colaboradores de Google, descritos en Gemini at Work, son el ejemplo más claro hasta ahora: cada uno recibe una identidad “gobernada como la de un empleado”, y cada acción se “atribuye al agente y no a una persona”. Vimos qué significa eso para contratar y dar de baja agentes. Esta identidad hace que los agentes rindan cuentas como objetos. Suele fallar cuando varios agentes comparten un nombre, o cuando un agente tiene nombre y ningún patrocinador.
La autoridad delegada: ¿tenía permiso esta persona? Cuando un agente actúa en nombre de alguien, lleva sus permisos. Los Genie Agents de Databricks son el caso modelo: “cada llamada a una herramienta se ejecuta con los permisos del usuario que hace la pregunta”, como cubrimos en el diseño de identidad de Databricks. La delegación garantiza que el agente no puede exceder a la persona. Falla por ser demasiado generosa: el agente hereda todo el alcance del usuario para una tarea que necesita una porción mínima.
La identidad de carga de trabajo: ¿qué puede alcanzar el runtime si el agente queda subvertido? Bajo todo agente gestionado hay cómputo, y el cómputo se ejecuta con un rol de nube o una cuenta de servicio. La investigación de Zenity Labs sobre AgentCore, que analizamos en nuestro artículo sobre el rol de ejecución, trata solo de esta identidad: según los investigadores, un rol predeterminado que abarcaba toda la región permitió que un agente comprometido alcanzara a otros agentes y su memoria. Esta identidad falla en silencio, porque la crean las plantillas de despliegue, vive en el IAM de la nube y no en el inventario de IA, y nunca aparece en el registro de auditoría del agente como “el agente”.
| Identidad | Responde a | Normalmente la emite | Fallo típico | Prueba |
|---|---|---|---|---|
| Principal del agente | ¿Qué agente actuó? | La plataforma de agentes o el directorio | Nombres compartidos, sin patrocinador | ¿Puede listar las acciones de un agente y nombrar a su patrocinador? |
| Autoridad delegada del usuario | ¿Tenía permiso esta persona? | El usuario, mediante el consentimiento de OAuth | El agente lleva todo el alcance del usuario | ¿Puede acotarlo a la tarea? |
| Identidad de carga de trabajo | ¿Qué puede alcanzar el runtime si se subvierte? | Una plantilla de despliegue | Un rol amplio compartido por muchos agentes | Si este agente quedara totalmente comprometido, ¿qué más cae? |
Por qué se pasa por alto la tercera
Los equipos de gobernanza de agentes revisan prompts, herramientas y acceso a datos. Los equipos de seguridad de la nube revisan roles. En una organización típica, ninguno de los dos revisa el rol de carga de trabajo a la luz de lo que un prompt podría hacer que el agente hiciera con él. El principal del agente aparece en el inventario de IA; la autoridad delegada aparece en las pantallas de consentimiento; la identidad de carga de trabajo no aparece en ningún sitio donde mire el programa de IA.
Por eso añadiríamos una regla a la autoridad de identidad en nuestro modelo de seis autoridades para la gobernanza de agentes de IA: la identidad de carga de trabajo solo debería alcanzar los recursos de su propio agente. Su runtime, su memoria, sus logs, su acceso al modelo. Todo lo demás debería alcanzarse a través del principal del agente o de la autoridad delegada, en una llamada autorizada y registrada. Un rol de carga de trabajo que puede alcanzar a un vecino es una ruta lateral esperando una inyección. Esta es nuestra visión de diseño, no un requisito de un proveedor.
Donde se encuentran las tres: el registro de auditoría
Cada acción que emprende un agente debería registrarse con las tres: qué agente, en nombre de quién, bajo qué rol de carga de trabajo. La decisión de Google de atribuir las acciones al agente y no a una persona es acertada, siempre que sobreviva el campo on-behalf-of. Sin él, la rendición de cuentas pierde a la persona que fijó el objetivo. Sin el rol de carga de trabajo, una investigación no puede saber si el agente actuó por su ruta prevista o a través de una credencial que nunca debería haber tenido.
Nuestra expectativa, y es una opinión más que un hecho: dentro de un año, los cuestionarios de seguridad para plataformas de agentes pedirán estas tres por separado, igual que ahora preguntan por separado por SSO, cuentas de servicio y claves de API. Los equipos que ya puedan responder a las tres pruebas de la tabla pasarán ese año lanzando en vez de explicando.