¿Puedes confiar en la memoria de tu agente IA? Envenenamiento distribuido en RAG y privacidad reconstruible

TL;DR

La memoria persistente de agentes (Mem0, Letta, Zep, los checkpointers de LangGraph) se vende como feature premium de personalización. Casi nadie la vende con gobernanza, y sin gobernanza es una superficie de ataque con efecto retardado.
Un paper presentado en un workshop de ESORICS 2026 muestra un envenenamiento distribuido que reparte una afirmación falsa entre documentos inofensivos por separado: la revisión documento a documento casi no lo detecta (arXiv 2609.21573).
Un RAG que inyecta memorias sin filtrar cuando el store tiene posiciones en conflicto amplifica alucinaciones, no las reduce. Decidir si lo recuperado merece confianza cuesta unos 0,14 ms por decisión (arXiv 2609.22043).
Lo que guardas etiquetado como privado no es lo que un observador externo puede reconstruir. En el framework CIPL, la memoria de un agente es el caso casi saturado de fuga recuperable (arXiv 2609.21686).
El mercado ya responde: tres CVEs parcheados en el checkpointer de LangGraph y backup/rollback de memoria de agente por parte de Cohesity (solo Bedrock, GA prevista para fin de 2026). Al final, un checklist de higiene aplicable esta semana.

Contexto: el cuaderno que nadie audita

Piensa en un agente con memoria como en un asistente que lleva un cuaderno. Cada vez que completa una tarea, apunta algo útil para consultarlo más adelante. Ahora imagina que alguien cuela una instrucción falseada en ese cuaderno sin tomar el control del agente: este sigue funcionando con normalidad durante días o varias interacciones, hasta que abre el cuaderno, recupera la entrada envenenada y la trata como aprendizaje confiable. Es la analogía que usan los investigadores de la Universidad de Calgary (The Conversation, septiembre de 2026) tras simular 2.614 trayectorias de ataque multi-paso sobre agentes LLM con memoria. Su conclusión operativa: el peligro no es el momento de la inyección, es el retraso, y algunos ataques muestran patrones no monótonos que un test de un solo prompt no captura.

Mientras tanto, la memoria se ha convertido en categoría de producto. Mem0, Letta y Zep la venden como capa de personalización; LangGraph la implementa como checkpointer; los stores de RAG son, a efectos prácticos, memoria documental. Ya escribimos que la memoria de agentes es el nuevo cuello de botella por razones de arquitectura. El problema ha cambiado de forma: ya no es solo cuánto cuesta recordar, es cuánto cuesta confiar en lo recordado. Y Gartner predice que el 40% de las aplicaciones empresariales incorporará agentes específicos por tarea a finales de 2026, desde menos del 5% en 2025 (nota oficial de Gartner, 26-ago-2025). La superficie crece más rápido que la gobernanza.

El ataque que no se ve revisando documentos sueltos

La mayoría de equipos que revisan su RAG busca el documento malicioso: el pasaje con la instrucción oculta, la página envenenada con autoridad falsa. El paper Micro-Collaborative Poisoning (Pereira, Maia y Praça, ISEP/GECAD; workshop de ESORICS 2026, arXiv 2609.21573) propone algo más incómodo: dividir la afirmación falsa entre varios documentos que, aislados, son localmente plausibles. Ninguno contiene el claim completo. Ninguno parece malicioso. La influencia no viene de un pasaje dominante, sino de la acumulación de señales débiles que coinciden en el contexto recuperado.

El paper evalúa 108 configuraciones de RAG variando dataset, arquitectura de retriever, profundidad de retrieval, composición de la base de datos, número de bases envenenadas y modelo generador. Dos hallazgos con consecuencias directas:

Lo que agrava el ataque: subir el top-k y envenenar varias bases de datos aumenta la probabilidad de que las señales débiles aparezcan juntas en el contexto. Si tu arquitectura recupera de múltiples fuentes y junta todo en el prompt, estás facilitando la conspiración.
Lo que lo mitiga: la diversidad limpia de las fuentes y retrievers más fuertes reducen su efecto. La redundancia controlada, no la acumulación indiscriminada.

