Cuando una organización conecta su primer agente a herramientas reales —abrir tickets, consultar el CRM, mover archivos, enviar correo— casi siempre resuelve la autenticación de la forma más rápida disponible: el agente actúa con las credenciales de la persona que lo invocó. Es cómodo, funciona en la demo y no obliga a tocar el modelo de identidad que ya existe. También es el error de diseño más común que encontramos, y el más caro de revertir cuando el agente ya está en producción.
Lo incómodo es que no hay vulnerabilidad que parchear: el sistema hace exactamente lo que se le pidió. Nadie decidió de forma explícita cuánta autoridad tiene el agente. La heredó, y con ella heredó el techo de daño del usuario más privilegiado que alguna vez lo use.
Por qué la herencia de permisos rompe el modelo
En una aplicación tradicional, el código que corre bajo la sesión de un usuario está acotado por el propio código: este botón llama a este endpoint, que hace esta consulta. Los permisos limitan el alcance, pero la lógica limita el camino. Un agente no tiene esa segunda barrera. Decide qué herramienta invocar y con qué parámetros a partir de texto, y parte de ese texto proviene de fuentes que tu organización no controla: un documento recuperado, la respuesta de una API, el cuerpo de un correo.
Al juntar ambas cosas —autoridad completa del usuario y decisión no determinista influida por entrada externa— el resultado es previsible. Ya lo planteamos al hablar de inyección de prompts: el control efectivo no está en evitar que el modelo sea engañado, sino en limitar qué ocurre cuando lo engañen. Los permisos son ese límite.
Tres consecuencias concretas de la herencia merecen nombrarse:
- El daño máximo escala con el usuario, no con la tarea. El mismo asistente que resume tickets tiene, cuando lo usa un administrador, capacidad para borrar la cola completa. Nadie diseñó eso; simplemente ocurre el día que el administrador lo prueba.
- La trazabilidad se pierde justo cuando hace falta. Los registros de los sistemas de destino muestran que la acción la ejecutó la persona. No distinguen entre lo que ella escribió y lo que un agente decidió en su nombre, que es precisamente la pregunta a responder después de un incidente.
- No puedes revocar al agente sin revocar a la persona. Ante un comportamiento anómalo, la única palanca es cortar el acceso del usuario, así que en la práctica nadie corta nada hasta que el daño ya es evidente.
Un agente que hereda permisos no tiene modelo de permisos: tiene el de otro, aplicado a decisiones que ese otro no tomó.
Cómo se ve un diseño correcto
Identidad propia para cada agente
Cada agente debería existir como principal en tu directorio, con credenciales propias y ciclo de vida propio. No es un detalle formal: es lo que permite auditar, aplicar política y revocar por agente. La pregunta de control es simple: ¿puedes desactivar un agente esta tarde sin afectar a ninguna persona? Si la respuesta es no, todavía no hay identidad propia.
Permisos por tarea, no por rol
El rol es una abstracción pensada para personas, que hacen muchas cosas distintas a lo largo del día. Un agente hace pocas cosas y casi siempre las mismas. Eso habilita algo que con humanos resulta impracticable: enumerar las operaciones concretas que necesita —lectura de estos campos, escritura solo en este estado, nada más— y negar el resto por defecto. Cuando el catálogo de herramientas del agente crece, el permiso no debería crecer con él de forma automática; cada herramienta nueva es una decisión de autorización que alguien firma.
Credenciales acotadas en el tiempo
Las claves de larga duración incrustadas en la configuración del agente son el equivalente moderno de la contraseña compartida. El patrón razonable es emitir credenciales de corta vida por ejecución, ligadas a la tarea que las justifica y a la identidad de quien la originó. Si una de esas credenciales se filtra en un log, en una traza o en la memoria del agente, la ventana de abuso se mide en minutos y no en meses.
La intersección, no la suma
Un matiz que suele saltarse: dar identidad propia al agente no significa desentenderse del usuario. El permiso efectivo de cada acción debería ser la intersección de dos conjuntos: lo que el agente tiene autorizado hacer por diseño, y lo que la persona que originó la tarea podría hacer por sí misma. Si el agente puede consultar toda la base de clientes pero quien pregunta solo tiene acceso a su cartera, la respuesta debe limitarse a esa cartera. Es el mismo principio que sostiene un RAG con control de acceso real.
Sin esa intersección aparece la falla opuesta a la herencia: un agente sobreautorizado que responde a cualquiera con la información de todos.
Qué revisar antes de aprobar un agente nuevo
Cuatro preguntas ordenan la mayoría de las conversaciones de aprobación. Primero, qué herramientas puede invocar y cuáles producen efectos irreversibles: enviar, publicar, pagar, borrar, cambiar permisos. Segundo, con qué identidad se autentica en cada sistema y cuánto duran esas credenciales. Tercero, qué acciones exigen confirmación humana fuera del canal del modelo, porque el agente no puede ser a la vez quien pide y quien aprueba. Y cuarto, qué queda registrado: la pregunta y la respuesta no bastan, hace falta la herramienta invocada, los parámetros y el resultado para poder reconstruir la cadena completa.
Ninguna de estas medidas exige tecnología nueva. Es control de accesos aplicado a un sujeto que no es una persona ni es un servicio determinista, y que por eso no encaja del todo en las categorías del directorio. La tentación es aplazar esa incomodidad y dejar que el agente use la sesión de quien lo llama. Conviene resolverla temprano, mientras el agente hace una sola cosa y su lista de herramientas cabe en media página. Más adelante el trabajo es idéntico, pero con doce agentes en producción y sin nadie que recuerde quién autorizó cada integración.