Identidad con intención: la clave para controlar a los agentes de IA que ya operan en producción

Hace apenas un par de años, desplegar inteligencia artificial en la empresa solía significar asistentes que redactaban correos o resumían documentos. Hoy, esos mismos sistemas han dejado de ser meros copilotos: provisionan infraestructura, resuelven tickets de soporte, priorizan alertas, aprueban transacciones y hasta escriben código que llega a producción. En pocas palabras, los agentes de IA ya no son asistentes pasivos: actúan como operadores dentro de la organización.

Eso obliga a los responsables de seguridad —los CISOs— a reenfocar un problema conocido pero ahora mucho más complejo: el control de acceso. Cada agente se autentica contra APIs, servicios en la nube y herramientas de terceros usando claves, tokens OAuth, roles de nube o cuentas de servicio. Lee datos, escribe configuraciones y encadena llamadas a otros sistemas. En el mundo técnico, un agente de IA se comporta exactamente como una identidad, y sin embargo en muchos entornos no se le gobierna como tal.

La realidad operativa es sencilla y peligrosa: muchos agentes heredan privilegios de su creador, se ejecutan con cuentas demasiado amplias para “que todo funcione” y evolucionan más rápido que los controles que los rodean. Esa combinación produce lo que ya puede considerarse una zona ciega emergente en seguridad de IA. La primera respuesta obvia es aplicar un enfoque de identidad para los agentes: tratar cada agente como una identidad de primera clase con ciclo de vida, propiedad, roles y trazabilidad. Sin embargo, hay una segunda verdad que complica el panorama: la identidad por sí sola ya no basta.

Los modelos tradicionales de gestión de identidad y acceso (IAM) responden a una pregunta concreta: ¿quién solicita el acceso? En entornos centrados en personas o servicios estáticos eso podía ser suficiente porque los roles y funciones eran previsibles. Pero los agentes de IA son dinámicos por diseño: interpretan objetivos, planifican pasos y encadenan herramientas según el contexto. Un agente que arranca con la misión de generar un informe trimestral podría, si se le orienta o es manipulado, intentar acceder a sistemas ajenos al reporte. Un agente de remediación puede desviarse y modificar configuraciones que exceden su propósito original.

Ese comportamiento rompe la suposición de determinismo en la que se basa el acceso estático: si el rol lo permite, la acción se ejecuta aunque ya no coincida con la razón original de la existencia del agente. Aquí entra la necesidad de un paso más allá del IAM clásico: los permisos basados en intención. Si la identidad responde al “quién”, la intención responde al “por qué”.

Permitir que un agente active privilegios solo cuando su misión declarada y su contexto de ejecución justifiquen esa activación transforma el control de acceso. En lugar de un mapa estático entre identidad y permisos, el sistema evalúa si el propósito y las condiciones en tiempo de ejecución autorizarían ese acceso. Por ejemplo, un agente de despliegue podría tener la capacidad de modificar infraestructura, pero esos privilegios solo se activan si la acción se realiza desde una canalización aprobada y en respuesta a un cambio autorizado. Si el mismo agente intenta tocar producción fuera de ese flujo, las credenciales no permiten la operación.

Este enfoque compuesto atenúa dos fallas recurrentes. Por un lado, la herencia de privilegios: es habitual que desarrolladores prueben agentes con credenciales propias elevadas y esas credenciales perduren en producción. Si cada agente tiene identidad propia y gestionada, ese “sangrado” desaparece. Por otro lado, la deriva de misión: los agentes pueden pivotar por prompts, integraciones o ataques; las políticas basadas en intención impiden que ese pivot se convierta en acceso no autorizado.

Pero más allá del cierre de riesgos concretos, hay un argumento organizacional poderoso: gobernanza que escala. En ecosistemas donde un agente puede invocar miles de APIs y recursos en múltiples nubes y SaaS, gestionar cada permiso como una regla separada conduce rápidamente a una explosión de políticas difícil de auditar. Un modelo de intención simplifica la supervisión: en lugar de revisar cada llamada posible, los responsables auditan perfiles de identidad y límites de intención aprobados. Las revisiones de política pasan a centrarse en si la misión autorizada tiene sentido, no en inventariar cada endpoint que un agente podría tocar.

La trazabilidad también mejora. En un incidente, no solo importa saber qué identidad ejecutó una acción, sino qué perfil de intención estaba activo y si la operación se alineó con la misión autorizada. Esa granularidad de contexto es cada vez más relevante para la rendición de cuentas ante reguladores y directorios ejecutivos. Para los equipos técnicos, además, facilita la investigación y la respuesta rápida.

Estas ideas no son solo teoría: enlazan con marcos y prácticas que llevan años consolidándose en seguridad, como los principios de Zero Trust o los modelos basados en atributos. Recursos como el marco de gestión de riesgos de IA del NIST (NIST AI RMF), las recomendaciones de control de acceso basadas en atributos (NIST SP 800-162) y la estrategia de Zero Trust (NIST SP 800-207) ofrecen principios que encajan con este enfoque de identidad+intención. Asimismo, organizaciones como la Cloud Security Alliance y proyectos comunitarios como OWASP están empezando a documentar riesgos y controles específicos para sistemas de IA.

¿Y qué medidas prácticas pueden empezar a aplicar los equipos de seguridad hoy mismo? El camino arranca por un inventario claro de agentes y sus capacidades, asignándoles identidades únicas con gestión de ciclo de vida y propietarios responsables. A partir de ahí conviene definir, por escrito, la misión aprobada de cada agente y los límites operativos en los que puede actuar. Esa documentación debe integrarse con mecanismos técnicos que condicionen la activación de privilegios a la coincidencia entre identidad, intención declarada y contexto en tiempo de ejecución.

En paralelo hay que instrumentar la supervisión: registros enriquecidos que muestren no solo qué se hizo y por quién, sino cuál era la intención asociada y qué señales de contexto (pipeline, origen de la petición, autenticación multifactor, etc.) permitieron la acción. Finalmente, automatizar la rotación de credenciales, la revocación al término del ciclo de vida y las comprobaciones periódicas de desvío de misión reduce exposición y aclara la gobernanza.

La alternativa es peligrosa: permitir autonomía sin gobernanza multiplica el riesgo; tener identidad sin intención deja huecos. En la era agentic, entender quién actúa es necesario, pero asegurarse de que actúa por la razón correcta es lo que hace que la IA sea segura. Para los CISOs, adaptar procesos, herramientas y revisión de políticas a esta realidad no es una opción, es una obligación para mantener control, cumplimiento y resiliencia.

Si quieres profundizar en marcos y recomendaciones prácticas, empieza por los recursos del NIST sobre IA y control de acceso que he mencionado, y por la documentación y las buenas prácticas que publican iniciativas como la Cloud Security Alliance. La conversación sobre cómo poner en marcha controles de identidad y permiso por intención apenas comienza, y es imprescindible que la afronten equipos de seguridad, ingeniería y cumplimiento de forma coordinada.