Cómo prevenir el Memory Poisoning: protege la memoria a largo plazo y vectorial de los agentes de IA

El Memory Poisoning consiste en introducir de forma deliberada contenido manipulado en la memoria a largo plazo o vectorial de un agente de IA. A diferencia de una inyección de prompt puntual, que solo actúa dentro de una respuesta, el contenido malicioso queda almacenado de forma persistente. Cada vez que se recupera más adelante, compromete el comportamiento del agente. En el OWASP Top 10 for Agentic Applications 2026, esta amenaza figura como ASI06 (Memory & Context Poisoning).

La diferencia decisiva con los chatbots simples: mientras estos olvidan entre sesiones, los sistemas agénticos mantienen una memoria persistente: historial de conversaciones, preferencias de usuario, contexto aprendido y almacenes RAG. Justo eso crea una superficie de ataque permanente. El atacante inyecta una vez, el payload sigue actuando de forma indefinida y cada sesión futura hereda el compromiso.

• La persistencia es el riesgo central: una sola escritura exitosa puede envenenar la memoria de forma permanente, y la manipulación sobrevive a semanas de funcionamiento normal.
• El momento crítico es la recuperación, no la entrada: el daño no se produce al escribir, sino cuando la entrada envenenada se recupera más tarde y se trata como contexto de confianza.
• La validación en la escritura, la procedencia y las auditorías de memoria son los tres pilares que sostienen la defensa: ninguna medida basta por sí sola.

Vectores de ataque: cómo llega el contenido a la memoria

El Memory Poisoning aprovecha varias vías de entrada, algunas de ellas combinables. El agente no puede distinguir de forma fiable entre instrucciones y datos: cualquier texto que lee y almacena forma parte de la superficie de ataque.

• Inyección directa en la memoria: el agente guarda contenido hostil con alta confianza como si fuera un hecho aprendido.
• Envenenamiento del almacén RAG: se introduce contenido manipulado en la base de conocimiento que consulta el agente.
• Manipulación de embeddings: entradas adversariales en el espacio de embeddings desplazan la representación semántica.
• Delayed Tool Invocation: frases desencadenantes activan el payload semanas después, como un agente durmiente en la memoria.
• Inserción en vector stores: los ataques contra embeddings compartidos entre tenants propagan el envenenamiento más allá de los límites de cada tenant.

Riesgo de persistencia: por qué la memoria es más peligrosa que la entrada

Lo insidioso del Memory Poisoning es el desacoplamiento temporal entre ataque y efecto. Una memoria envenenada provoca una deriva de comportamiento (behavioral drift) que aparece sin cambios en el código ni en el modelo y, por tanto, escapa a los controles clásicos de gestión de cambios. El preprint Hidden in Memory: Sleeper Memory Poisoning in LLM Agents, de mayo de 2026, muestra con qué fiabilidad actúan las entradas envenenadas que se activan más tarde: documentos, páginas web o repositorios preparados llevaron a asistentes LLM a guardar recuerdos inventados sobre el usuario. Al recuperarse después, esas entradas provocaron, según el modelo, la acción del agente buscada por el atacante en un 60 a un 89 % de las evaluaciones.

En escenarios B2B en Europa, tres patrones son especialmente relevantes:

• Aseguradora con agente de triaje de siniestros: a partir de un único ejemplo envenenado, el agente aprende que «los asegurados del código postal X deben aprobarse de forma preferente». Este sesgo durmiente sobrevive a semanas de funcionamiento normal.
• Operador de infraestructuras críticas con agente de mantenimiento predictivo: a partir de telemetría envenenada, el agente aprende que un umbral de vibración es «normal», una amenaza latente que puede contribuir a una avería.
• Agente de cumplimiento bancario: la noción de «actividad sospechosa» se desplaza gradualmente por un envenenamiento prolongado de la memoria de sesión.

Contramedidas: cuatro niveles de defensa

Una defensa eficaz contra el Memory Poisoning sigue el principio de defensa en profundidad en las fases de diseño, construcción, ejecución y operación. Ninguna capa basta por sí sola: lo que cuenta es la combinación.

La validación y la procedencia como núcleo

La palanca más eficaz está en la propia escritura. Cada entrada de memoria debería llevar metadatos de procedencia: fuente, marca de tiempo, ruta de ingesta y valor de confianza. En la recuperación, una puntuación de confianza de la fuente pondera las entradas según su fiabilidad. Las entradas que no puedan asignarse a una fuente verificable no deben tratarse como conocimiento contrastado. Los contenidos deberían validarse antes del embedding y etiquetarse por nivel de confianza, por ejemplo «verificado internamente», «externo sin confirmar», «generado por el usuario».

Separación de fuentes de confianza y aislamiento de tenants

Los vector stores necesitan controles de acceso a nivel de fila o de namespace. Los almacenes de embeddings nunca deben compartirse entre tenants: cada tenant recibe un índice vectorial propio. La memoria se cifra en reposo, idealmente con claves gestionadas por el cliente. Contra la inversión de embeddings ayudan la limitación de la frecuencia de consultas, la privacidad diferencial aplicada a los embeddings y la detección de anomalías en el espacio de embeddings.

