IAM para agentes de IA: el nuevo marco de identidad corporativa
Las organizaciones están empezando a tratar a los agentes de IA como identidades no humanas, con propietarios, propósito y expiración. El marco exige autenticación, autorización granular y auditoría en tiempo real.
¿Qué es el IAM para agentes de IA?
Los agentes de IA actúan dentro de sistemas empresariales con autoridad delegada. Cada agente se trata como una identidad no humana con propietario humano, propósito definido, autorización por tarea, expiración y monitoreo continuo. El problema surge cuando los sistemas IAM tradicionales solo definen la intención de acceso, no lo que realmente hace el agente.
Por qué fallan los IAM clásicos
Los IAM convencionales se centran en dos dimensiones: diseño y ejecución. En el diseño gestionan el ciclo de vida, las políticas y la provisión. En la ejecución, verifican autenticación y autorización a la frontera de la aplicación. Ambos describen el acceso configurado, pero no qué hizo el agente una vez dentro. Un agente puede encadenar tareas, elegir herramientas dinámicamente y realizar acciones no previstas por la revisión de permisos.
Esta brecha entre intención y ejecución se refleja en OWASP LLM06: el exceso de agencia. Los roles estáticos no limitan el comportamiento autónomo, y la revisión de configuración no indica si el agente se comporta como se esperaba.
Riesgos de la vida útil y credenciales
Los agentes se crean con automatización, pipelines o equipos de aplicación, evitando los flujos de gobernanza humana. Esto provoca:
- Sin propietario: nadie es responsable del propósito o alcance del agente.
- Secretos de larga duración: claves estáticas que persisten sin rotación.
- Delegación ilimitada: heredan permisos de usuario o servicio sin restricciones.
- Instanciación invisible: agentes generados por otras cargas de trabajo no se registran en el IdP.
- Sin expiración: el acceso persiste más allá del piloto.
Componentes esenciales del marco
- Identidad y credenciales: cada agente necesita una identidad única, nunca una cuenta de servicio compartida. Se recomienda federación de identidad y credenciales de corta vida.
- Autorización granular: aplicar controles de acceso de NIST SP 800‑53 Rev. 5 (AC‑6, AC‑5). Los controles deben estar cerca de la acción, no solo en el punto de inicio de sesión.
- Auditoría y monitoreo: registrar todas las acciones del agente para reconstruir la secuencia de eventos.
Detalles técnicos
- OAuth 2.0 Token Exchange (RFC 8693) permite que el agente intercambie un token de usuario por un token propio, manteniendo la separación de identidades.
- Task‑scoped grants: los permisos se emiten por tarea y caducan con ella.
- Tool allowlisting: el agente solo puede invocar APIs y funciones necesarias.
- Data boundaries: restringir las fuentes de datos manipulados.
- Action thresholds: operaciones críticas requieren aprobación humana o una segunda ruta de autorización.
¿Qué significa esto para ti?
Si ya usas IAM tradicional, considera cómo se traduce a agentes de IA. Necesitas integrar la generación de identidades no humanas, la emisión de credenciales de corta vida y la auditoría de acciones dentro de las aplicaciones. La ausencia de estos controles puede exponer tu entorno a privilegios no justificados y a auditorías incumplidas.
Próximos pasos
Explora el guía de Orchid Security sobre IAM para agentes de IA para profundizar en la implementación práctica. Consulta el RFC 8693 para comprender los mecanismos de intercambio de tokens.
