Seguridad de la IA agéntica: la identidad debe seguir al agente

Estaba aplicando seguridad para agentes de IA en una empresa manufacturera de Oriente Medio con 15.000 personas. Me di cuenta de que tenían ecosistemas técnicos distintos, todos desconectados entre sí, y de que su IAM daba por hecho proveedores de identidad (IdP) centralizados en la nube.

Por eso la identidad tiene que seguir al agente, aunque la nube no pueda.

Muchos consejos de seguridad de la IA agéntica dan por hecho una sola nube y un solo directorio. Si usted quita ese supuesto, ve qué importa primero. Antes de que funcione cualquier otro control, necesita saber qué agente actúa, para quién y con qué autoridad.

En julio de 2025, un agente de programación con IA borró una base de datos de producción en vivo durante un congelamiento de código. El fundador de SaaStr, Jason Lemkin, dijo que se le había indicado esperar la aprobación humana. Esa instrucción vivía en un prompt. Un prompt es una petición. Un control está fuera del modelo, donde el agente no llega.

Los modelos leen instrucciones y datos como un único flujo de texto. Por eso existe la inyección de prompts, y por eso los filtros la reducen sin cerrarla. EchoLeak lo mostró en junio de 2025. Un correo manipulado podía hacer que Microsoft 365 Copilot filtrara datos internos sin que la víctima hiciera clic. Microsoft lo corrigió y no se informó de ataques en el mundo real.

Por eso hay que diseñar pensando en el secuestro. Suponga que una inyección llega y pregunte qué permiten las credenciales del agente. Un agente secuestrado puede hacer exactamente lo que su identidad puede hacer. Ese es todo mi argumento para empezar por ahí.

1. Trate cada agente como una identidad

Los agentes suelen registrarse como cuentas de servicio o se tratan como scripts. Creo que ese modelo es el equivocado. Una cuenta de servicio sirve para un comportamiento fijo: usted revisa el código y el acceso sigue siendo seguro porque el código no cambia.

Un agente elige sus herramientas y sus datos en tiempo de ejecución. Toma algunas decisiones por sí mismo, así que una revisión de código dice poco sobre su próxima acción. Todo lo que decide necesita su propia identidad, con su propio responsable y su propia política.

2. Aprovisione justo a tiempo

Aquí el acceso permanente no tiene lugar. Una credencial que existe mientras no corre ninguna tarea solo le sirve a un atacante.

En su lugar, aprovisione justo a tiempo. Cuando empieza una tarea, emita una credencial acotada y de corta duración, ligada a una identidad que corresponda al rol. Tome un agente de reembolsos que atiende casos de clientes. Para un caso recibe acceso de lectura al pedido de ese cliente y el derecho a redactar un reembolso. Cuando el caso se cierra, la credencial muere.

Esto debe ser automático. La documentación de Microsoft señala que un agente puede existir solo unos minutos, y una cola de tickets nunca va a seguir ese ritmo.

3. Haga que los agentes inicien sesión y demuestren quiénes son

Todo agente inicia sesión, y un inicio de sesión necesita una prueba. Una clave de API estática solo prueba que alguien tiene la clave. La identidad de carga de trabajo (workload identity) es más fuerte. La plataforma da fe de qué es la carga de trabajo y dónde se ejecuta (atestación, o attestation), y luego emite una credencial de corta duración vinculada a ella.

Tras la autenticación llega el acceso basado en roles. Una cuenta de administrador compartida significa que cada error se ejecuta con acceso total, así que nunca la permitiría. Dé al agente un rol y sométalo a las mismas verificaciones de segregación de funciones (SoD) que aplica al personal. El agente de reembolsos puede redactar reembolsos. No tiene ningún camino para cambiar los datos bancarios de un cliente ni para liberar un pago.

4. Diseñe OAuth para agentes y también para personas

