La seguridad de los agentes es un problema de sistema: tratar al modelo como no confiable

¿Qué es esto?

El 18 de mayo de 2026, un grupo de investigadores de Google, UC San Diego, la Universidad de Wisconsin–Madison, Meta FAIR, Cornell y EmbraceTheRed publicó un position paper titulado Agent Security is a Systems Problem (arXiv:2605.18991, licencia CC BY 4.0). Su tesis cabe en una frase: el modelo de IA que impulsa a un agente debe tratarse como un componente no confiable, y las invariantes de seguridad deben imponerse en el sistema que lo rodea, no dentro del modelo.

Ese encuadre rompe deliberadamente con el enfoque dominante, que convierte al modelo en el objeto primario de la seguridad e intenta hacerlo robusto mediante alineamiento y entrenamiento. Los autores —entre ellos nombres reconocidos en ML adversario y seguridad de sistemas— recuerdan que es la misma apuesta que el campo ya perdió una vez, en la era del «ML adversario clásico» de los modelos de visión, donde las defensas basadas en el modelo fueron evadidas una y otra vez. El artículo fue recogido en la recopilación agéntica de junio de 2026 de Adversa AI entre las lecturas destacadas del mes.

Cómo funciona

El artículo traslada décadas de doctrina de seguridad de sistemas a los agentes. La arquitectura de referencia que utiliza tiene cuatro partes: una base de cómputo de confianza (TCB) cuya integridad el atacante no puede afectar, una política de seguridad que declara lo permitido, un monitor de referencia dentro de la TCB que verifica cada solicitud contra esa política, y un sistema no confiable al otro lado de una frontera de seguridad. Sobre ese esqueleto, los autores reformulan cinco principios que los agentes violan habitualmente:

Principio	Lo que exige
Mínimo privilegio	Un componente recibe solo los permisos que su tarea necesita, y nada más
Resistencia a la manipulación de la TCB	El núcleo de confianza no puede ser modificado por una entrada no confiable
Mediación completa	Toda solicitud que cruza la frontera se verifica — ninguna evade el monitor
Flujo de información seguro	Los datos sensibles no deben filtrarse a destinos no confiables, ni siquiera por canales laterales
Eslabón humano débil	Los mecanismos deben suponer que usuarios, administradores y desarrolladores cometerán errores

Para demostrar que el argumento es descriptivo y no abstracto, los autores analizan once ataques reales, ya públicos contra agentes en producción y asocian cada uno con los principios que quebrantó. La lista se lee como un registro de incidentes de 2025–2026: exfiltración vía Microsoft Copilot, «AgentFlayer» en Cursor, exfiltración vía Claude Code, puertos expuestos y fugas de secretos de Devin AI, «SpAIware» en la memoria a largo plazo de ChatGPT, prompt injection en ChatGPT Operator, toma de control de cuenta en DeepSeek, Terminal DiLLMa, ejecución de comandos arbitrarios en Amp y «AI ClickFix». En la Tabla 1 del artículo, cada uno viola el Flujo de información seguro, y la mayoría infringe dos o más principios a la vez — ahí está el punto: no son once errores inconexos, sino una única arquitectura ausente observada once veces.

Dos de sus ejemplos detallados son ilustrativos sin ser accionables. En el caso de la memoria de ChatGPT, una inyección de prompt indirecta alojada en un documento no confiable escribió instrucciones del atacante en el almacén «Memorias» —supuestamente de confianza— de la aplicación (fallo de resistencia a la manipulación de la TCB), la aplicación podía contactar servidores arbitrarios al margen de la solicitud del usuario (mínimo privilegio), y los datos de conversación se filtraron luego a través de la URL de una imagen renderizada (flujo de información). En el caso de Claude Code, una instrucción inyectada en un archivo de código hizo que el agente leyera un archivo .env y exfiltrara el secreto mediante un ping incluido en la lista blanca, cuya resolución DNS transportaba el dato — el agente tenía un acceso de shell más amplio del que la tarea requería, y un dato sensible llegó a un resolutor no confiable.

La mitad más difícil del artículo explica por qué esto no se arregla fácilmente. Los agentes no encajan limpiamente en la arquitectura clásica. Una aplicación tradicional es de propósito único: un desarrollador puede escribir una política fija en el momento de la instalación. Un agente recibe un objetivo abierto en lenguaje natural, compone herramientas en tiempo de ejecución, sigue enlaces que descubre y refina tareas subespecificadas sobre la marcha — por eso su política es difusa, dinámica y expresada en prosa. Los autores lo comparan con la carga dinámica de código en la web, que el navegador domesticó con la Content Security Policy, la Same-Origin Policy, el aislamiento de <iframe> y la Subresource Integrity. Los agentes carecen de todo eso: la procedencia de una instrucción es difícil de establecer, y el aislamiento mediante mecanismos como la Instruction Hierarchy es probabilístico en el mejor de los casos. Peor aún, usar un «LLM de seguridad» como monitor de referencia reintroduce el problema del que se intentaba huir: una TCB probabilística, sin contrato formal, ella misma atacable.

