Sleeper Memory Poisoning: ataques latentes contra agentes LLM con memoria

¿Qué es esto?

El 14 de mayo de 2026 (revisado el 18 de mayo), investigadores del CISPA y colaboradores — Sidharth Pulipaka, Stanislau Hlebik, Leonidas Raghav, Sahar Abdelnabi, Vyas Raina, Ivaxi Sheth y Mario Fritz — publicaron Hidden in Memory: Sleeper Memory Poisoning in LLM Agents. El trabajo estudia un riesgo introducido por una función que se ha vuelto estándar en el último año: la memoria persistente, que permite a un asistente almacenar información del usuario entre sesiones para personalización y continuidad.

La contribución principal es caracterizar un ataque diferido que los autores llaman sleeper memory poisoning (envenenamiento de memoria latente). El adversario manipula un contexto externo que el asistente leerá más tarde — un documento, una página web, un repositorio de código — para que almacene una memoria falsa sobre el usuario. A diferencia de una inyección de prompt clásica, que actúa en el momento y desaparece, la memoria implantada puede permanecer latente y reaparecer en numerosas conversaciones posteriores, mucho después de que el contenido malicioso haya salido de la ventana de contexto.

Cómo funciona

El ataque se entiende como una cadena de tres etapas, cada una evaluada por separado en el artículo: escritura, recuperación y acción.

1. Escritura. El asistente de la víctima ingiere contenido controlado por el atacante durante una tarea normal (resumir una página, revisar un repositorio, leer un archivo compartido). En ese contenido se oculta un texto diseñado no para desencadenar una acción inmediata, sino para ser recordado — formulado como un hecho duradero sobre el usuario o sus preferencias. El subsistema de memoria lo confirma en el almacenamiento a largo plazo.
2. Recuperación. En una conversación posterior y sin relación, la etapa de recuperación trae la entrada envenenada como si fuera un hecho de confianza, confirmado por el usuario. La inyección original ya no está presente: los filtros de entrada no tienen nada que inspeccionar.
3. Acción. La memoria falsa dirige el comportamiento del modelo — sesgando respuestas o, en configuraciones agénticas, provocando llamadas a herramientas acordes con la intención del atacante.

Las tasas medidas son llamativas. En asistentes con memoria, las memorias envenenadas se escribieron con éxito hasta el 99,8 % de las veces en GPT-5.5 y el 95 % en Kimi-K2.6. Entre los casos en que una memoria envenenada se recuperó después, produjo acciones agénticas acordes con la intención del atacante en el 60–89 % de las evaluaciones según el modelo. Las cifras son altas porque la etapa de escritura explota exactamente el comportamiento para el que se diseñó la memoria: capturar con avidez todo lo que parezca un hecho útil y duradero.

Un estudio complementario de junio de 2026, From Untrusted Input to Trusted Memory de Dash, Ge, Jain, Shah y Shang, hace explícita la estructura. Identifica cuatro canales de escritura en memoria y nueve debilidades estructurales repartidas entre el comportamiento del modelo, el diseño del prompt de sistema y la arquitectura del agente, organiza los ataques en seis clases y aporta MPBench para medirlos (lo tratamos en MPBench: un mapa común para el envenenamiento de memoria). Su hallazgo central coincide con el resultado sleeper: los agentes ajustados para escribir y recuperar memoria de forma más agresiva son más explotables, y las defensas existentes contra inyección de prompts no cubren el envenenamiento de memoria.

Por qué importa

La memoria convierte una inyección puntual en un punto de apoyo persistente. La propiedad definitoria de la variante sleeper es que la escritura y el beneficio están separados en el tiempo, lo que rompe el modelo mental sobre el que se construyen la mayoría de las defensas. Un equipo puede analizar cada prompt entrante, no encontrar nada y aun así tener un asistente comprometido — porque la instrucción maliciosa se confirmó semanas antes y ahora vive dentro de lo que el sistema considera estado de usuario de confianza.

Es la tríada letal extendida sobre el eje temporal: acceso a datos privados, exposición a contenido no fiable y capacidad de actuar, a lo que se suma la durabilidad. El ataque generaliza la idea de latencia vista en Trojan Hippo y la contaminación temporal de memoria, y se demuestra en asistentes comerciales actuales, no en maquetas. Todo despliegue donde un agente lea contenido de terceros y conserve memoria a largo plazo — asistentes personales, agentes de código con memoria de proyecto, bots de soporte que recuerdan cuentas — hereda esta superficie.

Defensas

Los artículos son diagnósticos, pero apuntan claramente a mitigaciones. Trate la memoria como una frontera de entrada no confiable, nunca como una caché de confianza.

1. Controle el camino de escritura, no solo el de lectura. Los filtros anti-inyección de entrada no se generalizan a la memoria. Añada una comprobación distinta en el momento en que el contenido se confirma en el almacenamiento duradero, y de nuevo en la recuperación.
2. Adjunte procedencia y nivel de confianza a cada entrada. Etiquete cada memoria según su origen (confirmada por el usuario, salida de herramienta, reflexión del modelo) y nunca permita que una nota procedente de un documento o herramienta se recupere con la autoridad de un hecho validado por el usuario.
3. Haga que las escrituras en memoria sean lo menos agresivas posible por defecto. Ambos artículos vinculan las políticas de escritura/recuperación ávidas con una mayor explotabilidad. Exija un umbral de relevancia o confirmación antes de persistir y prefiera el contexto efímero ante la duda.
4. Añada una etapa de confirmación para memorias de alto impacto. Todo lo que pueda luego modificar autorizaciones de herramientas, gastos o el manejo de credenciales no debe poder autoescribirse sin un control humano o de política.
5. Versione y audite la memoria. Como la escritura y la activación están separadas en el tiempo, conserve un rastro de quién o qué escribió cada entrada y cuándo, para poder rastrear una nota envenenada después de que se active — véase la integridad del registro de auditoría de agentes y el guardián de memoria de OWASP para agentes.
6. Evalúe su propio agente. Use MPBench (o su metodología) para enumerar los canales de escritura que su despliegue expone realmente, en lugar de suponer que un solo filtro lo cubre.

Estado

Elemento	Referencia	Fecha	Notas
Hidden in Memory: Sleeper Memory Poisoning	arXiv 2605.15338	2026-05-14 (rev. 05-18)	Define el envenenamiento de memoria diferido/latente; cadena escritura→recuperación→acción
Tasas de escritura exitosa	Resumen del artículo	2026-05-14	Hasta 99,8 % (GPT-5.5), 95 % (Kimi-K2.6)
Tasa de acción agéntica entre recuperaciones	Resumen del artículo	2026-05-14	60–89 % según el modelo
From Untrusted Input to Trusted Memory (MPBench)	arXiv 2606.04329	2026-06-03	4 canales de escritura, 9 debilidades, 6 clases; las defensas PI no cubren la memoria

La conclusión no es que el envenenamiento de memoria sea totalmente nuevo — es que el encuadre sleeper muestra con qué limpieza el ataque se oculta en el tiempo, y las tasas medidas en asistentes reales demuestran que no es hipotético. Si su agente tiene memoria persistente y su única defensa es un filtro de prompt de entrada, asuma que no está cubierto.

Este artículo resume investigación públicamente disponible con fines defensivos y educativos. No reproduce ningún código de explotación.