Bad Memory: la inyección que persiste en los archivos de memoria de los agentes de código

¿Qué es esto?

El 16 de julio de 2026, Soham Gadgil, David Alexander, Sai Sunku y Franziska Roesner (Universidad de Washington) publicaron Bad Memory: Evaluating Prompt Injection Risks from Memory in Agentic Systems en arXiv. El artículo mide una superficie de ataque cada vez más común: los archivos de memoria en texto plano que los agentes de código leen como contexto de confianza — archivos de instrucciones cargados automáticamente como CLAUDE.md (Claude Code) y AGENTS.md (Codex), además de archivos de comportamiento y de conocimiento referenciados como core/behaviors.md y knowledge/*.md.

Los autores realizan sus experimentos en un espacio de trabajo sintético y aislado, contra dos sistemas agénticos de producción — Claude Code y OpenAI Codex — y cuatro modelos (Claude Opus 4.7, Claude Haiku 4.5, GPT-5.2, GPT-5.5). Cada condición se repite en 10 ensayos. El resultado principal: aunque es difícil hacer que un agente escriba contenido malicioso en su propia memoria a partir de una entrada externa no confiable, una carga ya presente en un archivo de memoria dirige de forma fiable la sesión actual, se vuelve a disparar con frecuencia en sesiones posteriores y a menudo permanece en el archivo después. El equipo indica que comunicó sus hallazgos a Anthropic y OpenAI de forma simultánea a la publicación.

Cómo funciona

La inyección indirecta clásica se parece a un XSS reflejado: una instrucción maliciosa se oculta en un contenido que el agente lee una vez (una página web, un ticket, un archivo) y actúa durante ese único turno. El marco que propone el artículo es que la inyección basada en memoria se parece a un XSS almacenado — la instrucción se escribe en un estado persistente y puede afectar a cualquier sesión futura que la cargue.

El modelo de amenaza es deliberadamente estrecho y realista. El adversario controla el contenido de un archivo persistente del espacio de trabajo que el agente puede cargar como contexto, pero no controla el modelo, el arnés ni el prompt del usuario. Cómo llega el archivo envenenado se considera fuera del alcance — el escenario plausible es un desarrollador que copia y pega un CLAUDE.md / AGENTS.md «compartido» o «listo para usar» desde un foro o repositorio público no confiable, es decir, un problema de cadena de suministro de configuración. Como estos archivos se tratan como si los hubiera escrito el usuario, la instrucción plantada se carga automáticamente al iniciar la sesión (en los archivos raíz) o cuando el agente considera relevante un archivo referenciado, y luego influye en una tarea por lo demás legítima.

Tres propiedades agravan la situación frente a una inyección única. Primero, la persistencia: la carga sobrevive de una sesión a otra. Segundo, el efecto acumulativo: una vez que el agente ha producido artefactos coherentes con la carga — por ejemplo, código que ya lee una credencial — una sesión posterior lo considera normal y desconfía menos. Tercero, la acumulación: varias cargas independientes pueden apilarse en la memoria con el tiempo. El estudio probó tres objetivos del atacante — exfiltración de credenciales, instalación no autorizada de una dependencia vulnerable conocida y promoción de marca encubierta — cada uno asociado a un tipo de archivo distinto. Aquí no se reproduce ninguna carga; el mecanismo anterior es el resultado conceptual, y los autores proporcionan un artefacto aislado para que los defensores reproduzcan la evaluación.

Por qué importa

Dos cifras replantean cómo pensar la memoria de los agentes. La tasa de éxito varió mucho según el modelo y el objetivo — el éxito medio en el primer intento osciló entre aproximadamente un 23 % (GPT-5.2) y un 63 % (Haiku 4.5), y algunas celdas alcanzaron el 100 % (por ejemplo, el uso no autorizado de herramientas en Haiku y el targeting de marca en GPT-5.5). Pero el hallazgo más incómodo es la brecha entre detectar y limpiar.

Persistencia y éxito no coinciden. Claude Opus 4.7 tuvo una de las tasas de éxito medias más bajas, pero la persistencia de carga más alta (~97 %): a menudo reconocía una instrucción como insegura, se negaba a actuar y luego la dejaba en el archivo de memoria. Esa es la combinación peligrosa, porque el artículo señala que los usuarios suelen degradar a un modelo más barato y menos robusto al acercarse a un límite de tokens — y ese modelo más débil es justamente el que tiene más probabilidades de obedecer la carga que el modelo más fuerte rechazó. Un rechazo que deja el veneno en su sitio no es una solución; es un aplazamiento hacia tu modelo menos capaz.

El estudio también muestra efectos de orden: rechazar un primer ataque volvía a los modelos más desconfiados ante un segundo, mientras que tener éxito en el primero bajaba su guardia. Esto importa, porque los archivos de memoria reales evolucionan a lo largo de muchas sesiones, no de una sola.

Defensas

El artículo es una evaluación defensiva, y sus recomendaciones se traducen en controles concretos:

1. Dejar de tratar la memoria persistente como uniformemente confiable. Los sistemas agénticos deben distinguir las verdaderas preferencias del usuario del contenido externo recuperado o compartido. Un archivo procedente de un repositorio o un foro no debería tener la misma autoridad que una instrucción que el usuario escribió en esta sesión. Es la misma confusión de autoridad que hay detrás del envenenamiento de la memoria de los agentes (ASI06).

2. Someter los archivos de memoria de alto impacto a una revisión explícita. Los cambios en CLAUDE.md, AGENTS.md y los archivos de comportamiento universales deberían exigir que el usuario vea y apruebe un diff, en lugar de cargarse o actualizarse en silencio.

3. Jerarquizar la memoria por nivel de confianza. Separa la memoria en niveles de política para que los archivos de conocimiento de baja confianza aporten datos pero no puedan anular las reglas de seguridad ni las restricciones de comportamiento globales. Una nota de preferencias técnicas nunca debería poder autorizar la lectura de una credencial.

4. Validar la memoria al inicio de cada sesión y eliminar de verdad lo que se señale. El resultado sobre la persistencia es la lección clave: detectar sin eliminar no sirve de nada cuando una sesión posterior puede ejecutarse en un modelo más débil. Si el agente identifica una instrucción plantada como maliciosa, la remediación debe retirarla del archivo, no solo negarse a seguirla esta vez.

5. Alejar los secretos del espacio de trabajo. Las cargas de exfiltración de credenciales solo rinden si las credenciales son accesibles. Guarda las claves de API y las credenciales de nube en un gestor, fuera del entorno en el que opera el agente — la misma lección que el trío letal.

6. Tratar las configuraciones de agente compartidas como dependencias no confiables. Un CLAUDE.md o AGENTS.md obtenido de internet merece el mismo escrutinio que un paquete no auditado. Léelo antes de soltarlo en un proyecto.

Estado

Elemento	Referencia	Fecha	Notas
Artículo Bad Memory (arXiv 2607.14611)	arXiv	2026-07-16	Claude Code + Codex; 4 modelos; 10 ensayos/condición
Sistemas / modelos probados	arXiv	2026-07-16	Claude Opus 4.7, Claude Haiku 4.5, GPT-5.2, GPT-5.5
Rango de éxito en el primer intento	arXiv	2026-07-16	~23 % (GPT-5.2) a ~63 % (Haiku 4.5); varias celdas al 100 %
Brecha de persistencia	arXiv	2026-07-16	Opus 4.7: menor éxito pero ~97 % de persistencia
Divulgación responsable	arXiv	2026-07-16	Comunicado a Anthropic y OpenAI a la vez que la publicación
Artefacto de reproducción	anonymous.4open.science	2026-07	Entorno aislado + arnés de ASR/persistencia multisesión

La lectura correcta no es «los agentes de código están rotos». Es que un archivo de memoria es un estado persistente, privilegiado y entre sesiones — y los agentes actuales lo van a leer, a veces obedecerlo y a menudo no limpiarlo. Si tu flujo de trabajo comparte o reutiliza archivos CLAUDE.md/AGENTS.md, trátalos como código que se revisa, no como notas que se creen sin más.