El análisis de visibilidad es la parte que debería cambiar tu proceso: el ataque deja una firma de envenenamiento más débil que el envenenamiento directo, y la inspección aislada de documentos casi no lo expone. Si tu revisión de seguridad del RAG es “un humano (o un LLM) mira documentos uno a uno”, tu método está diseñado para el ataque equivocado. Ya vimos algo parecido con Phantom Authority y la procedencia en sistemas RAG: el problema nunca fue solo un documento falso, era confiar en la autoridad de lo que llega sin auditar su origen. Aquí el problema es incluso peor: el origen de cada fragmento puede ser impecable.

El problema inverso: memorias en conflicto que amplifican alucinaciones

El segundo paper ataca desde el lado de la defensa. An Interpretable Memory Decision Controller (Zhang et al., arXiv 2609.22043) parte de un dato que debería incomodar a quien monta RAG sobre stores de memoria: cuando el store contiene posiciones en conflicto y el pipeline inyecta lo recuperado sin filtrar, la tasa de alucinación sube por encima de la de un baseline sin memoria en los modelos susceptibles a la inyección de memoria. Tu capa de personalización puede estar empeorando las respuestas.

La propuesta, MDL (Memory Decision Layer), es un controlador de decisión sin parámetros entrenados que se sitúa entre retrieval y generación: codifica tres señales complementarias (relevancia, fiabilidad y riesgo de tarea) más una señal meta de memoria de trabajo, desacopla confidence de consistency, y permite inversión de riesgo y abstención explícita. Cifras del paper: reduce la tasa de alucinación con memorias en conflicto un 56,04% en escenarios generales y se acerca a cero en escenarios de alto riesgo, con un coste de unos 0,14 ms por decisión. Eso es unas 50 veces más rápido que el propio paso de embedding-retrieval que lo precede, y de cuatro a cinco órdenes de magnitud más rápido que pedirle al modelo que autoevalúe lo que recuperó.

Mi lectura: la decisión de “¿confío en esta memoria?” es prácticamente gratis y casi nadie la implementa. El RAG por defecto inyecta y ya. Que un controlador sin entrenamiento, puramente geométrico, recorte a la mitad las alucinaciones bajo conflicto dice menos del genio del paper y más de lo descuidado del patrón dominante. Limitación obvia: son benchmarks de los propios autores sobre datasets open-source, no producción; el número exacto (−56,04%) extrapolado a tu stack es fe, no dato. Lo que sí se sostiene es la dirección: sin chequeo de consistencia previo a la inyección, más memoria puede significar más alucinación.

Lo privado no es lo que crees que es privado

Tercer paper: CIPL: A Channel-Aware Framework for Recoverable Privacy Leakage in LLM Agents (Huang et al., arXiv 2609.21686). Su distinción central es la que falta en la mayoría de auditorías: no es lo mismo lo que el agente expone internamente que lo que un observador externo puede reconstruir. CIPL modela el flujo desde la unidad sensible seleccionada hasta lo que un atacante puede recuperar, y lo evalúa sobre objetivos basados en memoria, mediados por retrieval y mediados por herramientas, más un caso de estudio con un agente de navegador en vivo (BrowserUse).

Conclusiones que duelen:

Las etiquetas del storage no determinan la recuperabilidad. Marcar algo como privado en tu capa de persistencia no dice nada sobre lo que un observador puede reconstruir por otro canal.
La memoria es el caso de referencia casi saturado: en sus experimentos, el observador externo recupera casi todo lo sensible que pasa por la memoria del agente.
La fuga mediada por retrieval suele ser parcial; la mediada por herramientas y la de agente en vivo dependen de la superficie de observación, de la alineación entre prompt y canal, de la profundidad de retrieval y del comportamiento del proveedor.
Una auditoría semántica estratificada encuentra revelaciones útiles para un atacante que el exact-matching canónico no ve. Si tu auditoría de privacidad busca patrones exactos de PII, está midiendo lo fácil.

Para el que diseña agentes: asume que la memoria es, a efectos de fuga, un canal abierto. Lo que le cuentas a tu agente esta semana es reconstruible desde fuera con la metodología adecuada, aunque tu base de datos tenga el label correcto.

