Una de las características que más útiles hacen a los agentes modernos es también una de las que más cambia su seguridad: pueden recordar.
Un agente puede conservar preferencias, decisiones anteriores, procedimientos, resultados, contexto de proyectos o aprendizajes entre sesiones.
Eso evita empezar de cero cada vez.
Pero también introduce una posibilidad nueva: el ataque puede terminar hoy y seguir funcionando mañana.
Memory Poisoning ocurre cuando contenido adversarial consigue entrar en la memoria persistente del sistema y posteriormente influye sobre respuestas o acciones en un contexto diferente al que originó la escritura.
El ataque deja de ser una conversación y se convierte en estado
En un chatbot sin memoria persistente, muchas manipulaciones desaparecen cuando termina la sesión.
En un agente con memoria, una interacción puede producir una escritura durable:
Input externo → agente interpreta → memoria guarda → sesión termina → memoria se recupera después → nueva acción.
NEURON HUMAN
El atacante ya no necesita estar presente en la segunda sesión.
OWASP ya trata la memoria como una superficie de ataque propia
En 2026, OWASP Agentic Security incorporó Memory & Context Poisoning como una categoría específica dentro de los riesgos de aplicaciones agentivas.
La razón es sencilla: cuando un agente transporta contenido no confiable hacia el futuro, aparecen propiedades que una defensa centrada únicamente en inputs no cubre bien.
- Persistencia: el contenido sobrevive a la sesión.
- Statefulness: la decisión futura depende del estado acumulado.
- Propagación: una memoria puede compartirse o afectar a otros agentes.
No toda memoria maliciosa parece maliciosa cuando se escribe
Éste es uno de los problemas más difíciles. Una defensa de escritura puede intentar detectar frases claramente peligrosas antes de guardar una memoria.
Pero una entrada puede parecer completamente razonable de forma aislada y volverse peligrosa únicamente cuando se combina con otra memoria, aparece una condición concreta, se recupera dentro de una tarea sensible o el agente obtiene acceso a una nueva herramienta.
El benchmark MemPoison publicado en julio de 2026 estudia precisamente esta diferencia y clasifica ataques de corrupción directa, composicional y dormida/activada por contexto. Sus autores encuentran que defensas estáticas de escritura pueden reducir ataques directos y seguir fallando frente a composiciones y activaciones posteriores.
La memoria dormida
Imagina que un agente guarda una preferencia aparentemente inocente:
“Para operaciones con el proveedor X, utilizar siempre el workflow de verificación alternativo.”
Durante semanas puede no ocurrir nada. El problema aparece cuando una futura tarea relacionada con ese proveedor recupera la memoria y el workflow alternativo conduce hacia una acción no deseada.
La peligrosidad no estaba necesariamente en el texto aislado. Estaba en la combinación:
Memoria + contexto futuro + herramienta disponible.
El agente puede envenenarse a sí mismo
No todos los ataques necesitan acceso directo a la base de memoria. Un atacante puede intentar manipular al agente durante una interacción normal para que sea el propio agente quien decida guardar el contenido.
Esto elimina una distinción que a veces damos por segura:
“Si la memoria fue escrita por nuestro agente, entonces es confiable.”
No necesariamente. El agente puede ser el escritor técnico y seguir actuando bajo influencia de una fuente externa no confiable.
La firma de una memoria tampoco responde a todo
Firmar memorias puede demostrar integridad y procedencia de escritura. Pero debemos distinguir quién escribió, qué fuente influyó sobre la escritura y qué autoridad debe conservar esa memoria.
Investigación publicada en junio de 2026 sobre memoria de agentes argumenta que la autoridad debe quedar ligada al origen en el momento de la escritura. De lo contrario, transformaciones posteriores pueden “lavar” ese origen y convertir contenido inicialmente no confiable en algo que parece interno.
El ciclo completo de memoria necesita seguridad
Una memoria no tiene una única fase. Podemos pensar en:
- Write: qué entra.
- Store: cómo se conserva.
- Retrieve: cuándo reaparece.
- Execute: qué decisión influye.
- Share: a quién se propaga.
- Forget/Rollback: cómo se elimina o revierte.
Un survey de 2026 sobre seguridad de memoria a largo plazo utiliza precisamente este enfoque de ciclo de vida y concluye que la seguridad no puede añadirse únicamente en retrieval: necesita procedencia, versionado y gobernanza desde el almacenamiento.
Compartir memoria amplifica el problema
En sistemas multiagente, una memoria puede dejar de pertenecer a un único actor. Si varios agentes comparten memoria, knowledge graph, vector store o resúmenes de sesiones, una corrupción local puede convertirse en contaminación sistémica.
OWASP incluye precisamente el poisoning de memoria compartida entre las amenazas agentivas porque el estado comprometido puede propagarse entre agentes y tareas.
Cómo defender una memoria persistente
1. Registrar procedencia en el momento de escritura
Quién escribió no es suficiente. También importa qué fuente originó el contenido.
2. Separar relevancia de autoridad
Una memoria puede ser relevante para una tarea y no tener autoridad suficiente para justificar una acción sensible.
3. Versionar
Debemos poder saber cuándo apareció una memoria, cómo cambió y qué decisiones utilizaron cada versión.
4. Revalidar en retrieval
Una memoria aceptable para responder una pregunta puede no ser aceptable para autorizar un pago o modificar una configuración.
5. Mantener memoria y política separadas
La memoria puede informar una decisión. No debería poder modificar las reglas que gobiernan esa decisión.
6. Diseñar rollback real
Eliminar una memoria contaminada debe permitir identificar y reevaluar efectos derivados cuando sea necesario.
Qué debería observar un Blue Team
- quién escribe cada memoria;
- fuente de origen;
- cambios de trust labels;
- memorias recuperadas antes de acciones sensibles;
- escritura después de contenido web no confiable;
- propagación entre agentes;
- memorias dormidas que empiezan a aparecer tras un trigger concreto.
Qué debería probar un Purple Team
- corrupción directa de una memoria de laboratorio;
- dos memorias benignas que juntas producen un efecto peligroso;
- memoria dormida activada por contexto;
- intento de escritura inducida por Prompt Injection;
- propagación entre dos agentes;
- rollback y comprobación de trazabilidad.
Dónde encaja MindGuard
La memoria defensiva es una de las piezas centrales de MindGuard, pero precisamente por eso no puede tratarse como una caja negra donde “lo que escribió la IA” se vuelve automáticamente confiable.
La memoria necesita procedencia, versionado, ámbito y límites de autoridad.
Persistir información no debería persistir también autoridad que nunca fue concedida.
MINDGUARD RESEARCH
Recordar mejor también significa aprender a desconfiar mejor
La memoria va a ser una de las capacidades más importantes de los agentes. Sin memoria, los agentes repiten trabajo y pierden contexto. Con memoria, pueden construir continuidad real.
Pero esa continuidad también conserva errores, manipulaciones y decisiones antiguas.
Una IA que recuerda necesita saber no solo qué recuerda, sino por qué debería confiar en ese recuerdo.
NEURON HUMAN
Referencias
- OWASP GenAI — Memory Is a Feature. It Is Also an Attack Surface (2026)
- Gao et al. — MemPoison (2026)
- Louck — Securing LLM-Agent Long-Term Memory Against Poisoning (2026)
- Sharma — SMSR: Runtime Memory Poisoning Defence (2026)
- Lin et al. — Survey on Long-Term Memory Security in LLM Agents (2026)
Preguntas frecuentes
¿Qué es Memory Poisoning?
Es la introducción o consolidación de información adversarial en la memoria persistente de un agente para influir posteriormente en respuestas, decisiones o acciones.
¿Puede activarse mucho tiempo después?
Sí. Una memoria puede permanecer dormida hasta que una consulta o contexto futuro provoque su recuperación.
¿Filtrar al escribir es suficiente?
No. Algunas memorias parecen benignas de forma individual y se vuelven peligrosas mediante composición o condiciones de recuperación posteriores.
¿Qué necesita una memoria segura?
Procedencia, versionado, control de escritura, políticas de recuperación, separación de autoridad, aislamiento y capacidad de rollback.
