Detectar el envenenamiento de memoria de un agente solo con sus logs de herramientas

¿Qué es esto?

Cuando un agente LLM conserva una memoria persistente, un atacante puede depositar una instrucción maliciosa en ella durante una sesión y hacer que se dispare mucho más tarde en otra. Este «envenenamiento del canal de memoria» es difícil de detectar: los filtros de entrada y los controles de la capa de recuperación nunca ven la sesión desencadenante, y el agente guarda la regla maliciosa a través de su propia vía de escritura autorizada, por lo que nada parece anómalo en el momento de la escritura.

Un artículo publicado en arXiv el 30 de junio de 2026 (Forensic Trajectory Signatures for Agent Memory Poisoning Detection) aporta una observación útil para la defensa: aunque el envenenamiento en sí sea invisible, la ejecución del ataque no lo es. Cuando un agente envenenado finalmente actúa, tiene que recuperar el dato almacenado por el atacante antes de poder usarlo, y esa recuperación aparece en el log de llamadas a herramientas. El autor toma prestado el marco de la detección clásica en el endpoint: igual que un IDS de host detecta intrusiones a partir de secuencias de llamadas al sistema sin leer la memoria del proceso, la traza de llamadas a herramientas de un agente puede delatar un ataque por el canal de memoria sin inspeccionar el almacén de memoria, los pesos del modelo ni el contenido de ningún mensaje.

Cómo funciona

El estudio se centra en un ataque de exfiltración con disparo diferido. Un documento de «cumplimiento» malicioso se recupera vía RAG, el agente guarda dócilmente una regla de enrutamiento (una dirección de destino controlada por el atacante) en su memoria persistente y, en una sesión posterior, recuerda esa regla y envía datos al atacante.

El punto estructural clave es que la dirección de destino se almacena como un valor de memoria, no como una clave. Listar la memoria solo devuelve nombres de clave: para saber a dónde enviar los datos, el agente debe llamar a la operación de recuperación antes que a la de envío. Las sesiones benignas —o aquellas en las que una defensa bloqueó el ataque— se saltan esa recuperación y redactan su mensaje directamente. El resultado es un invariante de comportamiento que el autor denomina recall-before-send: en cada sesión de ataque exitosa del conjunto de datos, el primer recall precedía estrictamente al primer send, sin ninguna excepción.

Esa única regla, aplicada a los logs de la sesión desencadenante, ya separa los ataques exitosos de los no ataques con un área bajo la curva de aproximadamente 0,96. Un pequeño clasificador sobre unas diecinueve características de trayectoria (recuentos de llamadas, transiciones de pares de herramientas, punto de entrada) lo eleva a cerca de 0,99 y, lo que es importante, la señal está sobredeterminada: eliminar todas las características relacionadas con el recall deja la puntuación prácticamente igual, porque recuperar la regla desencadena una cascada posterior (una segunda redacción, un envío adicional) que se imprime también en otras características. La firma se mantiene en nueve modelos de código abierto de 7B a 120B parámetros y se transfiere a modelos de frontera sin reentrenamiento. Describimos el mecanismo de detección, no una receta de ataque.

Por qué importa

El envenenamiento de memoria es una de las amenazas de agente más difíciles de prevenir: trabajos relacionados del mismo autor muestran que cinco de las seis clases de defensa fracasan ante este ataque con disparo diferido, porque la mayoría ni siquiera puede observar la superficie afectada. Un método de detección que solo necesita los logs de llamadas a herramientas resulta atractivo, precisamente porque esos logs ya los emiten los frameworks de producción como LangChain, LangGraph, OpenAI Assistants y el uso de herramientas de Anthropic. Sin inspección de memoria, sin acceso a los internos del modelo, sin inferencia adicional: un umbral operativo mucho más bajo que las defensas que exigen modificar el almacén de memoria o leer activaciones.

El enfoque también ayuda con la atribución. Un ataque por inyección de prompt que lleva el destino en el prompt actual no necesita un recall de memoria, así que produce una trayectoria distinta. Eso permite a un respondedor de incidentes distinguir un ataque por el canal de memoria de una inyección de prompt ordinaria a partir del solo log de operaciones: una frontera forense realmente útil para reconstruir qué hizo un agente, y por qué.

Defensas

Considérelo una detección que complementa la prevención, no que la sustituye.

• Registre cada llamada a herramienta con marca de tiempo. Todo el método asume logs de invocación ordenados y con marca temporal. Asegúrese de capturar lecturas de memoria, redacciones y envíos; una recuperación que eluda la capa de herramientas (cachés internas, inyección implícita de contexto) no deja firma.
• Alerte sobre recall-before-send. Marque las sesiones desencadenantes en las que un recall de memoria precede a una acción saliente hacia un destino inusual. Es barato, sin acceso al modelo, y por sí solo captura el patrón dominante.
• Detecte en dos capas. Un clasificador de prefijo puede marcar sesiones sospechosas en tiempo real antes de que el envío se complete (con una ligera pérdida de precisión), respaldado por un clasificador de sesión completa para la auditoría forense a posteriori.
• Conserve la prevención estructural. La detección no detiene el ataque. Restringir la recuperación de memoria en la capa de herramientas (para que el agente no pueda recordar en silencio datos de enrutamiento controlados por el atacante) sigue siendo el control estructural más sólido; combínelo con procedencia en las escrituras de memoria.
• Calibre por modelo. Los modelos de razonamiento que llaman a menudo al recall para autoverificarse elevan los falsos positivos. Ajuste los umbrales por despliegue y excluya de un umbral compartido los modelos con hábitos de recall atípicos.

Estado

Elemento	Valor
Clase	Detección forense del envenenamiento del canal de memoria (defensa)
Señal	Invariante de llamadas a herramientas «recall-before-send» en la sesión desencadenante
Entradas necesarias	Solo logs de llamadas a herramientas: ni memoria, ni pesos, ni contenido de mensajes
Precisión reportada	~0,96 AUC (regla simple) a ~0,99 (clasificador completo); generaliza de 7B a 120B y a modelos de frontera
Punto ciego conocido	Ataques de elusión implícita que exfiltran sin un recall de memoria
Divulgado	30 de junio de 2026 (artículo de investigación)

Fechas clave: 30 de junio de 2026 — artículo sobre detección mediante firmas de trayectoria (arXiv 2606.30566), apoyado en un estudio mecanicista de junio de 2026 que concluye que la mayoría de las defensas fracasan ante los ataques de memoria con disparo diferido. Trabajos relacionados de junio de 2026 sistematizan los canales de escritura del envenenamiento de memoria (MPBench, arXiv 2606.04329) y la inyección de prompt almacenada entre sesiones (arXiv 2606.04425); los ataques de control persistente se mostraron antes en 2026 (Zombie Agents, arXiv 2602.15654). Los nombres de modelos citados son los reportados en los artículos fuente.