La seguridad de los agentes está en las transiciones, no en los componentes

¿Qué es esto?

Toward Secure LLM Agents: Threat Surfaces, Attacks, Defenses, and Evaluation (arXiv:2606.10749, publicado en junio de 2026) es una sistematización de 247 artículos sobre seguridad de agentes, organizada en torno a una sola idea de nivel de sistema: un agente LLM no es un chatbot que ocasionalmente llama a una herramienta, es un bucle que conecta flujo de información, autoridad delegada y estado persistente. Una vez que el modelo entra en ese bucle, los fallos dejan de ser «el modelo dijo algo inseguro» para convertirse en flujos de trabajo secuestrados, llamadas a herramientas no autorizadas, memoria corrompida y acciones externas dañinas.

El propio corpus relata la velocidad del fenómeno: 3 artículos en 2023, 42 en 2024 y luego 121 en 2025, con 81 más recopilados antes de finales de abril de 2026 —aproximadamente un tercio del campo aparecido en un solo año parcial—. La mayor parte (alrededor del 68 %) sigue siendo preprints de arXiv, lo que los autores señalan como signo de un área real pero aún no normalizada.

Cómo funciona

La contribución central del estudio es un replanteamiento, no un exploit. Sostiene que la seguridad de los agentes debe analizarse en términos de transiciones de estado y no de componentes aislados. El momento peligroso no es cuando el agente lee texto no confiable, sino cuando se permite que ese texto cambie de categoría sin mediación:

• un contenido no confiable se reinterpreta como una restricción de planificación;
• un plan tentativo se endurece en una decisión ejecutable;
• un rastro almacenado se reutiliza más tarde como contexto de confianza.

Esta perspectiva explica por qué la seguridad de los agentes difiere tanto de la seguridad de aplicaciones clásica como de la seguridad limitada al prompt. La pregunta no es solo qué ha visto el sistema, sino qué se le permite hacer ahora porque lo vio.

El mapa empírico de superficies lo respalda. Al contar las superficies de amenaza en el corpus, los prompts de usuario encabezan con 82 artículos, pero son solo un punto de entrada. El contenido web aparece en 55 artículos, las salidas de herramientas en 54, el contenido recuperado en 37, y los archivos/código, el bucle de planificación, la memoria/borradores y los canales entre agentes en al menos 25 cada uno. El prompt directo es minoritario; dominan las rutas de control mediadas e internalizadas. De ahí se derivan tres principios de modelado: la ambigüedad datos–control (el agente consume texto relevante para la tarea pero no confiable), la autoridad delegada (el agente actúa con permisos que el atacante no posee) y la persistencia y propagación (el daño se retrasa y resurge después a través de la memoria o de mensajes entre agentes).

Sobre todo, no es la teoría de un solo equipo. El AI Red Team de Microsoft, con doce meses de actuaciones contra agentes desplegados, publicó el 4 de junio de 2026 una taxonomía revisada de modos de fallo que nombra de forma independiente la misma frontera: contaminación del contexto de sesión, envenenamiento de memoria por inyección entre dominios, escalada de confianza entre agentes y divulgación de capacidades que convierte el sondeo de caja negra en una ruta de explotación de caja blanca. Dos métodos muy distintos —una síntesis de literatura y red teaming operativo— convergen en la misma conclusión.

Por qué importa

La conclusión principal es incómoda: la inyección de prompts y el secuestro de flujo de control mediado por herramientas siguen dominando, mientras que la corrupción de estado persistente y la propagación multiagente ascienden, y las defensas actuales son débilmente componibles. Las mitigaciones funcionan de forma aislada pero no se apilan limpiamente en una garantía de extremo a extremo. Los datos de campo de Microsoft afilan el punto: la elusión del control humano (human-in-the-loop) fue el modo de fallo más explotado de forma consistente, a veces como cadenas sin clic donde ningún paso parecía anómalo pero el resultado compuesto era exfiltración o movimiento lateral.

El estudio también cuestiona cómo medimos el progreso. Los benchmarks existentes infrarrepresentan los riesgos de largo horizonte, con estado y sensibles al despliegue —precisamente las transiciones que más importan—. Una defensa que puntúa bien en pruebas de inyección de un solo turno aún puede fallar cuando la contaminación se siembra temprano y detona mucho después, a través de una sesión o una cadena de delegación.

Defensas

La prescripción del estudio es arquitectónica y se traduce directamente en controles adoptables ya:

• Haga explícitas las fronteras de confianza. Etiquete cada canal por su autoridad. El contenido web, los documentos recuperados y las salidas de herramientas son observaciones de baja autoridad y nunca deben promoverse en silencio a instrucciones. Separe estructuralmente el contexto de sistema de confianza del contenido recuperado no confiable.
• Controle el privilegio en la acción, no en el prompt. Coloque las comprobaciones de capacidad en la transición de ejecución de herramienta, con privilegio mínimo. Que el modelo decida actuar no es autorización para actuar.
• Gestione el estado con su procedencia. Rastree de dónde provienen las entradas de memoria; trate la memoria escrita por el agente como no confiable al releerla. Una sola inyección exitosa que siembre la memoria puede propagarse a todas las sesiones posteriores, así que sanee y acote lo que se persiste.
• Endurezca el human-in-the-loop como control de seguridad. Descomponga las acciones compuestas antes de aprobarlas, resuma las aprobaciones a partir de las llamadas a herramientas subyacentes en lugar de la descripción del agente, escalone las aprobaciones según la reversibilidad y el radio de impacto, y vigile los patrones de fatiga de consentimiento.
• Verifique la identidad de los agentes, no la infiera. En los sistemas multiagente, exija credenciales atestiguables en los traspasos; rechace los roles autoasignados. Esto cierra la vía del «diputado confundido» de la escalada de confianza entre agentes.
• Evalúe sobre trayectorias completas. Pruebe escenarios de largo horizonte y con estado —siembre la contaminación temprano y mida aguas abajo—, no solo la inyección de un turno. (OWASP LLM01 sigue siendo la referencia básica para la clase de inyección.)

Estado

Elemento	Detalle
Fuente principal	Toward Secure LLM Agents (arXiv:2606.10749), junio de 2026, 247 artículos
Corroboración	Taxonomía de modos de fallo v2.0, AI Red Team de Microsoft, 4 de junio de 2026
Amenazas dominantes	Inyección de prompts, secuestro de flujo de control mediado por herramientas
Frontera emergente	Corrupción de estado persistente, propagación multiagente
Brecha clave	Defensas débilmente componibles; benchmarks que ignoran el riesgo de largo horizonte/con estado
Naturaleza	Sistematización defensiva: sin código de explotación, sin ataque inédito

La lección práctica es un modelo mental, no un parche. Deje de preguntarse solo si su agente puede ser engañado para decir algo y empiece a cartografiar las transiciones de su sistema: entrada a plan, plan a decisión, decisión a acción, acción a memoria almacenada, memoria al siguiente agente. Cada una de esas flechas es un lugar donde datos no confiables pueden cruzar hacia la autoridad. Los laboratorios y la literatura ya coinciden: es asegurando esas flechas, y no endureciendo solo el modelo, donde se gana o se pierde la seguridad de los agentes.