MPBench: una taxonomía sistemática del envenenamiento de memoria en agentes LLM

¿De qué se trata?

El 3 de junio de 2026, cinco investigadores — Pritam Dash, Tongyu Ge, Aditi Jain, Tanmay Shah y Zhiwei Shang — publicaron en arXiv (cs.CR/cs.AI) From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents. No es un ataque nuevo, sino una sistematización: el artículo recoge los resultados dispersos sobre envenenamiento de memoria publicados en los últimos dos años, los organiza en una taxonomía y entrega un banco de pruebas, MPBench, para medirlos.

El envenenamiento de memoria consiste en que un agente trata una entrada no confiable como si fuera memoria de largo plazo fiable. La idea central del artículo: una sola escritura adversaria puede influir de forma duradera en el comportamiento posterior del agente, mucho después de que termine la conversación que la depositó. Mientras que la inyección de prompt es un secuestro puntual del turno actual, el envenenamiento de memoria es un secuestro que persiste entre sesiones. Es el primer intento publicado de cartografiar esta superficie de forma metódica en lugar de exploit por exploit.

Cómo funciona

El artículo descompone el problema en tres ejes. Aquí no se reproduce ningún payload; la referencia canónica es el PDF de arXiv.

Eje 1 — CANALES DE ESCRITURA (4)
  Cómo el contenido no confiable llega a la memoria durable:
  - turnos de conversación guardados en el almacén de largo plazo
  - salidas de herramientas / recuperación reescritas como "experiencia"
  - pasos de resumen o reflexión que destilan la entrada en notas
  - escrituras de memoria explícitas emitidas por el usuario o el agente

Eje 2 — VULNERABILIDADES ESTRUCTURALES (9)
  Por qué esos canales son explotables, agrupadas en:
  - capacidades del modelo (no distingue datos de instrucciones de forma fiable)
  - diseño del system prompt (sin procedencia ni etiquetas de confianza)
  - arquitectura del agente (políticas de escritura/lectura agresivas, sin revisión)

Eje 3 — CLASES DE ATAQUE (6)
  Seis familias de envenenamiento derivadas de la matriz canal × debilidad

Dos hallazgos importan sobre todo a los profesionales. Primero, la agresividad es un riesgo: los agentes ajustados para escribir y recuperar memoria con más avidez — el mismo ajuste que los hace sentir “inteligentes” y personalizados — resultaron más explotables en MPBench. La perilla de la comodidad es también la del riesgo. Segundo, y más contundente: los autores prueban las defensas anti-inyección existentes y constatan que no cubren el envenenamiento de memoria. Un filtro que inspecciona el prompt actual no tiene nada que decir sobre una nota maliciosa escrita en memoria días antes y recuperada como contexto de confianza.

Esto enlaza con ataques ya documentados por la comunidad — por ejemplo AgentPoison, que ya en 2024 mostró el envenenamiento de memoria y bases de conocimiento de agentes — y con nuestra cobertura previa sobre la categoría ASI06 de OWASP, la exfiltración de memoria latente y la contaminación temporal de la memoria. Lo que aporta 2606.04329 es el tejido conectivo: un vocabulario común y un instrumento de medición.

Por qué importa

La memoria es ahora una función por defecto, no un juguete de laboratorio. Los productos de asistente incorporan memoria persistente, los frameworks de agentes reescriben “experiencias” en almacenes vectoriales, y los pipelines RAG difuminan la frontera entre dato recuperado e instrucción. Cada uno de esos casos es un canal de escritura en el sentido del artículo.

La implicación defensiva es incómoda. La mayoría de los equipos que adoptaron en 2025 un filtro anti-inyección del lado de la entrada supusieron implícitamente que se generalizaba. Este artículo es la prueba de que no. Una memoria envenenada es, por construcción, de confianza en el momento en que se lee: ya ha cruzado la frontera de confianza que el filtro debía proteger. La exposición también es asimétrica en el tiempo: la escritura y el disparo pueden estar separados por días o sesiones, lo que derrota la monitorización por petición y complica el análisis forense, ya que el turno malicioso pudo haber desaparecido de los registros.

Una taxonomía y un banco de pruebas son exactamente lo que este campo necesitaba. Permiten plantear preguntas concretas — cuál de los cuatro canales expone mi agente, cuál de las seis clases puedo reproducir contra mi propia pila — en lugar de discutir anécdotas.

Defensas

El artículo es diagnóstico más que prescriptivo, pero su estructura señala directamente las mitigaciones. Trate la memoria como una frontera de entrada no confiable, no como una caché de confianza.

1. Etiquete la procedencia de cada elemento almacenado. Marque las entradas de memoria con su fuente (usuario, salida de herramienta, reflexión del modelo) y su nivel de confianza, y nunca permita que una nota originada en una herramienta o documento se recupere con la misma autoridad que una instrucción verificada.
2. Filtre el camino de escritura, no solo el de lectura. Los filtros anti-inyección del lado de la entrada no se generalizan a la memoria; añada un control distinto en el momento en que el contenido se escribe en el almacén durable, y otro en la recuperación.
3. Haga que las escrituras de memoria sean lo menos agresivas posible por defecto. El hallazgo de MPBench es explícito: las políticas ávidas de escritura/lectura son más explotables. Exija un umbral de relevancia o revisión antes de persistir, y prefiera el contexto efímero a la memoria durable en caso de duda.
4. Añada una revisión humana o por política para las escrituras de alto impacto. Una memoria que pueda modificar futuras autorizaciones de herramientas, el manejo de credenciales o decisiones de gasto no debe ser auto-escribible sin control.
5. Conserve y versione la memoria para la forensia. Como la escritura y el disparo están desfasados en el tiempo, mantenga un registro de auditoría de quién/qué escribió cada entrada y cuándo, para rastrear una nota envenenada a posteriori. Véase nuestra nota sobre la integridad de los registros de agentes.
6. Evalúe su propio agente. Use MPBench (o su metodología) para enumerar qué canales de escritura y clases de ataque expone realmente su despliegue, en vez de suponer que un solo filtro lo cubre todo.

Estado

Elemento	Referencia	Fecha	Notas
arXiv 2606.04329 v1	arXiv (cs.CR/cs.AI)	2026-06-03	Enviado; estudio sistemático + banco MPBench
Cuatro canales / nueve debilidades / seis clases	Resumen del artículo	2026-06-03	Taxonomía modelo, prompt, arquitectura
«Memoria agresiva ⇒ más explotable»	Hallazgo del artículo	2026-06-03	Medido en MPBench
«Las defensas anti-inyección no cubren el envenenamiento de memoria»	Hallazgo del artículo	2026-06-03	Brecha clave para los despliegues existentes
Trabajo fundacional (AgentPoison)	arXiv 2407.12784	2024	Ataque previo de envenenamiento de memoria/base de conocimiento

La conclusión correcta no es «el envenenamiento de memoria es nuevo» — no lo es. Es que el campo dispone por fin de un mapa común y una regla graduada. Si su agente tiene memoria persistente y su única defensa es un filtro del lado de la entrada, este artículo es la razón documentada para suponer que no está cubierto, y una forma estructurada de encontrar dónde están los huecos.

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