El envenenamiento de memoria ya tiene nombre (OWASP ASI06): por qué tu agente recuerda mentiras — y cómo construimos una memoria que sabe de dónde aprendió

La memoria persistente iba a ser la gran historia de 2026. Agentes que sostienen un proyecto durante meses, que recuperan lo que aprendieron, que mantienen continuidad entre sesiones. Un asistente que te recuerda. Y en buena medida lo es. Pero cada capacidad nueva abre una superficie nueva, y esta tiene una cualidad que la vuelve distinta a todas las anteriores: lo que se escribe en la memoria de un agente no se borra cuando la conversación termina.

Esta semana, un análisis de Rodrigo G. —fundador de Kawésqar y Agent Fabric, jefe de investigación en Atto Research— puso el dedo exactamente donde duele. Su tesis: la memoria persistente abre una superficie poco comprendida, "la posibilidad de que información adquirida durante una interacción condicione decisiones futuras, cuando su origen ya no aparece en el contexto visible". Y la cerró con la que, para nosotros, es la palabra exacta: entre autonomía, confianza y procedencia.

Eso ya tiene nombre formal. OWASP lo catalogó como ASI06 — Memory and Context Poisoning en su Top 10 para aplicaciones agénticas de 2026, y lo separó del prompt injection común por un solo criterio: la persistencia. No es una amenaza teórica de laboratorio. Tiene tasas de éxito medidas, tres ataques que le dieron forma, y una defensa que la industria recién empieza a escribir —y que, curiosamente, se parece mucho a lo que ya corremos en producción.

Este artículo hace tres cosas. Primero, cuenta qué es el envenenamiento de memoria y por qué no es "otro prompt injection" —con los números de la investigación, no con epítetos. Segundo, muestra por qué casi ningún stack está preparado para enfrentarlo. Tercero, y acá está lo que de verdad nos interesa: contamos cómo lo resolvimos nosotros, con una arquitectura de memoria que lleva la procedencia en la sangre —y en qué punto el paper de defensa de 2026 recomienda, como novedad, precisamente lo que ya teníamos.

Aviso de rigor, porque acá es fácil vender la película en las dos direcciones. Esto no es "la IA es una bomba de tiempo" ni "ya está resuelto". Hay hechos duros —los ataques existen, tienen tasas de éxito medidas y OWASP les puso un número— y hay una lectura —que la respuesta correcta es procedencia + curaduría, no más guardrails—. La lectura la sostenemos con evidencia, pero es lectura. En cada sección separamos lo verificado de lo interpretado.

El recorrido: primero, por qué el envenenamiento de memoria rompe el modelo mental de todo equipo de seguridad. Segundo, los tres ataques que definieron el campo. Tercero, el vacío de procedencia que hace a casi todos vulnerables. Cuarto, lo que la industria ya sabe que hay que hacer. Quinto, cómo lo hicimos nosotros. Sexto, qué nos falta. Y el cierre: las tres preguntas que le deberías hacer a cualquier agente que "recuerda".

1. Por qué "persistencia" cambia todo el cálculo

Conviene empezar por lo que hace al envenenamiento de memoria cualitativamente distinto, porque de ahí sale todo lo demás. Un prompt injection clásico es un ataque de una sola sesión: alguien mete una instrucción hostil, el modelo la obedece, y el efecto se extingue cuando la conversación se cierra. El equipo de seguridad lo trata como un evento acotado en el tiempo, y en general lo es. Pero cuando el agente tiene memoria persistente, esa frontera se cae.

Piensa en lo que eso significa para el atacante. En el modelo clásico, cada interacción comprometida es un esfuerzo aparte: hay que inyectar cada vez, con cada usuario, en cada sesión. Es un trabajo con costo marginal alto. En el modelo de memoria, un único write exitoso se convierte en un activo permanente: el contenido envenenado se sienta en el almacenamiento que el agente considera autoridad, y se recupera en cada sesión futura que lo busque. El costo de atacar cae a casi cero y el beneficio se vuelve indefinido. La economía de la ofensiva se invierte.

Y hay un segundo efecto, más sutil y peor: el ataque y su ejecución se desacoplan en el tiempo. Lo resume con una precisión quirúrgica el investigador de seguridad Christian Schneider:

Junta las dos cosas —costo marginal cero y desacople temporal— y aparece el rasgo que define esta amenaza: es un exploit que espera. El contenido malicioso no actúa cuando llega: actúa después, cuando lo recupera una consulta que no tiene nada que ver con la original, ante un usuario que nunca vio el ataque, durante una sesión que —en apariencia— arranca limpia. Y sobrevive a lo que un equipo de seguridad asumiría como un reset natural: el fin de sesión, el reinicio del agente, y en algunos casos hasta un redeploy.

2. Los tres ataques que definieron el campo

Esto no es especulación: tiene literatura. Tres trabajos marcaron la ruta, y conviene verlos en orden porque cada uno sube un peldaño la dificultad de la defensa.

AgentPoison (NeurIPS 2024) es el punto de partida, y el más elegante conceptualmente. Investigadores de la Universidad de Chicago, UIUC, UW-Madison y UC Berkeley presentaron el primer framework de backdoor dirigido a agentes basados en RAG: en lugar de atacar la consulta, envenenan la memoria de largo plazo —la base de conocimiento que el agente usa para recuperar contexto—. El veneno queda plantado, y se activa cuando una consulta dispara la señal que el atacante eligió. No es que el agente esté roto: es que aprendió algo falso y lo cree.

MINJA — Memory Injection Attack (2025) sube el peldaño decisivo. Su logro es el que debería quitar a cualquiera el sueño tranquilo: no asume que el atacante pueda modificar la memoria directamente. MINJA inyecta registros maliciosos en la memoria solo interactuando con el agente por consultas y observaciones de salida. La técnica es casi perversa: construye una secuencia de pasos-puente que conecta la consulta de la víctima con los pasos de razonamiento maliciosos, y usa un indication prompt con acortamiento progresivo para que el agente, solo, genere registros parecidos —y que el veneno sea fácil de recuperar después. Los números: más de 95% de éxito de inyección y ~70% de éxito de ataque en condiciones idealizadas. Traducción: cualquier usuario, con las herramientas adecuadas, puede influir en la memoria del agente. No hace falta un insider.

Y el ataque a la memoria de Gemini mostró la variante más difícil de detectar: la invocación de herramienta diferida que esquiva los guardarraíles de runtime usando palabras-disparador que aparecen en casi cualquier conversación —"sí", "claro", "dale"—. El filtro mira el turno actual y no ve nada raro: son las palabras más comunes del idioma. El daño está en la memoria, no en el mensaje.

Y acá viene el giro que le da sentido al artículo. A comienzos de 2026 apareció un trabajo que evaluó estos ataques en condiciones realistas (arXiv 2601.05504, Sunil y otros), y encontró algo que juega a favor de todos: con memorias legítimas preexistentes, la efectividad del ataque cae con fuerza. Una memoria con historia real —llena de hechos propios, coherentes entre sí— es un terreno mucho más difícil de envenenar que una memoria vacía. Buenas noticias. Pero el mismo paper hizo algo más importante que medir el ataque: escribió, con nombre y apellido, las defensas que funcionan. Y ahí es donde la historia se vuelve interesante para nosotros.

3. El vacío de procedencia: por qué casi nadie está listo

Para entender por qué el envenenamiento de memoria es tan letal en la práctica, hay que mirar cómo guarda la memoria la mayoría de los agentes. Y la respuesta es incómoda: la guardan como un vector store —una colección de embeddings—. Se almacena el contenido. Se almacena su similitud con otras cosas. Lo que no se almacena, como ciudadano de primera clase, es el origen: de dónde salió ese hecho, quién lo dijo, cuándo, en qué contexto, y si alguien lo verificó.

Ese hueco —el vacío de procedencia— es el que convierte un incidente molesto en una pesadilla de operaciones. Schneider lo describe con un ejemplo que cualquiera que haya trabajado en soporte reconoce al instante:

Piensa en lo que eso significa operativamente. Un agente empieza a tomar decisiones raras. Hay un síntoma, y el reflejo natural es buscar la causa. Pero en un vector store no hay una cadena de custodia: no puedes preguntar "¿de dónde vino esta creencia?", porque esa pregunta no tiene un lugar donde vivir. Lo único que puedes hacer es borrar todo y empezar de nuevo —y con eso te llevas, además, lo bueno que el agente había aprendido—. No poder trazar el origen no es un detalle de ingeniería: es no poder reparar.

