No oculte un agente autónomo detrás de las credenciales de una persona o de una cuenta de servicio compartida. Dé al agente desplegado una identidad propia, un patrocinador responsable, delegación acotada, acceso con una vigencia adecuada y breve, trazabilidad útil de sus acciones y controles de ciclo de vida. De lo contrario, la empresa puede saber que «algo» actuó sin poder explicar qué agente fue, bajo la autoridad de quién ni con qué permisos.
Autenticación y autorización siguen siendo funciones distintas, pero los agentes hacen más difícil ver su relación. El sistema debe autenticar la carga de trabajo, conservar cuando corresponda el contexto delegado de la persona o el servicio, autorizar la acción concreta sobre una herramienta y registrar contexto suficiente para investigarla después.
Este diseño de identidad se desprende del problema de descubrir agentes en la sombra, del cambio de modelo operativo que introduce la IA agéntica y de los niveles de escalado del gobierno mínimo viable de IA.
La brecha de responsabilidad en la automatización
Delegar autoridad en el software no equivale a delegar la responsabilidad. En un proceso humano, un responsable normalmente puede identificar quién aprobó una tarea y quién la ejecutó. En un proceso agéntico, esa cadena debe estar incorporada de forma deliberada en las identidades, el patrocinio, las aprobaciones y los registros.
Un agente puede ejecutar una operación financiera, modificar código en producción o acceder a datos personales sensibles. Los anuncios de Microsoft Entra de noviembre de 2025 son una señal del mercado: las identidades de los agentes ya necesitan un tratamiento de primer nivel para el acceso y el ciclo de vida. La pregunta útil de diseño no es si los agentes sustituyen los principios existentes de Zero Trust, sino cómo se aplican esos principios a una carga de trabajo capaz de elegir herramientas y acciones durante la ejecución.
Si un agente opera bajo una cuenta de servicio genérica, puede resultar imposible distinguirlo de otras automatizaciones durante una investigación. Si utiliza directamente las credenciales de una persona, el registro puede dar a entender, de forma incorrecta, que esa persona ejecutó cada acción. El patrocinador no aprueba todas las decisiones que el agente toma en tiempo de ejecución, pero sí responde de su propósito, sus límites y su derecho a seguir operando.
La identidad como nuevo perímetro
La identidad es uno de los principales planos de control para los agentes que operan a través de distintas API y entornos. El Top 10 de OWASP para aplicaciones agénticas incluye entre sus riesgos publicados el abuso de identidades y privilegios. Por eso conviene diseñar antes de llegar a producción la relación entre la identidad del agente, la autoridad delegada, los permisos sobre herramientas y el ciclo de vida.
Piense en el ciclo de vida de una acción del agente. Comienza con la autenticación: el sistema demuestra qué carga de trabajo está actuando y, cuando procede, en nombre de quién. Prefiera credenciales cuya vigencia y alcance correspondan a la tarea. Los secretos de larga duración aumentan la persistencia tras un compromiso; una vigencia extremadamente corta puede causar problemas de fiabilidad y recuperación. La decisión adecuada depende de la acción y de la plataforma de identidad.
Aquí existe una tensión entre rendimiento y seguridad. Los tokens de corta duración añaden trabajo, pero los de larga duración añaden riesgo. La respuesta consiste en integrar comprobaciones de identidad en cada invocación de una herramienta. Cada vez que un agente llama a una API externa o accede a una base de datos, debe demostrar el alcance específico de su autorización. Así, el perímetro deja de ser una frontera estática y se convierte en un proceso dinámico de verificación que crece con la complejidad de las operaciones del agente.
Delegación acotada y mínimo privilegio
El segundo pilar es la delegación acotada. Un agente solo debería recibir los privilegios necesarios para su tarea, durante el tiempo y en el contexto requeridos. Es el conocido equilibrio entre mínimo privilegio y utilidad, pero con más dinamismo porque el agente puede elegir herramientas y ordenar acciones mientras se ejecuta.
Si un agente necesita leer datos de clientes y redactar informes, no necesita además permiso para eliminar cuentas o modificar registros de facturación. Evite copiar todo el conjunto de permisos del usuario patrocinador en una credencial de agente de larga duración. Es preferible delegar de forma explícita y temporal, con comprobaciones de autorización que tengan en cuenta el recurso, la acción, el patrocinador y el contexto del flujo de trabajo.
Trate a los agentes como cargas de trabajo con sus propias políticas de acceso. El control de acceso basado en roles (RBAC) puede seguir siendo útil, mientras que los atributos, el contexto del recurso, el riesgo de la acción y el contexto delegado del usuario permiten autorizar con mayor precisión. No autorice a partir de la intención que el propio modelo declara: contraste con la política la operación concreta que solicita a la herramienta.
Trazabilidad y procedencia de las acciones
Además de autenticar y autorizar, necesitamos entender qué ocurrió después de tomar la decisión. Ahí entra la trazabilidad de las acciones. Esta enlaza la entrada de un agente con su salida y crea una traza auditable que responde: ¿quién inició esto?, ¿qué datos se utilizaron? y ¿por qué se hizo?
Los registros suelen estar fragmentados entre el gateway del modelo, el orquestador, el proveedor de identidad, la herramienta y el sistema de destino. Para investigar hace falta un identificador de correlación y contexto suficiente que permita conectar esos registros. Reconstruir el razonamiento privado de un modelo no siempre es posible, ni es el objetivo. Lo que interesa es reconstruir la instrucción, la identidad, la autorización, la solicitud a la herramienta, el resultado y el cambio de estado posterior.
Registre la fecha y hora, la identidad del agente, el patrocinador o servicio responsable, la instrucción inicial o la referencia del flujo de trabajo, el contexto delegado, la decisión de autorización, la acción de la herramienta, el destino y el resultado. Proteja en el registro el contenido sensible de prompts y datos en lugar de copiarlo sin criterio. La revocación puede impedir accesos futuros, pero no deshace una acción irreversible; por eso la trazabilidad y la autoridad acotada deben ir juntas.
Seis pruebas para el diseño de identidades
Para evaluar si su organización está preparada para cargas de trabajo agénticas, aplique estas seis pruebas de diseño de identidad. Si no supera cualquiera de ellas, su enfoque actual no basta para sistemas autónomos.
- Prueba del principal diferenciado: ¿tiene cada agente una identidad única y separada de las personas y de otros agentes?
- Prueba del patrocinador responsable: ¿hay una persona o unidad organizativa claramente definida que responda por las acciones y los resultados del agente?
- Prueba de delegación acotada: ¿solo puede el agente acceder a los recursos estrictamente necesarios para completar su tarea?
- Prueba de acceso de corta duración: ¿coincide la vigencia de la credencial con la tarea y limita la persistencia tras un compromiso?
- Prueba de trazabilidad de las acciones: ¿pueden los investigadores correlacionar la instrucción, la identidad, la autorización, la acción de la herramienta y el cambio resultante?
- Prueba de control del ciclo de vida: ¿están definidos y se aplican la creación, los cambios de responsable, las revisiones de acceso, la suspensión y la retirada?
Estas pruebas convierten la «identidad de agente» de una etiqueta de producto en una capacidad operativa. Los equipos de identidad, los propietarios de aplicaciones, seguridad y auditoría necesitan un diseño común para emisión, delegación, correlación, revocación y pruebas. La automatización ayudará a escala, pero el modelo de políticas y responsabilidades debe entenderse antes de automatizarlo.
Empiece por el agente con mayor autoridad
Haga inventario de los agentes que pueden cambiar movimientos de dinero, producción, datos de clientes, identidades o decisiones reguladas. Elija el que tenga mayor radio de impacto y sométalo a las seis pruebas. Las carencias mostrarán si la siguiente inversión debe hacerse en la plataforma de identidad, el diseño del agente, el registro, la ruta de aprobación o el proceso de ciclo de vida.
Hágalo antes de contar agentes. Diez agentes bien acotados pueden ser más fáciles de gobernar que una única identidad de automatización compartida, con acceso amplio y sin patrocinador.