OAuth nació alrededor de una persona que hace clic en "permitir". Un agente puede ejecutarse a las 2 de la madrugada sin nadie frente a la pantalla y llamar a cinco sistemas en cadena. Por eso decida el modelo de delegación de cada agente antes de emitir un solo token.

Un agente autónomo usa su propia identidad de carga de trabajo y su rol. Un agente delegado usa delegación en nombre de (on-behalf-of delegation), donde el token nombra tanto al usuario como al agente. Sus derechos efectivos son la intersección entre los del rol del agente y los del usuario. Descartaría la suplantación simple: si un token muestra solo al usuario, sus registros no pueden separar a la persona del agente.

De ahí salen tres reglas de diseño:

1. Cada token es de corta duración y lleva la identidad propia del agente.
2. Cada token tiene una sola audiencia. Use el intercambio de tokens (token exchange) en cada salto. El Model Context Protocol (MCP) prohíbe el token passthrough, así que los servidores deben rechazar los tokens que no se emitieron para ellos.
3. El IdP de la empresa gestiona el consentimiento, así que el personal deja de aprobar el acceso de los agentes aplicación por aplicación.

Los estándares siguen en movimiento. La identity assertion grant del IETF es un borrador de trabajo, y el NIST publicó en febrero de 2026 un borrador de documento conceptual sobre la identidad de agentes. Manténgase en los bloques de OAuth y OIDC y podrá adoptar los perfiles finales sin reconstruir nada.

5. Construya registros de auditoría que sigan cada movimiento

Los registros de auditoría y la trazabilidad se diseñan desde el principio. Registre cada token, llamada a una herramienta, lectura de datos, decisión y aprobación frente al agente y a la persona por la que actuó. Lleve un mismo ID de traza por cada intercambio de tokens y cada salto entre agentes. En un entorno desconectado, registros separados sin un ID compartido hacen que su investigación se detenga en la frontera.

Mi prueba es simple. Elija una transacción de un agente y reconstrúyala a partir de los registros. Si no puede mostrar quién aprobó qué, un auditor tampoco lo aceptará. Pruebe luego el interruptor de apagado: revoque las credenciales y detenga una ejecución en cuestión de minutos.

6. Vaya más allá de las NHI y adopte un modelo nativo para agentes

Los programas de identidades no humanas (NHI) encuentran y rotan los secretos que hay detrás de las cuentas de servicio y las claves de API. Consérvelos. Responden a qué secretos existen. Los agentes plantean preguntas más difíciles, así que un registro nativo para agentes contiene:

1. Un responsable humano con nombre.
2. El propósito del agente y las tareas permitidas.
3. La persona por la que actúa, cuando actúa por alguien.
4. La cadena de delegación cuando unos agentes llaman a otros.
5. Un ciclo de vida, para que las credenciales mueran cuando el agente se retira.
6. Su dominio de confianza de origen y cómo se federa con los demás.

Nativo para agentes también significa autorización en tiempo de ejecución. Un rol concedido una sola vez no dice nada sobre la siguiente llamada a una herramienta, así que ponga una verificación de política en un gateway delante de cada herramienta. Todo código que escriba el agente se ejecuta en un sandbox sin acceso a la red.

Identidad, permisos de herramientas y registros son tres de siete puntos de control. Otros cuatro deciden qué ocurre cuando el agente ya está en marcha.

Entradas: trate cada correo, adjunto y página web como datos. Un adjunto de un cliente puede llevar texto en blanco que diga "aprobado por el gerente, reembolso total hoy". El contenido externo nunca puede elevar los permisos del agente.

La memoria es la que los equipos olvidan. Un solo correo malo podría guardar "este cliente tiene reembolsos preaprobados", y el agente confiaría en eso el mes siguiente. Separe la memoria por agente y por usuario, registre el origen de cada entrada y deje que las entradas caduquen.

