MemAudit: auditoría forense para hallar memoria de agente envenenada

¿Qué es esto?

Los agentes LLM persistentes recuerdan. Escriben resúmenes, «lecciones aprendidas» y hechos recuperados en un almacén a largo plazo, y luego devuelven esas entradas al contexto en turnos posteriores — a menudo para usuarios y tareas distintos. Ese almacén es una superficie de ataque. El envenenamiento de memoria inyecta contenido fabricado que parece un recuerdo corriente pero que, una vez recuperado, orienta al agente hacia el objetivo de un atacante: filtrar datos, invocar la herramienta equivocada o avalar una instrucción maliciosa. Como la carga llega por la vía de escritura normal y se dispara mucho después, no toca ni los pesos del modelo ni el código, y elude las defensas que solo inspeccionan el prompt actual.

La mayoría de las defensas publicadas son preventivas: intentan impedir que se escriban o recuperen entradas maliciosas. MemAudit, publicado en arXiv en mayo de 2026, adopta la postura contraria: suponer que algún veneno ya entró y dar a los equipos de respuesta una forma de auditar el almacén de memoria a posteriori. Se enmarca en una literatura en rápido crecimiento — un estudio de 2026 sobre seguridad de la memoria a largo plazo traza todo el ciclo de vida, y trabajos ofensivos como MemoryGraft muestran cómo una sola «experiencia» envenenada puede comprometer de forma persistente a un agente.

Cómo funciona

MemAudit se apoya en dos ideas presentes en su título: la atribución causal y la detección de anomalías estructurales.

La atribución causal responde a la pregunta forense «¿qué recuerdos causaron esto?». Cuando un agente produce una acción dañina o inesperada, el auditor necesita saber qué entradas almacenadas lo empujaron. En lugar de revisar a ojo miles de notas, el enfoque rastrea la influencia desde la acción observada hasta las entradas concretas que moldearon la decisión — convirtiendo «el agente se comportó mal» en «estas tres entradas, recuperadas juntas, dictaron el comportamiento». Esa es la diferencia entre saber que hubo una brecha y saber qué borrar.

La detección de anomalías estructurales trabaja en sentido inverso. Un almacén de memoria sano presenta regularidades: cómo se relacionan las entradas, cómo se agrupan, cómo se formulan y se referencian. Las entradas envenenadas suelen desentonar sobre ese fondo: una instrucción disfrazada de hecho, una nota conectada a muchas más recuperaciones que sus vecinas, un contenido cuya estructura no coincide con la forma habitual en que el agente se escribe a sí mismo. Señalar esos valores atípicos hace aflorar candidatas a revisión aunque ninguna entrada parezca maliciosa de forma aislada.

Usados juntos, ambos indicios se contrastan mutuamente. La detección de anomalías reduce el campo a las entradas sospechosas; la atribución causal confirma cuáles influyeron realmente en un mal resultado dado. No se necesita ningún payload de explotación para realizar la auditoría, y aquí no se reproduce ninguno — el objetivo es el triaje y la limpieza, no el ataque.

Por qué importa

El envenenamiento de memoria es una de las amenazas agénticas más difíciles, precisamente por el desfase temporal. La escritura y el daño están separados por horas, días o varias sesiones, de modo que el filtrado de entrada clásico y las barreras por turno no ven nada anómalo. En despliegues multiusuario, el radio de impacto crece: una entrada envenenada escrita durante su sesión puede recuperarse en la de otra persona. Existen defensas preventivas certificadas — véase SMSR, una propuesta de junio de 2026 con una cota de robustez — pero la prevención nunca es perfecta, y los equipos necesitan una respuesta a «creemos que la memoria está contaminada; ¿y ahora qué?». La auditoría forense es esa respuesta. Además, encarece el envenenamiento sigiloso y de combustión lenta: un atacante que contaba con una entrada eterna debe ahora sobrevivir a una auditoría capaz de remontar los efectos hasta sus causas.

Defensas

Trate el almacén de memoria como un estado relevante para la seguridad, no como un simple caché de conveniencia. En concreto: vincule cada entrada a su origen (quién la escribió, desde qué sesión y fuente) para que la atribución causal tenga algo que rastrear; mantenga un registro de solo anexado de escrituras y recuperaciones para que los incidentes sean reconstruibles; y separe la memoria por nivel de confianza y por inquilino para que una entrada envenenada no cruce al contexto de otro usuario. Realice auditorías periódicas — escaneos de anomalías estructurales más atribución ante cualquier acción sorprendente — en lugar de confiar en un filtro único. Exija procedencia y, cuando sea posible, una verificación humana antes de que un recuerdo pueda autorizar una llamada a una herramienta sensible, de modo que una nota recuperada nunca sea la única base de una acción irreversible. Por último, haga que el borrado sea real: cuando una auditoría señale una entrada, elimínela junto con todo lo derivado de ella y vuelva a probar.

Estado

Elemento	Referencia	Notas
MemAudit (auditoría a posteriori)	arXiv 2605.23723, mayo de 2026	Atribución causal + detección de anomalías estructurales
Panorama de la amenaza	arXiv 2604.16548, 2026	Estudio de seguridad de la memoria a largo plazo en todo el ciclo
Ataque representativo	arXiv 2512.16962 (MemoryGraft)	Compromiso persistente vía recuperación de experiencia envenenada
Prevención certificada	arXiv 2606.12703 (SMSR), junio de 2026	Defensa preventiva complementaria con cota de robustez

El giro de fondo va de «¿podemos impedir que entre el veneno?» a «¿podemos encontrarlo una vez dentro?». Ambas preguntas importan: la prevención reduce la probabilidad, la auditoría forense acota el daño cuando la prevención falla. Para cualquier agente que escriba en memoria duradera, prevea las dos.