El mercado ya responde (con parches y con producto)

Esto dejó de ser teoría de papers hace meses, en dos frentes.

El frente de los CVEs. Check Point Research publicó en junio de 2026 una cadena de vulnerabilidades en el checkpointer de LangGraph, la capa de persistencia que guarda el estado del agente (11-jun-2026; LangGraph mueve ~46,5 millones de descargas mensuales según el propio artículo). La cadena: inyección SQL en el parámetro de filtro de get_state_history(), encadenable con una deserialización msgpack que acaba en ejecución remota de código. Tres CVEs, todos parcheados:

CVE	Problema	Paquete y versión mínima
CVE-2025-67644	Inyección SQL en checkpointer SQLite	langgraph-checkpoint-sqlite ≥ 3.0.1
CVE-2026-28277	RCE por deserialización msgpack	langgraph ≥ 1.0.10
CVE-2026-27022	Inyección en checkpointer Redis	langgraph-checkpoint-redis ≥ 1.0.2

Es explotable en despliegues self-hosted que expongan get_state_history() con un filtro controlado por el usuario sobre backends SQLite o Redis. La plataforma gestionada de LangChain (PostgreSQL) no está afectada. Un servidor comprometido por esta vía expone API keys, historial completo de conversaciones y un punto de apoyo en la red. Nada de esto es “la memoria envenenada por un atacante sofisticado”: es tu capa de memoria siendo el vector de entrada clásico.

El frente del producto. Cohesity presentó Agent Resilience el 16 de septiembre de 2026 (Cohesity Catalyst): snapshot y rollback de la memoria y configuración de agentes con backups inmutables y clean-room recovery. El problema que ataca es real, y su propia encuesta global (con Vanson Bourne) lo cuantifica: el 56% de las organizaciones dice no estar bien preparada para detectar o contener acciones no intencionadas de agentes IA. Pero los matices importan y el marketing no los pone: hoy solo cubre Amazon Bedrock (AgentCore y Bedrock Agents), está disponible para clientes seleccionados, la GA está prevista para fin de 2026, y Microsoft y Google están “en el roadmap”. No hay evaluaciones de terceros. Y el límite de fondo lo señaló la prensa especializada: restaurar la memoria del agente a este martes no deshace lo que el agente escribió el miércoles en bases de datos compartidas. El rollback del cuaderno no deshace las acciones ejecutadas con lo que había en el cuaderno.

La ola, además, sigue activa: esta misma semana la prensa cubría GhostWriter (arXiv 2607.06595, New Mexico State University), un ataque en dos fases contra agentes personales con herramientas que inyecta memoria envenenada vía prompts ocultos, con tasas de inyección de ~98% y activación de ~60% en los agentes de última generación que los autores probaron. Su contramedida (AM-Sentry) apunta a la misma dirección que los papers anteriores: política de qué se guarda en memoria y pantalla de revisión de lo que se recupera.

Higiene de memoria: qué haría yo

Ninguna de estas mitigaciones requiere tecnología exótica. Requieren tratar la memoria como lo que es: input no verificado con estado. Lista corta, ordenada por coste-beneficio:

Trata cada memoria recuperada como input no verificado, no como hecho. La decisión de confianza debe ser explícita antes de inyectar, no implícita en el pipeline. Si tu respuesta a “¿validas lo que recuperas?” es “el retriever ordena bien”, estás en el patrón que amplifica alucinaciones.
Chequeo de consistencia previo a la inyección. Señales del estilo de MDL: relevancia, fiabilidad, riesgo de tarea. Con posiciones en conflicto, abstente o escala a humano en tareas de alto riesgo. El coste (0,14 ms por decisión en el paper) ya no es excusa.
Procedencia en write-time, no en retrieval-time. La extracción estructurada con origen en el momento de escribir (como propone AutoViewMem, arXiv 2609.21940, un paper de arquitectura de memoria, no de seguridad) deja metadatos que luego permiten evaluar qué confías y qué no. Consolidación offline para evitar el store conflictivo.
Audita combinaciones, no documentos sueltos. El envenenamiento micro-colaborativo vive en la suma. Muestrea periódicamente el contexto completo que le llega al modelo, no solo los documentos del índice. Si tu revisión de seguridad es documento a documento, no detecta este patrón por diseño.
Parchea los checkpointers hoy: langgraph ≥ 1.0.10, langgraph-checkpoint-sqlite ≥ 3.0.1, langgraph-checkpoint-redis ≥ 1.0.2. Y no expongas get_state_history() con filtros controlados por el usuario. Es una tarde de trabajo.
Backup y rollback del estado del agente en tu plan de recuperación, con el límite aprendido: recuperar el cuaderno no deshace acciones ya ejecutadas contra sistemas compartidos. Si tu agente escribe en producción, la recuperación empieza en esas escrituras, no en la memoria.
Diseña asumiendo la fuga. Lo que le das al agente, cuenta que un observador externo puede reconstruirlo (CIPL). El dato sensible que no necesita estar en la memoria del agente, no lo pones ahí.