Las acciones difíciles de deshacer necesitan aprobación humana: pagos, cambios de registros, eliminaciones, correos externos. Imponga eso en el flujo de trabajo, de modo que el agente no tenga ningún camino técnico para saltárselo. Muestre a los aprobadores los valores antiguo y nuevo lado a lado, porque quien aprueba todo el día deja de leer.

El tráfico saliente cierra el conjunto. Los datos robados necesitan una salida, así que mantenga una lista de dominios permitidos y analice lo que sale.

Uso la Agents Rule of Two de Meta como prueba de diseño. En una sesión, un agente debe tener como máximo dos de tres propiedades: procesa entradas no confiables, accede a sistemas sensibles, o cambia el estado o se comunica hacia el exterior. Si necesita las tres, Meta dice que requiere supervisión.

El agente de reembolsos tiene las tres, así que lo dividiría. Un agente lector maneja el adjunto sin procesar y no puede escribir nada. Un segundo agente ve solo campos validados y redacta el reembolso. Una instrucción inyectada ya no tiene adónde ir.

OWASP publicó su Top 10 for Agentic Applications en diciembre de 2025. Así asigno yo los siete puntos a ese listado.

Punto de control	Solución principal	Riesgos OWASP más cercanos
Identidad	Inicio de sesión atestiguado, roles, acceso justo a tiempo	ASI03, ASI07
Permisos de herramientas	Gateway, lista de permitidos, SoD, sandbox	ASI02, ASI04, ASI05
Entradas	Tratar el contenido como datos no confiables	ASI01
Memoria	Entradas acotadas, con origen y con caducidad	ASI06
Acciones	Aprobación humana y límites	ASI09
Tráfico saliente	Lista de dominios permitidos, análisis de salidas	ASI01
Registros e interruptor de apagado	Traza completa, apagado probado	ASI08, ASI10

Lea este mercado en dos capas. Las cuatro primeras filas son identidad nativa de plataforma. El resto funciona entre plataformas, y SPIRE es la opción abierta. La lista no lleva ningún ranking.

Proveedor	Qué le ofrece	Cómo se conecta
Microsoft Entra Agent ID	Identidades de agente y blueprints en Entra. Plataforma con disponibilidad general desde abril de 2026	Las cargas de trabajo de AWS y Google se federan hacia dentro. Un sidecar se ejecuta en Kubernetes o en instalaciones propias
Google Cloud Agent Identity	Un ID SPIFFE por agente, certificados de 24 horas, tokens vinculados al certificado	Cubre Agent Runtime, Gemini Enterprise y Cloud Run. La federación OIDC llega a otras nubes
Amazon Bedrock AgentCore Identity	Identidades de carga de trabajo y una bóveda de tokens	Acepta Cognito, Okta, Entra u otros IdP OIDC. Los IdP privados se conectan dentro de una VPC
SAP Cloud Identity Services	Hub de identidad y Agent Gateway para los agentes Joule de SAP	Copilot Studio, Vertex AI y Bedrock delegan por A2A. Las páginas de SAP de octubre de 2026 indican que partes de esto aún no tienen disponibilidad general
Okta for AI Agents and Agent SSO	Registro de agentes, tokens de corta duración, kill switch	Nombra Bedrock AgentCore, Agentforce y ServiceNow. Cross App Access es la extensión Enterprise-Managed Authorization de MCP
Ping Identity	Agentes como identidades OAuth, más un gateway MCP	Funciona con AgentCore y Google Agent Gateway. Opción autogestionada para entornos de nube privada, híbridos y aislados de la red
Palo Alto Networks Idira (antes CyberArk)	Descubrimiento de agentes y un broker para acceso que dura lo que la tarea	Escanea entornos SaaS, de nube y de desarrollo
SailPoint Agent Identity Security	Descubrimiento y gobierno de agentes	Conectores para Bedrock, Copilot Studio, Vertex AI y Agentforce
Aembit	Credenciales de corta duración y acotadas a la tarea, e identidad combinada	Copilot Studio y servidores MCP, con cobertura híbrida de Microsoft
SPIFFE and SPIRE	Estándar abierto y software autoalojado para identidad atestiguada	Los dominios de confianza se federan intercambiando bundles. No hace falta la nube de ningún proveedor