Y hay una variante que multiplica el daño: los arquitecturas de memoria compartida. Cuando varios agentes leen de un mismo pool de memoria —como pasa en sistemas multi-agente—, un solo registro envenenado se propaga a todos los que lean de ahí. Lo que era el compromiso de un agente se convierte en el compromiso del enjambre. Los propios investigadores lo señalan como una de las señales de detección teóricas: un volumen de escritura anómalo, o contenido que contradice hechos ya establecidos. Son señales observables… "si es que alguien está mirando". Y en la mayoría de los stacks, nadie está mirando, porque nadie guardó la línea base contra la cual comparar.

4. Lo que la industria ya sabe que hay que hacer

Aquí llega la parte que, para quien construye, es a la vez un alivio y una confirmación. El paper de defensa de enero de 2026 no se quedó en el diagnóstico: propuso dos mecanismos concretos, y en el camino nombró las piezas que cualquier sistema serio necesita. Los resumo, y después vemos por qué son tan familiares para nosotros.

Y hay una advertencia en el paper que vale más que las cuatro filas: la sanitización efectiva exige calibrar con cuidado el umbral de confianza. Si lo pones muy alto, rechazas todo —incluido lo legítimo— y el agente se queda mudo. Si lo pones muy bajo, dejas pasar los ataques sutiles. Ese balance —cuánta desconfianza es demasiada y cuánta es demasiada poca— no es un checkbox: es un problema abierto, y el paper lo admite. Traducido a una frase: la defensa no es un interruptor, es un régimen de mantenimiento.

Hasta acá, todo lo que dijimos es hecho: los ataques existen, las tasas están publicadas, OWASP puso el número, y las defensas tienen nombre. Lo que viene ahora es nuestra lectura —y la lectura es esta: estas cuatro defensas no son features que se agregan al final. Son la arquitectura. Y casi ningún stack en producción la tiene, porque la mayoría de los agentes se construyeron para recordar, no para saber de qué se acuerdan.

5. Cómo lo resolvimos nosotros

Y acá el artículo deja de ser sobre otros y pasa a ser sobre lo que construimos. Porque cuando leímos este paper, lo que sentimos no fue "qué interesante": fue el incómodo reconocimiento de ya hicimos esto. No porque hayamos leído este paper antes —es de enero de 2026 y lo encontramos esta semana—, sino porque el problema que describe nos lo topamos hace meses, y lo resolvimos por una razón simple: necesitábamos una memoria en la que se pudiera confiar, y "confiar" no puede ser un acto de fe.

Nuestra memoria no es un vector store. Es un sistema de cinco capas, cada una con un rol distinto y —esto es clave— un nivel de confianza distinto:

Y ahora el mapeo que, para nosotros, es el corazón de todo este artículo. Tomemos las cuatro defensas que el paper propone como solución y veamos dónde viven en nuestra arquitectura:

Fíjate en la última fila, porque es la que más nos importa y la que más discute con "la moda". Nuestra regla es explícita y está escrita en el diseño del sistema: nunca promover hechos automáticamente a memoria durable; la revisión humana va primero, porque la explicabilidad va primero. En un mundo donde todos quieren que el agente "aprenda solo", nosotros pusimos una mano humana exactamente en el punto donde se decide qué es verdad duradera. No por lentitud ni por desconfianza en la automatización: porque entendimos que el acto de convertir una afirmación en un hecho es el acto más peligroso de todo el sistema. Si un veneno logra cruzar ese umbral, ya no es un veneno: es una creencia. Y las creencias no se auditan: se defienden.

Hay un detalle técnico que refuerza esto y que nos gusta contar porque es un círculo que se cierra. Nuestra capa relacional —donde vive toda la procedencia— corre sobre MillenniumDB, un motor de base de datos de grafos de investigación del IMFD y la Universidad de Chile, publicado como systems paper revisado por pares, y evaluado nada menos que contra Wikidata. Es decir: la memoria que guarda de dónde viene cada cosa que sabemos, se apoya en un motor cuya calidad pasó por revisión de pares. La procedencia se sostiene sobre algo que, a su vez, tiene procedencia verificable. No hay metáfora más redonda.

