Las agencias de los Cinco Ojos dicen que la mayoría de las implementaciones de agentic AI ya son demasiado permisivas

El 1 de mayo de 2026, CISA, la NSA y sus homólogos del Reino Unido, Australia, Canadá y Nueva Zelanda publicaron la primera guía de seguridad multigubernamental coordinada para agentic AI: "Careful Adoption of Agentic AI Services". El mensaje central es contundente: las organizaciones de infraestructuras críticas y defensa no están evaluando un riesgo futuro; ya están ejecutando agents con más acceso del que sus propios equipos de seguridad pueden controlar, y la guía existe porque esa brecha ha dejado de ser teórica.

Lo que hace que este documento merezca una lectura detallada, incluso si no trabajas en infraestructura crítica, es que es el primer intento de las agencias de seguridad por categorizar formalmente lo que puede salir mal con un AI agent — a diferencia de una aplicación tradicional — y las categorías se alinean directamente con los errores que la mayoría de los equipos que implementan agents en este momento ya están cometiendo.

Cinco categorías de riesgo y por qué no se reducen a "prompt injection"

La guía divide el riesgo de agentic AI en cinco categorías: privilegio, diseño y configuración, comportamiento, estructural y responsabilidad. Es un marco deliberadamente más amplio que el enfoque predeterminado de la industria de seguridad en prompt injection y jailbreaks, y el razonamiento es directo: un agent con privilegios limitados y correctamente definidos es mucho menos peligroso incluso cuando es manipulado con éxito, porque la manipulación no tiene a dónde ir.

Riesgo de privilegio se refiere a agents que tienen acceso permanente a sistemas, datos o acciones muy por encima de lo que requiere una sola tarea: el equivalente en AI de una service account con permisos de domain admin porque nadie se tomó el tiempo de limitarla. Riesgo de diseño y configuración abarca agents conectados a cadenas de herramientas y fuentes de datos externas sin que nadie haya mapeado lo que esa interconexión realmente expone. Riesgo de comportamiento es el agent haciendo algo no deseado incluso sin manipulación externa: una acción emergente que nadie programó explícitamente. Riesgo estructural se refiere a las dependencias en capas que los agents introducen (una herramienta o fuente de datos comprometida se convierte en un agent comprometido). Riesgo de responsabilidad es el más difícil de incorporar a posteriori: cuando un agent toma una acción con consecuencias, ¿alguien puede reconstruir por qué y quién es responsable de que haya ocurrido?

El problema de la superficie de ataque interconectada

La guía es explícita al señalar que el problema de seguridad central de agentic AI no es el modelo, sino la cantidad de componentes que un agent suele tocar. Un solo customer-support agent podría llamar a una CRM API, una base de conocimiento, un sistema de tickets y una herramienta de correo electrónico, cada uno con sus propias credenciales y modos de fallo. El documento advierte que esto crea "una superficie de ataque interconectada que los actores maliciosos pueden explotar", porque comprometer cualquier eslabón de esa cadena puede comprometer los permisos efectivos del agent en todos ellos.

Este es precisamente el patrón detrás de los incidentes de seguridad de AI agent más graves divulgados este año: los atacantes no necesitan atacar el modelo en sí cuando pueden comprometer una integración de herramienta débilmente protegida y heredar cualquier acceso que se le haya otorgado al agent.

Lo que la guía realmente te dice que hagas

Quitando el marco conceptual, el núcleo operativo son cinco reglas, todas aplicables hoy con las herramientas de identidad y acceso existentes:

Nunca otorgues a los agents acceso amplio o sin restricciones. Si la service account de un agent puede hacer más de lo que requiere su lista de tareas documentada, esa es la brecha que usarán los atacantes — y suele ser una brecha creada por conveniencia durante el despliegue inicial, no una decisión deliberada.

Restringe a los agents a tareas de bajo riesgo y no sensibles por defecto, y exige una excepción explícita y revisada para ampliar el alcance — invirtiendo el patrón común de otorgar acceso amplio desde el principio y restringirlo después (lo que rara vez ocurre realmente).

Aplica el principio de mínimo privilegio con autenticación por solicitud, no una única credencial permanente que el agent mantenga durante toda su vida. Cada llamada a una herramienta debe autenticarse y delimitarse de forma independiente, de modo que una sesión comprometida no herede acceso irrestricto.

Exige aprobación humana para acciones de alto impacto — transacciones financieras, eliminación de datos, cambios en controles de acceso, cualquier cosa que sea costosa o difícil de revertir. La guía trata esto como algo no negociable, no como un añadido opcional para despliegues tempranos.

Gestiona la seguridad de los AI agents dentro de los marcos de ciberseguridad existentes, no como un programa paralelo y a medida. Los agents deben aparecer en los mismos inventarios de activos, revisiones de acceso y playbooks de respuesta a incidentes que cualquier otro componente del sistema con credenciales y acceso a la red.

La conclusión para los equipos que despliegan agents este trimestre

Si estás implementando un AI agent en producción y no puedes responder "¿cuál es el radio de explosión máximo si la sesión de este agent se ve comprometida ahora mismo?", la guía de los Cinco Ojos dice que tienes un problema de privilegio, no un problema de modelo. Realiza una auditoría de acceso antes de tu próximo despliegue de agent: lista cada herramienta, API y fuente de datos a la que el agent pueda acceder, luego pregúntate si cada una está limitada al permiso más restringido según la tarea, en lugar de un permiso amplio a nivel de servicio. Ese único ejercicio cierra la brecha que la mayoría de los post-mortem de incidentes de este año tienen en común.