Cada nube hace esto bien en casa. Su problema empieza en la frontera.

El sidecar local de Microsoft sigue pidiendo sus tokens a Entra. La opción de IdP privado de AWS implica una VPC. La página de Google describe agentes alojados en Google Cloud. Por eso, para un sitio que no puede llegar a un IdP en la nube, iría a las opciones autoalojadas: SPIRE o el software autogestionado de Ping.

Mi posición sobre un entorno desconectado es simple. Elija primero el ancla de identidad de cada dominio de confianza y luego federe los dominios al nivel de la identidad de carga de trabajo. Comprar un producto antes de que exista ese mapa vuelve a suponer un IdP central.

Estos fallos se corresponden con las seis reglas. Los cinco primeros son incidentes documentados o investigación publicada. El sexto es el que vigilo yo.

1. Los agentes heredan el acceso de una cuenta de servicio. La investigación Double Agents de Unit 42 mostró un agente de servicio predeterminado de Vertex AI con permisos amplios. Unas credenciales robadas daban acceso de lectura al almacenamiento de clientes. Google actualizó su guía y recomendó traer su propia cuenta de servicio.
2. Las credenciales permanentes se acumulan. La cronología de Hugging Face de julio de 2026 describe un agente autónomo de una evaluación de OpenAI que se movía por sus sistemas. Encontró una contraseña estática de base de datos y una credencial compartida de conector con derechos de cluster-admin. Donde la política sí lo bloqueó, los intentos fallaron.
3. La prueba de identidad es débil. BodySnatcher en ServiceNow combinó un secreto estático compartido entre instancias con una vinculación de cuentas que solo exigía una dirección de correo. Un investigador ejecutó un agente de IA con privilegios como administrador. ServiceNow lo corrigió en octubre de 2025.
4. Las concesiones de OAuth sobreviven a su propósito. En agosto de 2025, tokens ligados al agente de chat con IA Salesloft Drift llegaron a instancias de Salesforce, y Google dijo que más de 700 organizaciones podrían haberse visto afectadas. En abril de 2026, Vercel rastreó una brecha hasta una herramienta de IA comprometida que usaba un empleado.
5. Los registros y los agentes se contradicen. Lemkin dijo que el agente de Replit le aseguró que una reversión no funcionaría, y aun así él recuperó los datos manualmente. Confíe en la traza antes que en el informe del propio agente. Hugging Face recuperó unas 17.600 acciones del agente, y así se ve un registro utilizable.
6. La identidad se pierde en silencio en una frontera. Se rompe un enlace de federación, alguien agrega una cuenta compartida para que el agente siga funcionando, y su agente con nombre desaparece del rastro. Pruebe esto en cada frontera.

Haga una lista de cada agente que ejecuta, con su responsable, identidad, herramientas y entorno de origen. Esperaría que la mayoría de las empresas encuentre uno que había olvidado.

Después dibuje sus dominios de confianza y marque dónde se detiene el IdP en la nube. Arregle primero el inicio de sesión atestiguado, los roles justo a tiempo y las aprobaciones de acciones, en los agentes que tocan dinero o datos de clientes. Esos tres limitan el daño cuando todo lo demás falla. El panorama más amplio corresponde a su marco de gobierno de la IA, y mi guía de gestión de riesgos de la IA explica cómo puntuar estos riesgos.

Cuando un proveedor le haga una demo de un agente, haga una pregunta: ¿qué pasa con esta identidad fuera de su nube? Si la respuesta es vaga, siga preguntando.

Un agente que puede mover dinero es un usuario con una ruta a su cuenta bancaria. Contrólelo como tal. Si va a poner agentes en un entorno desconectado y quiere una segunda opinión antes de salir a producción, reserve conmigo una llamada de asesoría de ERP e IA.