Investigadores han demostrado que una sola interacción puede introducir una instrucción persistente en la memoria de un agente de IA e influir en respuestas posteriores sobre el mismo tema. El estudio InjecMEM, presentado el 24 de agosto de 2026 y aceptado en COLM 2026, trata la memoria como un límite de seguridad y no como una función de comodidad.
El resultado no demuestra que todos los agentes con memoria sean vulnerables. Los experimentos se centran principalmente en MemoryOS y también prueban MemGPT, varias familias de modelos de pesos abiertos y una salida objetivo controlada sin efecto operativo. El ataque más potente supone además acceso al modelo subyacente para optimizarlo. Dentro de esos límites, el estudio ofrece una advertencia concreta: un atacante podría no necesitar acceso directo a la base de datos para envenenar el estado persistente de un agente.
Cómo funciona el ataque InjecMEM
Muchos agentes guardan interacciones anteriores, recuperan registros relevantes y los insertan en un prompt posterior. InjecMEM ataca las dos partes de ese ciclo.
Primero, el atacante envía una interacción preparada que incluye un ancla temática. El ancla utiliza indicios amplios para que el sistema de memoria asocie el registro con un tema objetivo, como salud o finanzas. Después, la interacción contiene una instrucción adversaria optimizada para seguir siendo eficaz cuando el registro aparece en distintas posiciones dentro de un prompt largo y cambiante.
Cuando otro usuario formula más tarde una pregunta inocua sobre el tema, el sistema puede recuperar el registro envenenado. Si la recuperación tiene éxito, la instrucción puede dirigir el modelo hacia una salida predefinida. El atacante no necesita leer ni editar directamente el almacén de memoria.
El estudio también describe una vía indirecta. Una herramienta comprometida podría devolver texto malicioso que el agente almacena como memoria. Repararla no eliminaría automáticamente el registro guardado.
Qué encontraron los experimentos
Los autores separan el éxito de recuperación del éxito de generación. La primera medida pregunta si el registro envenenado aparece ante una consulta posterior relacionada con el tema. El éxito condicional pregunta si el modelo produce la salida objetivo después de recuperar ese registro.
| Resultado experimental | MemoryOS | MemGPT |
|---|---|---|
| Recuperación media del registro envenenado | 46,5 % | 37,2 % |
| Éxito condicional de la generación dirigida | 76,6 % | 48,6 % |
| Éxito conjunto de extremo a extremo indicado por el estudio | 35,6 % | 18,1 % |
Son resultados de investigación, no tasas de incidentes en producción. La salida objetivo no tenía efecto operativo. El ataque siguió funcionando mientras se acumulaban memorias inocuas y se transfirió dentro de algunas familias. La transferencia entre familias fue menos fiable. Una instrucción optimizada sobre Qwen y Mistral no funcionó en un modelo Llama no visto, aunque concatenar instrucciones produjo un éxito medible en las tres familias evaluadas.
Los investigadores también probaron filtros durante la recuperación. Un juez LLM, ProtectAI y PromptGuard redujeron la recuperación en algunos casos, pero dejaron el éxito condicional cerca del nivel sin defensa. Un filtro de perplejidad suprimió el ataque, pero bloqueó el 71,8 % de las páginas inocuas. El filtrado puede volver inutilizable la memoria sin resolver el problema de confianza.
Por qué la memoria persistente cambia el modelo de seguridad
Una inyección de prompt normal puede afectar a una respuesta. Una memoria envenenada puede reaparecer más tarde, cuando el operador ya ha olvidado la interacción original. También puede alcanzar otro flujo si la memoria se comparte entre tareas, usuarios o agentes.
OWASP identifica de forma independiente el envenenamiento de memoria y contexto como riesgo de las aplicaciones con agentes. Sus recomendaciones tratan el contexto, los resúmenes, los hooks y la configuración local como estado de seguridad porque influyen en la planificación y el uso de herramientas. Ese modelo respalda la preocupación, pero no reproduce los porcentajes de InjecMEM.
Para los equipos que operan agentes con herramientas, la consecuencia va más allá de una respuesta incorrecta. Una instrucción recuperada puede influir en qué API se utiliza, qué datos se revelan o si una acción posterior sigue alineada con la tarea del usuario. La guía de Maetra sobre controles de inyección de prompt explica por qué la inspección de contenido debe combinarse con autoridad limitada sobre los efectos externos.
Seis controles para revisar ahora
- Tratar las escrituras de memoria como entrada no fiable. Analizar y clasificar los registros antes de hacerlos persistentes. Un resumen generado por el agente no es seguro por defecto.
- Registrar la procedencia. Conservar la fuente, la identidad del usuario o herramienta, la hora, la tarea y el historial de transformación de cada registro.
- Separar inquilinos y tareas. Impedir que un registro cruce límites de usuario, espacio de trabajo o finalidad sin una política explícita.
- Aplicar retención y revocación. Dar caducidad a las memorias sensibles, permitir el borrado selectivo e invalidar registros ligados a una fuente comprometida.
- Comprobar al escribir y al leer. Un filtro de recuperación puede omitir un ataque o bloquear demasiado contenido inocuo. Se necesitan validación, detección de anomalías y políticas en ambas etapas.
- Limitar el efecto del texto recuperado. La memoria puede informar el razonamiento, pero no debe conceder credenciales ni autoridad. Las llamadas a herramientas con consecuencias siguen necesitando un control independiente y evidencia de auditoría de IA útil.
Las pruebas deben cubrir una sola interacción, salidas de herramientas, deriva, memoria compartida, borrado, recuperación y cambios de modelo. Un registro eliminado no debe recuperar influencia tras reconstruir un índice o restaurar una copia de seguridad.
Qué sigue siendo incierto
El artículo es un estudio aceptado en una conferencia, pero sigue siendo una evaluación acotada. La optimización más fuerte utiliza acceso al modelo que un atacante podría no tener. Los sistemas que reescriben o resumen intensamente las interacciones antes de guardarlas pueden comportarse de otra manera. Los autores tampoco muestran una transferencia fiable a todas las familias de modelos no vistas.
Los porcentajes no deben convertirse en una estimación universal de riesgo. Una evaluación práctica debe utilizar la implementación real de memoria, la lógica de recuperación, el modelo, el formato del prompt, las herramientas, los permisos y los límites de datos de producción.
Análisis de Maetra: la memoria necesita su propio ciclo de control
La memoria del agente debe inventariarse como cualquier otra capacidad con consecuencias. Los equipos necesitan saber qué se guarda, quién o qué lo escribió, dónde puede recuperarse, en qué acciones puede influir y cómo se revoca.
Empiece con un agente que conserve contexto entre sesiones. Siga un registro desde la entrada hasta la recuperación y después hasta cualquier llamada a herramienta o efecto externo. Si puede influir en una acción sin procedencia, política ni evidencia, la capa de memoria ya forma parte del plano de control, aunque el producto la describa solo como personalización.
Fuentes
- InjecMEM: Memory Injection Attack on LLM Agent Memory Systems, presentado el 24 de agosto de 2026 e incluido como aceptado en COLM 2026.
- Artículos aceptados en COLM 2026, consultado el 25 de agosto de 2026.
- OWASP: Memory Is a Feature. It Is Also an Attack Surface, publicado el 13 de mayo de 2026.