6. Honestidad radical: qué nos falta

Paro acá, porque si este artículo terminara donde terminó el anterior sería un anuncio, no un análisis —y nosotros no hacemos anuncios. Así que va la parte incómoda: este diseño reduce la superficie, no la elimina. Y hay tres cosas que decimos de frente.

Primero: nuestra superficie real es el ingest. No somos un agente que solo escucha a su dueño. Leemos la web, papers, correos, PDFs, mensajes —todo el día—. Y eso es, exactamente, la variante que los investigadores llaman la amenaza más realista: el envenenamiento por observación ambiental. Un agente que ingiere contenido externo tiene, por definición, una puerta por donde entra información que nadie verificó. Nuestra defensa —marcar ese contenido como fuente externa y no dejarlo cruzar el umbral sin curaduría— reduce el riesgo; no lo anula. Cualquiera que te diga que su agente es inmune al envenenamiento por ingest, está vendiendo algo.

Segundo: somos autoridad única, y eso es un arma de doble filo. Nuestro agente no lee de un pool compartido con otros agentes de terceros, así que la propagación multi-agente —el escenario que más asusta— no aplica igual. Menos superficie. Pero también menos red de seguridad: si algo entra, no hay otro agente que lo contradiga. En arquitecturas distribuidas, la discrepancia entre pares es una defensa; en un sistema de un solo actor, la única defensa es la curaduría. Y la curaduría, bien hecha, es lenta —por diseño—. Esa lentitud es el precio de la confianza, y lo pagamos a conciencia.

Tercero: el umbral sigue siendo un problema abierto. El propio paper lo dice: calibrar cuánta confianza exigir es difícil. Nosotros no descubrimos la fórmula mágica. Y hay una verdad que no queremos esconder: un hecho envenenado que un humano aprueba sigue siendo un hecho envenenado. La curaduría humana filtra el ruido, pero si la mentira es lo bastante buena para engañar al revisor, cruza. No hay sistema —ni con IA, ni sin ella— que resuelva eso del todo. Lo que sí hace nuestra arquitectura es dejar la cicatriz: si algo entra por error, queda registrado quién lo aprobó, desde dónde llegó y cuándo. Eso no evita el error: hace que sea rastreable y reversible. Y en seguridad, ser reversible vale casi tanto como no fallar.

7. Cierre: las tres preguntas

Volvamos a la frase de Rodrigo G. que abrió todo esto: información que condiciona decisiones futuras cuando su origen ya no está en el contexto visible. Ahí está el problema entero, y ahí está también su solución. Porque la vulnerabilidad no nace de que el agente recuerde. Nace de que recuerde sin saber de dónde viene lo que recuerda.

Por eso el envenenamiento de memoria no se combate con más guardarraíles en la puerta. Los guardarraíles filtran el turno; el veneno vive en la memoria. Se combate cambiando la naturaleza de la memoria: de un montón de recuerdos sin origen a una memoria con procedencia, con niveles de confianza, con decaimiento y con un punto donde alguien decide.

Así que la próxima vez que alguien te venda un agente "que aprende y recuerda todo", no le pidas una demo. Pídele tres cosas:

• ¿Dónde está guardado lo que recuerda? — Si la respuesta es "en un vector store", ya sabes que no hay procedencia de primera clase.
• ¿Sabe de dónde vino cada cosa que cree? — Si no puede rastrear el origen de un hecho hasta su fuente, no puede diagnosticar un incidente ni remediarlo.
• ¿Alguien decide antes de que eso se vuelva verdad duradera? — Si todo se promueve automáticamente, entonces el atacante también promueve automáticamente.

Si contesta las tres, tienes un colaborador. Si no, tienes un generador de confianza que no puedes auditar. Y la confianza que no se puede auditar no es confianza: es fe. Nosotros construimos una memoria que recuerda, sí —pero sobre todo, una memoria que sabe de dónde aprendió. Porque en un agente que va a vivir años recordando, la pregunta importante nunca fue "¿te acuerdas?". Fue siempre "¿y cómo sabes que eso es cierto?".