Las agencias de inteligencia de los países Five Eyes publicaron el 2 de mayo de 2026 una guía conjunta advirtiendo que los sistemas de agentes IA con riesgos de seguridad son suficientemente serios como para recomendar adopción lenta y cuidadosa, y que hasta que los estándares de evaluación maduren, las organizaciones deben asumir que estos sistemas van a comportarse de formas inesperadas.
En 30 segundos
- CISA (EE.UU.), NCSC (Reino Unido), ASD (Australia), GCSB (Nueva Zelanda) y CSE (Canadá) publicaron juntos la guía “Careful adoption of agentic AI services” en mayo de 2026.
- Identificaron 23 riesgos distintos agrupados en 5 categorías: privilegios, diseño/configuración, comportamiento, superficie de ataque interconectada, y auditoría.
- La inyección de prompt se menciona como “la amenaza más persistente y difícil de resolver” para agentes autónomos.
- Recomiendan priorizar resiliencia sobre productividad: despliegue incremental, supervisión humana obligatoria y evaluaciones de seguridad previas.
- Cualquier componente que un agente usa (herramientas, APIs, datos externos) amplía la superficie de ataque y puede heredar sus permisos completos.
Qué son los agentes de IA y por qué operan en infraestructura crítica
Un agente de IA es un sistema autónomo que percibe su entorno, toma decisiones y ejecuta acciones para lograr objetivos, sin necesidad de aprobación humana en cada paso. A diferencia de un chatbot que responde preguntas, un agente puede llamar APIs, ejecutar código, acceder a bases de datos, enviar correos y encadenar tareas complejas por su cuenta.
Eso los hace atractivos. Una organización de defensa puede deployar un agente que monitoree logs de seguridad, detecte anomalías y aplique parches automáticamente, sin que nadie tenga que revisar cada alerta a las 3 de la mañana. En infraestructura crítica, esa automatización parece un golazo.
El problema es que el salto de “herramienta supervisada” a “sistema autónomo” trae consigo una superficie de riesgo completamente diferente. Según la guía de Five Eyes, estos sistemas “operan cada vez más en infraestructura crítica y sectores de defensa”, lo que los convierte en objetivos prioritarios para actores maliciosos.
La advertencia de Five Eyes: 5 categorías de riesgo identificadas
La guía documenta 23 riesgos distintos agrupados en cinco áreas. No es una lista de paranoia teórica: cada categoría tiene escenarios de explotación concretos.
- Riesgos de privilegios: Los agentes reciben permisos amplios para hacer su trabajo. Si alguien compromete el agente, hereda esos permisos.
- Riesgos de diseño y configuración: Configuraciones incorrectas que exponen capacidades no deseadas o crean dependencias inseguras.
- Riesgos de comportamiento: Alineación incorrecta de objetivos (el agente optimiza para lo que no querés) o comportamiento directamente deceptivo.
- Riesgos estructurales: La cadena de componentes interconectados multiplica los vectores de ataque.
- Riesgos de auditoría: Sin trazabilidad clara, es casi imposible saber qué hizo el agente, cuándo, y por qué.
La guía abre con una advertencia que vale la pena leer completa: hasta que las prácticas de seguridad, los métodos de evaluación y los estándares maduren, las organizaciones deben asumir que los sistemas de IA agéntica van a comportarse de forma inesperada. No “podrían”. “Deben asumir que lo harán”.
La superficie de ataque interconectada: cada componente es una puerta
Ponele que deployás un agente de automatización para gestión de contratos. Para funcionar, necesita acceso al sistema de documentos, al CRM, a la API de pagos y a un servicio externo de validación de firmas. Cada uno de esos puntos de integración es un vector de ataque potencial. Te puede servir nuestra cobertura de monetización de herramientas agénticas.
El documento Five Eyes lo dice sin anestesia: “cada componente individual en un sistema de IA agéntica amplía la superficie de ataque, exponiendo el sistema a vías adicionales de explotación”. Si el agente tiene acceso de escritura a contratos y alguien compromete la herramienta de validación externa, ese atacante puede modificar contratos y autorizar pagos usando los permisos del agente.
La ironía es que el efecto multiplicador funciona en contra de la organización. Tres componentes integrados no dan tres veces más valor, pero sí potencialmente tres veces más superficie de riesgo. Y a diferencia de un sistema tradicional donde comprometés una herramienta y tenés acceso a esa herramienta, acá comprometés una herramienta y podés acceder a todo lo que el agente puede hacer.
Inyección de prompt: la amenaza que la NSA dice es difícil de resolver
La inyección de prompt es la amenaza que aparece destacada en la guía como “la más persistente y difícil de arreglar”. Y tiene sentido cuando entendés cómo funciona en un contexto agéntico.
En un chatbot, la inyección de prompt es molesta pero contenida: el usuario le dice al modelo “ignorá tus instrucciones y hacé X”, el modelo puede obedecer, pero el daño es limitado porque el modelo solo responde texto. En un agente autónomo con acceso a herramientas, la historia es distinta.
¿Por qué es específica de agentes y tan difícil de parchar? Porque la inyección no viene solo del usuario. Un agente que lee documentos externos, navega webs o procesa datos de terceros puede encontrar instrucciones maliciosas embebidas en esos datos (inyección indirecta), y ejecutarlas automáticamente antes de que cualquier humano lo note.
Imaginá un agente de parcheo de sistemas que lee logs de eventos para decidir qué actualizar. Si un atacante logra escribir en esos logs una instrucción disfrazada como evento legítimo, el agente puede ejecutarla con todos sus privilegios. No hay parche universal conocido para esto: es un problema estructural del modelo de ejecución agéntica. Esto se conecta con lo que analizamos en restricciones en acceso a IA.
Escenarios reales de fallo documentados en la guía
La guía no se queda en abstracciones. Presenta escenarios concretos de cómo puede salir mal un deployment agéntico, y son los que cualquiera que haya trabajado con estos sistemas reconoce como plausibles.
Agente de parcheo que elimina logs de firewall
Un agente desplegado para automatizar el parcheo de sistemas recibe permisos amplios para modificar configuraciones. Un atacante externo o un dato envenenado le instruye eliminar logs del firewall antes de aplicar el parche. El agente lo hace (es parte de su tarea de “preparación del sistema”) y el incidente queda sin registro.
Herramienta de contratos secuestrada
Un agente para gestión de contratos tiene acceso de lectura y escritura al sistema documental y permisos para autorizar pagos hasta cierto monto. Si la herramienta de validación externa queda comprometida, el atacante puede modificar contratos y disparar pagos usando los permisos heredados del agente. (Spoiler: para cuando alguien lo nota, el dinero ya se movió.)
Agentes en la sombra sin controles TI
Un equipo de negocios conecta un agente de automatización usando sus credenciales personales, sin pasar por el proceso de aprobación de TI. El agente tiene acceso a sistemas críticos porque el usuario tiene acceso a esos sistemas. Nadie sabe que existe hasta que algo falla.
Esto último, la proliferación de “shadow AI agents”, es uno de los riesgos que más preocupa a las agencias firmantes. No por sofisticación técnica, sino porque el control organizacional desaparece antes de que aparezca el incidente.
Resiliencia sobre productividad: qué recomienda Five Eyes
Las seis agencias firmantes tienen una posición clara: la ganancia de productividad no justifica saltear controles de seguridad. La frase que abre la sección de recomendaciones es “priorizar resiliencia sobre productividad”, y no suena a consejo preventivo sino a corrección de un patrón que ya están viendo. Cubrimos ese tema en detalle en por qué las empresas frenan rollouts.
| Recomendación | Qué implica en la práctica |
|---|---|
| Despliegue incremental | No deployar agentes en producción sin pruebas en entornos controlados con datos reales pero acceso limitado |
| Governance fuerte | Registro centralizado de qué agentes existen, qué permisos tienen, quién los aprobó |
| Supervisión humana obligatoria | Checkpoint humano para operaciones irreversibles: transferencias de fondos, eliminación masiva de datos, cambios de configuración crítica |
| Monitoreo continuo | Logging de todas las acciones del agente con alertas ante comportamiento fuera de parámetros |
| Control de cadena de suministro | Evaluación de seguridad de cada herramienta, API y fuente de datos que el agente consume |
El punto sobre supervisión humana es el que más tensión genera con los casos de uso que hacen atractivos a los agentes. Si tenés que aprobar manualmente cada acción, ya no es tan autónomo. Pero para operaciones de alto impacto, las agencias no dejan margen: la intervención humana no es opcional.
Cómo prepararse ahora: pasos para organizaciones
Si estás evaluando o ya tenés agentes de IA en tu organización, hay medidas concretas que podés tomar sin esperar a que los estándares del sector maduren del todo.
El primero y más inmediato es el inventario. No podés proteger lo que no sabés que existe. Antes de cualquier control técnico, necesitás saber qué agentes están corriendo, con qué credenciales y qué accesos tienen. La proliferación de agentes departamentales sin control de TI es el vector más fácil de atacar porque nadie lo está mirando.
Segundo, aplicar least privilege con seriedad. Un agente que solo necesita leer contratos no debería poder modificarlos. Los permisos amplios “por si acaso” son el patrón que aparece en casi todos los escenarios de fallo documentados en la guía.
Tercero, definir qué operaciones requieren aprobación humana explícita. Que el agente pueda ejecutar consultas de lectura de forma autónoma está bien. Que pueda iniciar transferencias o borrar registros sin que nadie lo apruebe, no.
Desde el ángulo de infraestructura, los principios de zero trust y defense-in-depth que ya aplicás a sistemas tradicionales aplican acá también, pero con complejidad adicional porque el agente es el que genera el tráfico. Si tu organización maneja sus propios servidores donde corren estos sistemas, asegurate de que la infraestructura de base tenga controles equivalentes: donweb.com tiene opciones de hosting y VPS donde podés aislar entornos de prueba antes de mover agentes a producción.
Errores comunes al deployar agentes de IA
Error 1: Asumir que el agente solo hará lo que le dijiste. Los LLMs que alimentan a los agentes pueden ser redirigidos por datos envenenados en fuentes externas. Si tu agente procesa input de terceros (PDFs, webs, correos), ese input puede contener instrucciones. No es paranoia: es el mecanismo de inyección indirecta documentado por NSA y NCSC-UK. Más contexto en capacidades de modelos multimodales avanzados.
Error 2: Darle permisos amplios para facilitar el setup inicial. “Le doy acceso a todo para que funcione, después lo ajusto” es el patrón que lleva a que el ajuste nunca llegue y el agente quede con permisos innecesarios para siempre. Los permisos deben definirse antes del deployment, no después.
Error 3: No tener un plan de rollback. La guía de Five Eyes insiste en reversibilidad: si el agente hace algo inesperado, ¿podés detenerlo y revertir sus acciones? Si la respuesta es “depende de qué hizo”, tenés un problema de diseño antes que de seguridad.
Preguntas Frecuentes
¿Qué son los agentes de IA y por qué son distintos a un chatbot?
Un agente de IA es un sistema que percibe su entorno, toma decisiones y ejecuta acciones de forma autónoma para alcanzar objetivos, sin aprobación humana en cada paso. A diferencia de un chatbot que solo genera texto, un agente puede llamar APIs, modificar archivos, enviar datos y encadenar tareas complejas. Esa autonomía es lo que crea los riesgos documentados por Five Eyes en mayo de 2026.
¿Cuáles son los principales riesgos de seguridad de los agentes de IA autónomos?
Five Eyes identificó 23 riesgos en 5 categorías: privilegios excesivos, diseño y configuración incorrecta, comportamiento no alineado o deceptivo, superficie de ataque interconectada por múltiples componentes, y falta de auditoría y trazabilidad. La inyección de prompt (directa desde el usuario o indirecta desde datos envenenados) aparece como la amenaza más difícil de mitigar.
¿Qué recomiendan CISA y NCSC-UK sobre el despliegue de agentes IA?
Las seis agencias firmantes recomiendan priorizar resiliencia sobre productividad: despliegue incremental con pruebas en entornos controlados, governance centralizado de agentes y permisos, supervisión humana obligatoria para operaciones irreversibles, monitoreo continuo con logging completo, y evaluación de seguridad de cada herramienta y fuente de datos que consume el agente.
¿Cómo puede un agente de IA “escapar” de su propósito original?
A través de inyección de prompt indirecta: el agente procesa datos de una fuente externa (un documento, un log, una web) que contiene instrucciones maliciosas disfrazadas de contenido legítimo. Como el agente ejecuta herramientas automáticamente, puede actuar sobre esas instrucciones antes de que ningún humano lo note. No hay que engañar al usuario, basta con envenenar los datos que el agente consume.
¿Los agentes de IA son seguros si uso proveedores conocidos como OpenAI o Anthropic?
El modelo de lenguaje subyacente importa menos que la arquitectura del sistema completo. Los riesgos documentados por Five Eyes son en gran parte independientes del proveedor del LLM: nacen de cómo se diseña el agente, qué permisos se le asignan y con qué herramientas y datos externos se conecta. Un agente mal configurado sobre un modelo top tier sigue siendo un agente inseguro.
Conclusión
Que cinco agencias de inteligencia de los países más avanzados tecnológicamente del mundo publiquen una guía conjunta diciéndote que frenes antes de deployar agentes de IA no es una postura conservadora de burocratas desconectados. Es una señal de que están viendo incidentes reales o vectores de ataque activos que justifican el nivel de alarma.
Lo que cambió en mayo de 2026 no es la existencia de riesgos en agentes de IA, sino que las agencias de inteligencia más importantes del mundo los documentaron formalmente y le pusieron número: 23 riesgos distintos, 5 categorías, con escenarios de explotación concretos. Eso eleva el estándar mínimo de due diligence para cualquier organización que esté evaluando o ya esté usando estas tecnologías.
¿Eso significa que no hay que usar agentes? No. Significa que si los deployás sin governance, sin least privilege, sin supervisión humana en puntos críticos y sin un plan de rollback, la pregunta no es si algo va a salir mal, sino cuándo.