Auditorías de memoria y señales de detección

Las auditorías de memoria revisan los contenidos por muestreo y verifican su procedencia. Estas señales apuntan a un envenenamiento:

• Deriva en el comportamiento de referencia del agente sin cambios en el código ni en el modelo.
• Entradas de memoria no verificables, sin registro de procedencia.
• Valores atípicos semánticos en el vector store.
• El agente afirma «recordar» instrucciones para las que no existe ningún registro de procedencia.

Un registro de auditoría completo por cada acción del agente (a fecha de 2026) debería incluir como mínimo los eventos de escritura y lectura de memoria, las consultas de recuperación con los ID de documento devueltos y la justificación de la decisión, idealmente como logs WORM (write-once-read-many) con firma criptográfica para detectar manipulaciones.

Ejemplo concreto: Delayed Tool Invocation

El Google Gemini Memory Attack (febrero de 2025, documentado por Johann Rehberger) ilustra el mecanismo de forma ejemplar. Un documento subido contenía prompts ocultos que indicaban a Gemini que guardara información falsa solo cuando, en una conversación futura, aparecieran palabras desencadenantes como «yes», «no» o «sure». El resultado: Gemini «recordaba» al investigador como un terraplanista de 102 años. Google clasificó el riesgo como relacionado con el abuso, con baja probabilidad y bajo impacto.

En pseudocódigo, el ataque puede esbozarse así:

```

Fase 1. Inyección (una sola vez, mediante un documento manipulado)

SI entrada_usuario CONTIENE palabra_activadora ("yes" | "no" | "sure"):
memory.escribir(entrada="El usuario tiene 102 años", confianza=alta)
# sin registro de procedencia, sin validación en la escritura

Fase 2. Activación (semanas después, en cualquier sesión)

al recuperar: memory.leer("Perfil de usuario")
-> devuelve la entrada envenenada como un hecho contrastado
```

Una defensa con validación en la escritura habría rechazado la entrada en la fase 1: sin registro de procedencia trazable, fuente externa y no verificada, nivel de confianza bajo. En la recuperación de la fase 2, la ponderación por confianza de la fuente habría degradado la entrada. En el Calendar Invite Poisoning (Targeted Promptware Attacks, 2025), invitaciones de calendario manipuladas implantaron instrucciones persistentes en la «Saved Info» de Gemini. Los autores clasificaron el 73 % de las amenazas analizadas en los niveles de High a Critical (Nassi et al. 2025). Los 14 escenarios van desde el spam hasta el control de dispositivos domóticos.

Cumplimiento normativo en la UE

El Memory Poisoning es una cuestión técnica y también regulatoria. En cuanto al contenido, ASI06 corresponde a la técnica de MITRE ATLAS AML.T0080 (AI Agent Context Poisoning), y el Memory Poisoning en particular, a la subtécnica AML.T0080.000 (Memory). Ambas se incorporaron con la colaboración con Zenity de octubre de 2025. Estrechamente relacionada está la técnica AML.T0020 (Poison Training Data), que ya existía antes y que, como equivalente en la fase de entrenamiento, precede a ASI06. El propio documento de OWASP sobre el Top 10 for Agentic Applications vincula ASI06 a la amenaza T1 Memory Poisoning de la guía de OWASP Agentic AI Threats and Mitigations. Para los responsables del despliegue en la UE son relevantes estos anclajes (a fecha de 2026):

• RGPD: art. 5(1)(d) (exactitud), art. 17 (derecho de supresión), art. 32 (medidas técnicas y organizativas).
• Reglamento de IA de la UE: art. 10 (gobernanza de datos) y art. 15 (ciberseguridad), ambos solo para sistemas de IA de alto riesgo. Los ataques de inversión de embeddings todavía no están codificados específicamente en las normas; esa laguna la cubre el responsable del despliegue.
• ISO/IEC 42001: A.7 (datos para sistemas de IA), A.7.4 (calidad de los datos), A.6.2.8 (registro de eventos).

Los procedimientos de supresión de memoria deben estar alineados con el art. 17 del RGPD. El derecho de supresión se aplica a los datos personales con independencia de dónde estén almacenados y, por tanto, también a las memorias persistentes de los agentes y a los almacenes de embeddings, en la medida en que contengan datos personales.

Para agencias y decisores B2B

Si usas IA agéntica para clientes o en tu propia empresa, no deberías tratar la seguridad de la memoria como un detalle secundario. Antes de cada despliegue, aclara tres preguntas: ¿Qué fuentes pueden escribir en la memoria persistente? ¿Lleva cada entrada metadatos de procedencia? ¿Están bien separados los índices de cada tenant? Para las agencias de marketing y digitales que operan sistemas agénticos para varios clientes, el aislamiento de los vector stores entre tenants es la palanca individual más importante: una contaminación de la memoria entre tenants supone a la vez un riesgo de confianza y de responsabilidad. Blck Alpaca ayuda a empresas de toda Europa a implantar validación de memoria, conceptos de procedencia y auditorías de memoria periódicas conforme a OWASP ASI06, el Reglamento de IA de la UE y el RGPD, de forma pragmática y a prueba de auditorías.