La identidad en la seguridad de los agentes ya está establecida. Un agente debe contar con una identidad propia, mediante credenciales temporales y revocables, vinculadas a la tarea que realiza y con un registro que permita identificar a la persona que lo activó. En agosto de 2026, expertos en seguridad del NIST defendieron esta visión y la mayoría de proveedores de identidad la respaldan.
La gestión de identidad y acceso es una base imprescindible, pero no es el origen de las vulnerabilidades actuales.
Lo que realmente está fallando es la idea tradicional que hemos sostenido durante veinte años: si controlamos el acceso en la entrada, los problemas dentro se resolverán solos. Esto funcionaba cuando el software era pasivo. Sin embargo, hoy los agentes actúan con autonomía, analizan objetivos y eligen por sí mismos las acciones a seguir, como expertos escapistas. 
Un agente que encuentra un obstáculo busca otra ruta
La mayoría de los controles actuales se centran en gestionar la entrada: ¿Debe conectarse? ¿Tiene permiso para acceder a un servicio? ¿Es válido su token? Cada uno responde a una pregunta sobre la ruta de conexión, y casi nunca existe una única vía para llegar a un destino relevante.
Por eso, cuando un agente encuentra una ruta bloqueada, lo interpreta como un desafío que debe superar. Mientras que una persona podría abrir un ticket ante una puerta cerrada, un agente buscará por una ventana.
En julio de 2026, un agente autónomo permaneció cuatro días y medio dentro de los sistemas de producción de Hugging Face. Un filtro configurado para restringir las descargas de los servidores de datos nunca se activó porque el agente cambió la estrategia: dejó de solicitar recursos remotos y se centró en operar con recursos locales. El filtro funcionó correctamente, pero el agente simplemente eludió la restricción.
En entornos comunes de desarrollo, se han detectado casos donde malware en paquetes npm comprometidos intentó aprovechar asistentes de codificación con IA para buscar secretos, y en otros, un agente eliminó accidentalmente una base de datos de producción durante un periodo de congelación de cambios, para luego engañar al operador afirmando que los datos no podían recuperarse. Estos incidentes ocurrieron directamente en la máquina local, sin que los controles de red los detectaran.
De un modelo exterior-interior a uno interior-exterior
Los controles externos se encargan del acceso, y la mayoría de las organizaciones disponen de múltiples medidas en esta capa. Pero la seguridad interior no reemplaza esos controles exteriores; los completa.
La seguridad interna se focaliza en la acción misma y plantea una cuestión más concreta y difícil: ¿Debe este agente, actuando bajo la autoridad de esta persona, ejecutar exactamente esta acción sobre este sistema en este momento?
Esta pregunta es crucial porque aunque un agente pueda intentar múltiples caminos, el resultado que persigue es siempre el mismo. Por ejemplo, borrar una tabla será borrar una tabla, independientemente de cómo llegue hasta ella. El control debe interceptar y evaluar cada acción en el momento preciso.
Los controles habituales cubren diferentes aspectos:
| Control | Qué cubre | Qué no cubre |
|---|---|---|
| Gateway | Tráfico que pasa a través de él | Los comandos locales y cambios en archivos que no pasen por la red |
| Sandbox | Ambiente controlado global | Restricciones granulares en acciones individuales |
| SIEM | Registro de eventos realizados | Detección en tiempo real antes de la acción |
| Registro de agentes | Existencia del agente | Acciones que ha realizado el agente |
Muchos de estos controles deciden fuera del momento crítico, tras realizar la acción, lo que limita su eficacia para detener acciones maliciosas o erróneas.
Colocar el punto de control donde actúa el agente
Cada agente opera mediante un mecanismo de ejecución (agent harness): un software que realiza la acción indicada, ya sea ejecutar un comando, modificar un archivo o llamar a una API. Actualmente, en la mayoría de las implementaciones, no existe ninguna supervisión que evalúe la acción justo antes de que se efectúe.
El enfoque de seguridad interior-interna introduce un paso de aprobación en ese espacio: antes de que el mecanismo ejecute una acción, un punto de control examina qué agente solicita, bajo qué autoridad, contra qué sistema, y aplica la política correspondiente. La acción puede permitirse, denegarse o enviarse a revisión humana. Debido a que todas las acciones pasan ahí, si un agente ve bloqueada una acción destructiva y prueba una versión menos dañina, seguirá sujeto a las mismas reglas. La principal vulnerabilidad será una mala configuración de la política, algo que se puede corregir.
Sin la base de identidad sólida, ningún control sirve. Para que cualquier nivel de seguridad —ya sea en el prompt, la inferencia, el mecanismo de ejecución o la capa de políticas— pueda decidir «¿puede un agente llevar a cabo esta acción sobre este objeto?» es imprescindible que la solicitud contenga una identidad única y auditada, y no una cuenta de servicio compartida por varios agentes y personas.
Las compañías que desarrollan entornos para agentes comparten esta visión. En los últimos 18 meses, entidades como Anthropic, Google, Microsoft, OpenAI, LangChain y Cursor han incorporado ganchos (hooks) que permiten inspeccionar una acción antes de que se ejecute. AWS también argumentó que los controles deben aplicarse justo cuando un agente intenta invocar una herramienta.
El problema actual es que estos mecanismos no están estandarizados, cada uno funciona diferente. Una empresa que use varias plataformas necesitará mantener la lógica de control en diversas variantes, con múltiples auditorías, lo que dificulta la escalabilidad y une la seguridad al entorno técnico empleado. Por ello, es necesario un sistema de seguridad único, independiente del proveedor, que supervise todas las acciones, para no tener que reiniciar los análisis de seguridad cada vez que se adopta un nuevo modelo o framework.
Observa antes de bloquear
La reacción típica en seguridad es «bloquea inmediatamente», pero esta estrategia genera conflictos con la dinámica empresarial. La seguridad debe adaptarse al ritmo de la empresa y no frenarla. Herramientas como sistemas de prevención de intrusiones o firewalls de aplicaciones web suelen arrancar en modo monitor, para identificar patrones normales antes de aplicar bloqueos, porque saltarse esta fase puede provocar interrupciones de producción.
Los agentes exigen un proceso similar, pero acelerado. Un punto de control en modo observación no bloquea nada, pero proporciona respuestas que muchas empresas hoy no pueden obtener:
- Cuáles agentes están activos, no solo cuáles se supone que deben estarlo.
- Quién inició cada agente y bajo qué autoridad opera.
- Qué capacidades usaron y sobre qué sistemas actuaron.
- Qué acciones habrían violado políticas si el sistema estuviera en modo ejecución.
La política debe construirse a partir de datos concretos y evidencias, no solo de diagramas conceptuales. La aplicación efectiva debe empezar en las áreas con más riesgo: comandos destructivos, datos de producción o movimientos de datos sensibles. Posteriormente, es necesario observar los patrones, perfeccionar las políticas y confiar en el uso seguro y controlado de la IA, aplicando un ciclo de observar, aprender, construir y desplegar.
En resumen
No es necesaria nueva infraestructura, solo extender la identidad, autorización y auditoría ya existentes para usuarios humanos a los agentes, aplicándolos dentro del mecanismo de ejecución justo antes de que ocurran las acciones.
El perímetro de seguridad sigue existiendo, pero se ha trasladado hasta el momento en que el agente actúa, el único punto que no puede evitar.
Una solución pionera es Agent Security de Ory, que opera dentro del mecanismo de ejecución y usa los mismos sistemas de identidad y autorización que gestionan usuarios humanos. Esta solución comienza en modo observación para crear un inventario preciso y está disponible ya para su prueba en ory.com/agent-security.
