Envenenar una vez, explotar para siempre: envenenamiento persistente de la memoria de los agentes LLM (OWASP ASI06)
Un paper de arXiv de abril de 2026 sobre memory poisoning entre sitios y un post de OWASP del 13 de mayo de 2026 sobre el hallazgo MemoryTrap de Cisco contra Claude Code convergen en la misma lección: la memoria del agente es una frontera de confianza.
What is this?
Tres publicaciones de abril y mayo de 2026 han convertido el envenenamiento de la memoria de agentes de preocupación teórica en una clase de ataque documentada con una etiqueta equivalente a un CVE. El OWASP Gen AI Security Project la formalizó como ASI06: Memory & Context Poisoning en su Top 10 for Agentic Applications de 2026. El 13 de mayo de 2026, Idan Habler, co-líder de la entrada ASI06 en Cisco, publicó Memory Is a Feature. It Is Also an Attack Surface en el blog de OWASP, articulando la categoría en torno a un hallazgo concreto de Cisco — MemoryTrap — contra Claude Code, divulgado el 1 de abril de 2026 y parcheado por Anthropic en Claude Code v2.1.50. Dos días antes, el 3 de abril de 2026 (revisión del 7 de abril), Wei Zou y sus coautores en Amazon AWS publicaron Poison Once, Exploit Forever: Environment-Injected Memory Poisoning Attacks on Web Agents en arXiv (2604.02623, cs.CR), demostrando la misma clase contra los navegadores agénticos — OpenClaw, ChatGPT Atlas, Perplexity Comet — sin ningún acceso directo a la memoria.
La tesis común a las tres fuentes es sencilla: un agente que retiene contexto es un agente cuyo pasado se ha convertido en parte de su plano de control actual. Una vez que un atacante escribe en ese pasado, cada sesión futura hereda el compromiso. La ola de investigación de 2026 demuestra que esto no es un caso marginal.
How it works
La memoria de los agentes LLM actuales vive en varios lugares que parecen benignos desde el punto de vista del desarrollador: un fichero memory.json, un vector store de trayectorias pasadas, un CLAUDE.md o SKILL.md, una configuración global de hooks, una caché de conversación resumida. El objetivo del atacante es colocar tokens bajo su control en cualquiera de esas superficies, de modo que el runtime los trate como confiables en un turno posterior.
Tres patrones de ataque recientes ilustran la superficie.
MemoryTrap (Cisco, 1 de abril de 2026). Un usuario clona un repositorio y le pide a Claude Code que lo configure. Claude ofrece proactivamente instalar los paquetes npm necesarios; el script postinstall malicioso escribe un payload en el archivo de memoria persistente del usuario, en la configuración global de hooks y — antes del parche — en una capa que el agente cargaba directamente en su system prompt. En la sesión siguiente, en otro proyecto, el agente sigue confiando en ese texto como si lo hubiera enviado la propia Anthropic. La corrección de Anthropic en Claude Code v2.1.50 retira las user memories del system prompt, cerrando la vía de mayor confianza; el patrón más amplio permanece.
eTAMP / Poison Once, Exploit Forever (Amazon AWS, 3 de abril de 2026). Modelo de amenaza más fuerte: el atacante no tiene ningún acceso a la memoria. Modifica una sola observación en el entorno — una ficha de producto, un hilo de foro, un mensaje de error falso — que el agente web simplemente consulta. El agente almacena esa trayectoria como una memoria útil de “así suele ir este tipo de tarea” y, en otro sitio en una sesión futura, la recupera. Las tasas de éxito alcanzan el 32,5 % en GPT-5-mini, 23,4 % en GPT-5.2, 19,5 % en GPT-OSS-120B sobre (Visual)WebArena. Un hallazgo secundario — la Frustration Exploitation — multiplica la tasa de éxito hasta 8x cuando el agente ya tiene dificultades con clics perdidos o una UI corrupta. Los modelos más capaces no son más seguros.
MINJA (arXiv 2503.03704, marzo de 2025). El resultado seminal anterior, conservado aquí porque sigue siendo la demostración más limpia: un usuario corriente, solo con sus consultas, lleva al agente a escribir una memoria puente que conecta sus futuras consultas benignas con pasos de razonamiento elegidos por el atacante. Se reporta un 98,2 % de éxito de inyección, 76,8 % de ataque downstream bajo el modelo de amenaza del paper.
Layer Where it lives Trust assumed by runtime
------------------- ------------------------------ ----------------------------
Persistent memory memory.json, vector store Treated as past first-party
System-prompt CLAUDE.md / user memories Loaded high-authority
Hooks / config global hooks, shell profiles Executed silently
Retrieved context RAG store, summaries Mixed into next prompt
Why it matters
Tres propiedades hacen que esta clase sea más difícil que el prompt injection clásico.
Primero, la persistencia. Una inyección estándar muere con la sesión. Una inyección de memoria sobrevive hasta que alguien limpia el store manualmente — y rara vez hay una UI para ello. El paper eTAMP muestra que la activación puede darse en un sitio diferente días después, exactamente el tipo de fuga entre contextos que las defensas basadas en permisos nunca se diseñaron para detectar.
Segundo, el blanqueo de confianza. El runtime no distingue fácilmente la memoria escrita por el atacante de la escrita por el usuario. Ambas llegan por la misma vía de escritura; ambas parecen contexto first-party al leerse. Esa es la crítica estructural detrás de ASI06: los stacks agénticos ya separan los prompts de los desarrolladores de la entrada del usuario, pero no tienen un equivalente para las escrituras en memoria.
Tercero, la superficie de ataque crece con la capacidad. La memoria está llegando como feature a cada producto agéntico de primer nivel: Claude Code, ChatGPT memories, los nuevos “browser agents” (OpenClaw, ChatGPT Atlas, Perplexity Comet) estudiados en el paper eTAMP. Cada nueva superficie de memoria es una nueva línea de la frontera de confianza que los defensores quizá ignoren.
Defenses
ASI06 es lo bastante reciente como para que ninguna mitigación individual cierre la clase. La lista defensiva más corta, extraída de la entrada de OWASP y de los tres papers anteriores:
- Tratar las escrituras de memoria como no confiables por defecto. La decisión de confianza no debe tomarse al escribir, sino al leer, con un runtime capaz de marcar la procedencia de cada entrada (emitida por el usuario, salida de tool, observación de entorno) y una política que decida qué puede ascender a contexto de alta autoridad.
- Sacar las user memories del system prompt. Es la corrección concreta que envió Anthropic en Claude Code v2.1.50. La memoria puede seguir informando al modelo sin ocupar la misma capa que define el rol y las reglas del agente.
- Poner en cuarentena las observaciones derivadas del entorno. Distinguir lo que el agente vio de lo que el agente decidió recordar. Etiquetar las observaciones por URL/dominio de origen; nunca permitir que una observación de
example-shop.commodele el comportamiento enexample-bank.com. - Hacer auditables las escrituras de memoria. Un registro de memoria diffeable — visible para el usuario, firmable por el runtime — convierte un canal de persistencia silencioso en uno revisable. El proyecto OWASP Agent Memory Guard es la vía de implementación de referencia para este control.
- Limitar y revisar las escrituras de hooks. El camino MemoryTrap pasaba por hooks globales y
npm postinstall. Una escritura de hook por parte del agente debería requerir una confirmación humana explícita, y el system prompt nunca debería cargar a ciegas archivos de hooks escritos durante la misma sesión. - Probar las fugas entre sesiones y entre sitios. Las suites estándar de regresión de prompt injection se detienen en la frontera de la sesión. Las suites conscientes de ASI06 deben ejecutar un ataque en la sesión N y verificar la activación en la sesión N+k sobre otra superficie.
- Acotar el radio de impacto con scoping de capacidades. Incluso cuando una memoria envenenada gana en la lectura, una ejecución acotada por capacidades — ACL por skill, sin credenciales ambientales, allowlist de salida — limita lo que el atacante puede hacer con ella.
Status
| Ítem | Referencia | Fecha | Notas |
|---|---|---|---|
| Post de encuadre OWASP | OWASP Gen AI Security Project | 2026-05-13 | Idan Habler (Cisco), co-líder de la entrada ASI06 |
| Paper eTAMP | arXiv:2604.02623 v2 | 2026-04-07 | hasta 32,5 % de ASR en GPT-5-mini, entre sitios |
| Divulgación MemoryTrap | Cisco AI Blog | 2026-04-01 | parcheado en Claude Code v2.1.50 |
| Paper MINJA | arXiv:2503.03704 | 2025-03 | 98,2 % de inyección / 76,8 % de ataque |
| Entrevista a Habler | Help Net Security | 2026-04-14 | Agentic AI memory attacks spread across sessions and users |
| Categoría | OWASP Top 10 for Agentic Apps | 2025-12 → 2026 | ASI06: Memory & Context Poisoning |
La memoria es lo que hace que un agente sea personal. También es lo que hace que una sola mala observación sobreviva a la sesión en la que aterrizó. Las publicaciones de abril y mayo de 2026 anteriores no inventan un exploit nuevo: explicitan el coste de seguir ignorando uno viejo.
Sources
- → https://arxiv.org/abs/2604.02623
- → https://arxiv.org/html/2604.02623v2
- → https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface/
- → https://blogs.cisco.com/ai/identifying-and-remediating-a-persistent-memory-compromise-in-claude-code
- → https://arxiv.org/abs/2503.03704
- → https://www.helpnetsecurity.com/2026/04/14/idan-habler-cisco-agentic-ai-memory-attacks/