Ataques al flujo de control por memoria: cuando la memoria dirige las herramientas de un agente
Un artículo de marzo de 2026 muestra que la memoria envenenada de un agente no solo corrompe el contenido: secuestra el flujo de control de la selección de herramientas, forzando herramientas no deseadas y pasos omitidos en más del 90 % de los ensayos, entre tareas y mucho después de la inyección.
¿Qué es esto?
El 16 de marzo de 2026, Zhenlin Xu, Xiaogang Zhu, Yu Yao, Minhui Xue y Yiliao Song publicaron From Storage to Steering: Memory Control Flow Attacks on LLM Agents (arXiv:2603.15125, cs.CR). El artículo nombra una clase de ataque que los autores llaman Memory Control Flow Attacks (MCFA) — ataques al flujo de control por memoria.
La mayoría de los trabajos publicados sobre la memoria de los agentes —incluidos los casos tratados en el envenenamiento de memoria de agentes (ASI06) y MemMorph— abordan la memoria envenenada como un problema de contenido: el agente recupera un dato erróneo y produce una respuesta incorrecta. MCFA reformula la amenaza. Los autores demuestran que la memoria recuperada actúa como una entrada de control: no solo cambia lo que el agente dice, sino qué herramientas invoca el agente y en qué orden —incluso cuando el usuario da instrucciones explícitas y seguras—. La memoria se convierte, en sus palabras, en una «señal de control escrita una vez, leída muchas veces».
Cómo funciona
Un agente con memoria ejecuta un bucle: Leer memoria → Planificar la secuencia de herramientas → Ejecutar → Escribir nueva memoria. MCFA ataca el enlace Leer→Planificar. El atacante no necesita ningún privilegio interno: no puede editar el prompt del sistema, ni cambiar el código de las herramientas, ni tocar directamente el almacén de memoria, ni instalar herramientas. Solo interactúa normalmente con el agente y, en una o pocas conversaciones, logra que almacene una «preferencia» o «regla» orientada a la acción en la memoria a largo plazo. Más tarde, durante una tarea benigna no relacionada, esa memoria se recupera y dirige la traza de herramientas.
El artículo formaliza cinco familias de ataque (aquí no se reproduce ningún payload explotable; véase el apéndice del artículo para el protocolo):
Familia Efecto en la traza de llamadas a herramientas
------------ -------------------------------------------------------------
Override Una "preferencia" recuperada fuerza una herramienta
riesgosa/no deseada en la traza, eludiendo los filtros de
seguridad estáticos.
Order Se reordenan u omiten pasos — p. ej. un paso Audit requerido
se omite antes de un paso Transfer. Invisible para las
defensas por lista blanca, que solo verifican *qué*
herramientas, no el orden.
M-Scope La regla inyectada se generaliza a tareas no relacionadas,
actuando como una "llave maestra" entre dominios.
Persistence La desviación sigue activándose mucho después de la
inyección, sin reinyección.
Relapse Las instrucciones explícitas de "detente / corrige" fallan;
el estado de memoria envenenado resiste la corrección textual.Para medir esto a escala, los autores construyeron MemFlow, un marco automatizado que operacionaliza cada ataque como inyectar memoria maliciosa → recuperarla durante tareas benignas → auditar las desviaciones del flujo de control. Lo ejecutaron contra GPT-5 mini, Claude Sonnet 4.5 y Gemini 2.5 Flash, con herramientas reales de LangChain y LlamaIndex.
Por qué importa
Las cifras son altas y consistentes entre modelos. Más del 90 % de los ensayos fueron vulnerables a MCFA, incluso bajo restricciones de seguridad estrictas. Los overrides de elección de herramienta aparecieron en el 91,7–100 % de los ensayos, el reordenamiento de flujos en el 52,8–69,4 %, la expansión de alcance entre tareas en el 97,2–100 %, con una persistencia del 100 % observada en horizontes largos.
Dos propiedades lo hacen peor que una inyección de prompt puntual. Primero, la persistencia y el alcance entre tareas: una sola interacción de envenenamiento sigue dirigiendo tareas futuras y no relacionadas —el usuario que desencadena el mal comportamiento puede no ser quien lo plantó—. Segundo, la familia Order derrota la lógica de lista blanca. Muchas barreras en producción verifican si una herramienta puede ejecutarse; MCFA reordena u omite herramientas legítimas y permitidas (omitir la auditoría, luego transferir), de modo que cada llamada por separado parece permitida. Es el problema de la trifecta letal desplazado al planificador: contenido no confiable que llega a la memoria ahora influye en la selección de acciones, no solo en la salida.
La frontera de confianza a recordar: todo lo que una parte externa pueda hacer escribir en la memoria a largo plazo debe tratarse como una entrada controlable por el atacante para el planificador, y no como un estado de usuario confiable.
Defensas
Los autores prueban una mitigación de tipo producción y son explícitos en que no es una solución milagrosa: más de la mitad de los escenarios evaluados aún mostraban más del 85 % de desviación del flujo de control tras aplicarla. La defensa aquí es por capas, no un interruptor único.
-
Segregación de memoria por rol (RBMS). La mitigación del propio artículo: separar las reglas del sistema de las preferencias del usuario en canales distintos y aplicar una jerarquía de prioridad explícita, para que la memoria de usuario accesible al atacante nunca pueda superar la política del sistema. Reduce el éxito de los ataques pero no lo elimina; trátese como un piso, no un techo.
-
Convertir el flujo de control en un objeto de política, no en algo emergente. Defina el orden de herramientas requerido para los flujos sensibles (p. ej. Audit debe preceder a Transfer) y aplíquelo de forma determinista fuera del modelo. La familia Order es invisible para las listas blancas precisamente porque estas ignoran la secuencia y las dependencias.
-
Tratar la memoria recuperada como no confiable en el momento de la recuperación. Aplique etiquetas de procedencia a las entradas de memoria (quién/qué la escribió, desde qué canal) y rechace que las memorias del canal de usuario introduzcan o reordenen herramientas en trazas críticas de seguridad. Combine con comprobaciones de coherencia entre memorias relacionadas, como en A-MemGuard y los patrones de la guía de OWASP sobre memoria de agentes.
-
Auditar la traza, no solo la salida. MCFA se define como una desviación auditable en la traza de llamadas a herramientas. Registre la secuencia completa de herramientas por tarea y alerte sobre trazas que violen las dependencias declaradas o incluyan herramientas riesgosas —es observable incluso cuando la respuesta final parece correcta—.
-
Probar la persistencia y la recaída. Como un comportamiento corregido puede recaer, las pruebas de seguridad deben inyectar y luego ejecutar tareas posteriores y no relacionadas, verificando que la desviación realmente desapareció —no solo que está ausente en el siguiente turno—. Benchmarks como AgentDojo ofrecen un punto de partida para la evaluación a nivel de traza.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Artículo MCFA / MemFlow | arXiv:2603.15125 | 2026-03-16 | Define MCFA, 5 familias de ataque, marco MemFlow |
| Modelos evaluados | Artículo §4 | 2026-03-16 | GPT-5 mini, Claude Sonnet 4.5, Gemini 2.5 Flash |
| Frameworks probados | LangChain, LlamaIndex | 2026-03-16 | Herramientas reales, no mocks |
| Mitigación (RBMS) | Artículo §4.5 | 2026-03-16 | Reduce el ASR; >85 % de desviación aún en >la mitad de los escenarios |
| Defensa relacionada | A-MemGuard, arXiv:2510.02373 | 2025-10 | Validación por consenso + memoria de «lecciones» |
Es un hallazgo de investigación, no un CVE ni un incidente en el mundo real: no hay un parche del proveedor que instalar. La lección accionable es arquitectónica: si despliega un agente con memoria persistente y uso de herramientas, asuma que partes externas pueden plantar señales de control en esa memoria, y coloque el flujo de control de los flujos sensibles bajo una política determinista que usted controle, en lugar de bajo el planificador del modelo.