Los cuatro papers, en una tabla

Paper	Qué aporta	Qué NO demuestra
Micro-Collaborative Poisoning (2609.21573)	Un patrón de ataque distribuido realista, evaluado en 108 configuraciones RAG; top-k alto y multi-DB lo agravan, la diversidad limpia lo mitiga	Campañas reales observadas en la naturaleza; es un estudio experimental, no forense
MDL (2609.22043)	Cuantifica que inyectar sin filtrar memorias en conflicto amplifica alucinaciones, y que una decisión de confianza explícita cuesta ~0,14 ms	Que el −56,04% se traslade a tu stack; sus cifras son de benchmarks propios con datasets open-source
CIPL (2609.21686)	Un framework para medir lo que un observador externo reconstruye de verdad; la memoria como caso casi saturado	El daño concreto de una fuga en tu negocio; mide recuperabilidad, no impacto
AutoViewMem (21940)	Procedencia en write-time y consolidación offline como diseño de memoria de calidad	Cualquier cosa de seguridad: es arquitectura de memoria, lo usamos aquí como higiene, no como defensa

Conclusión

La memoria de agentes es útil y va a estar en todas partes; eso no está en discusión. Lo que está en discusión es venderla como feature premium de personalización sin gobernanza: sin procedencia en la escritura, sin chequeo de consistencia en la lectura, sin plan de recuperación y sin asumir que lo sensible se reconstruye desde fuera. Eso no es una feature, es deuda técnica con intereses, y los intereses se pagan en alucinaciones amplificadas, CVEs en la capa de persistencia y fugas reconstruibles.

Dicho lo cual, nada de terrorismo: los cuatro papers son simulaciones y benchmarks, no incidentes forenses; Cohesity no está probado por terceros; y los tres CVEs de LangGraph tienen parche publicado desde junio. La diferencia entre pánico y higiene es que la higiene tiene lista de tareas. La de arriba es un buen punto de partida: parchea hoy, audita combinaciones este mes, y diseña el próximo agente asumiendo que su cuaderno será leído.

La memoria sin gobernanza y la supervisión cara son el mismo fallo de diseño visto desde dos lados. En multi-agent systems con OpenClaw: arquitectura real vimos la mitad arquitectural: cada subagente que añades multiplica los puntos donde algo puede correr sin que lo veas. La otra mitad es de producto: la pieza «Supervisión barata de agentes IA: por qué los usuarios no quieren más autonomía» recoge que lo que piden los usuarios de agentes no es más autonomía, es poder revisar sin que la revisión les cueste más que hacerlo a mano.

Metodología y limitaciones

Verificado contra fuentes primarias el 21-09-2026: los cuatro papers vía API oficial de arXiv (todos v1, 18-sep-2026), la nota de Check Point Research (11-jun-2026), la nota de prensa de Cohesity (16-sep-2026), la nota oficial de Gartner (26-ago-2025) y el artículo de The Conversation firmado por los investigadores de la Universidad de Calgary. No hemos reproducido ningún ataque ni benchmark: todas las cifras son las declaradas por sus autores en sus respectivos contextos experimentales y no constituyen una validación independiente. GhostWriter es un preprint de julio de 2026 no (que sepamos) revisado por pares.