Por qué importa

Este artículo es un marco, no una solución, y ahí reside su valor. Si se acepta que la separación entre instrucciones y datos basada en el modelo «siempre será evadida por atacantes persistentes» —la conjetura explícita de los autores, coherente con el triángulo letal y los argumentos de integridad contextual sobre la prompt injection— entonces invertir únicamente en un modelo más robusto es una mala asignación de presupuesto. La palanca está en el andamiaje alrededor del modelo.

El artículo también ofrece a los defensores un vocabulario común. «Nuestro agente sufrió prompt injection» da poco margen de acción; «este incidente violó el Mínimo privilegio y el Flujo de información seguro, y nuestro monitor de referencia no tenía mediación completa sobre la herramienta ping» indica exactamente qué control construir. La tabla de los once ataques convierte un año de titulares en una lista de modos de fallo que probar en el propio despliegue.

El artículo concluye nombrando tres problemas de investigación que reconoce sin resolver: (1) la separación demostrable de instrucciones y datos (el análogo agéntico de la protección de memoria W⊕X, probablemente necesaria pero no suficiente); (2) la generación verificable de políticas —traducir una intención difusa en lenguaje natural a una política formal de mínimo privilegio que un monitor determinista pueda imponer, con garantía de corrección; y (3) el control de flujo de información capaz de separar las fuentes de datos una vez que el LLM las ha mezclado en su contexto. Ninguno está disponible hoy. Considere cualquier discurso «a prueba de prompt injection» como una exageración del estado del arte.

Defensas

La receta del artículo es defensa en profundidad implementada fuera del modelo. En concreto:

1. Trate al modelo como no confiable por defecto. Suponga que toda entrada que el agente ingiere —documentos, páginas web, salidas de herramientas, eventos de calendario, notificaciones— puede portar instrucciones hostiles, y que el modelo puede seguirlas. Diseñe de modo que un modelo comprometido quede contenido, no resulte catastrófico. Esto coincide con la postura de «tratar al agente como un proceso».

2. Imponga el mínimo privilegio por tarea, no por sesión. El caso del ping de Claude Code es un fallo de mínimo privilegio: el agente conservaba un acceso de shell amplio en un momento en que la tarea no lo requería. Limite el acceso a herramientas al subobjetivo actual y revóquelo después. Véase el patrón de la regla de dos como restricción práctica.

3. Coloque un monitor de referencia determinista en la ruta de toda acción consecuente. Busque la mediación completa: la red saliente, las escrituras de archivos, la ejecución de shell y la lectura de secretos deben cruzar un mismo punto de control que consulte una política explícita. Evite hacer de un LLM el único árbitro de esa decisión.

4. Añada controles de flujo de información en la salida. La mayoría de los once ataques terminaba en un canal de exfiltración. Etiquete las fuentes sensibles, y bloquee o sanee los flujos desde datos de alta confianza hacia destinos de baja confianza — URLs de imágenes renderizadas, consultas DNS, webhooks, HTTP saliente. Es también el espíritu de medidas de los proveedores como el bloqueo de exfiltración de OpenAI.

5. Diseñe para el eslabón humano débil. Una solicitud de aprobación que tergiversa lo que se aprueba, o que aparece con tanta frecuencia que el usuario la acepta de forma automática, no es un control. Reserve la revisión humana para acciones de gran radio de impacto y haga que el aviso describa lo que realmente va a ocurrir.

6. No espere a las piezas no resueltas. La separación demostrable instrucciones/datos, la generación verificable de políticas y el control de flujo completo son problemas de investigación. Mientras tanto, compense con fronteras toscas pero deterministas: ejecución en sandbox, listas blancas de red impuestas por debajo del agente, y credenciales de mínimo privilegio.

Estado

Elemento	Referencia	Fecha	Notas
Position paper publicado	arXiv:2605.18991v1 [cs.CR]	2026-05-18	Google, UCSD, UW–Madison, Meta FAIR, Cornell, EmbraceTheRed; CC BY 4.0
Ataques reales analizados	Artículo §2.2 + Apéndice A	2024–2026	11 casos representativos mapeados a 5 principios; todos violan el Flujo de información seguro
Problemas abiertos nombrados	Artículo §3	2026-05-18	Separación instrucciones/datos, generación verificable de políticas, control de flujo — todos sin resolver
Recogida por la comunidad	Recopilación de Adversa AI de junio de 2026	2026-06-01	Clasificado en «Artículo»: la seguridad de los agentes como problema de sistema, no de modelo

La conclusión no es un ataque nuevo, sino una recategorización. Los incidentes de agentes del último año no son un problema de robustez de modelo que los laboratorios acabarán entrenando, sino un problema de seguridad de sistemas que la disciplina ya sabe razonar — y que aún no ha terminado de ingeniar para los agentes.