Los agentes de inteligencia artificial que consultan páginas web, documentos o correos electrónicos pueden encontrar instrucciones maliciosas escondidas entre el contenido legítimo. El riesgo aumenta cuando el sistema guarda lo aprendido en una memoria persistente: la orden queda almacenada, sobrevive al cierre de la sesión y puede activarse días después. Una demostración desarrollada con Strands Agents reproduce este ataque y muestra por qué las decisiones sensibles deben quedar protegidas por reglas que el modelo no pueda saltarse.
Las claves del envenenamiento de memoria en agentes de IA en 20 segundos
- El ataque llega desde fuera: una web, un PDF o un correo puede contener instrucciones dirigidas al agente y no al usuario.
- La memoria amplía el riesgo: el contenido malicioso puede guardarse y reaparecer en conversaciones posteriores.
- Un mejor prompt no basta: pedir al modelo que ignore instrucciones sospechosas ayuda, pero no constituye una barrera de seguridad fiable.
- La demo reproduce un ataque real entre sesiones: un agente nuevo recupera una memoria contaminada desde disco y trata de enviar información a un atacante.
- La defensa se aplica antes de ejecutar la herramienta: un hook revisa el destinatario y cancela el correo cuando el dominio no está autorizado.
- La memoria sigue envenenada: el control evita una acción concreta, pero no elimina el contenido malicioso almacenado.
- En producción hacen falta varias capas: políticas de escritura y lectura de memoria, permisos mínimos, validación de herramientas, registros de auditoría y aprobación humana para acciones sensibles.
El ataque no termina cuando se cierra la conversación
La inyección de prompts aparece cuando un modelo interpreta como una orden el texto que debía tratar únicamente como información. Puede ser directa, cuando el propio usuario escribe la instrucción, o indirecta, cuando esta se encuentra dentro de una fuente externa consultada por el sistema.
Un agente que navega por internet para comparar hoteles podría leer una página con una frase oculta que le pide enviar las futuras reservas a una dirección ajena. El usuario no ha pronunciado esa orden y el atacante tampoco necesita acceder al servidor. Le basta con publicar contenido que sabe que el agente terminará procesando.
En una aplicación sin memoria el efecto podría limitarse a esa ejecución. El problema cambia cuando el agente resume la página y guarda sus conclusiones para utilizarlas más adelante. La instrucción deja de presentarse como contenido externo y reaparece dentro de una memoria que el sistema considera propia.
Ese comportamiento se conoce como envenenamiento de memoria. El agente puede recuperar la orden semanas después, durante una petición completamente normal, y actuar como si formara parte de las preferencias del usuario o de sus procedimientos internos.
El trabajo académico Zombie Agents: Persistent Control of Self-Evolving LLM Agents via Self-Reinforcing Injections, publicado en febrero de 2026, estudia precisamente esta persistencia. Sus autores muestran cómo una inyección indirecta puede incorporarse al estado de un agente, sobrevivir entre sesiones y provocar posteriormente el uso no autorizado de herramientas. La investigación también advierte de que los filtros aplicados únicamente al prompt de cada conversación resultan insuficientes cuando el contenido peligroso ya está dentro de la memoria.
Esto no significa que las instrucciones del sistema, los clasificadores o la separación visual del contenido externo sean inútiles. Pueden reducir el número de ataques que llegan a funcionar. El problema es confiar en ellos como única defensa cuando el modelo tiene capacidad para enviar mensajes, consultar bases de datos, modificar archivos, ejecutar código o autorizar operaciones.
OWASP mantiene la inyección de prompts como el primer riesgo de su lista para aplicaciones basadas en grandes modelos de lenguaje. La organización reconoce que no existe un método infalible para prevenirla y recomienda combinar controles como el mínimo privilegio, la separación del contenido no confiable, la validación determinista, la aprobación humana y las pruebas adversariales.
Una demo que infecta, reinicia y bloquea al agente
El repositorio resilient-agent-harness-sample-for-aws, publicado por Elizabeth Fuentes, incluye varias demostraciones sobre fallos de agentes de IA. Una de ellas está dedicada al envenenamiento de memoria y utiliza como ejemplo un asistente de reservas de hotel.
El ejercicio se divide en tres fases. En la primera se escriben en la memoria del agente una nota normal y otra contaminada. Esta última contiene una instrucción para enviar información de las reservas a una dirección controlada por un supuesto atacante.
La memoria se almacena en agent.state, el mecanismo nativo de estado de Strands Agents, y se conserva en el sistema de archivos mediante FileSessionManager. La persistencia no se simula manteniendo una variable activa en el mismo proceso. La demostración crea posteriormente otro agente, que recupera desde disco el estado guardado por la sesión anterior.
En la segunda fase el nuevo agente recibe una solicitud de reserva normal. Al recuperar la memoria contaminada, intenta utilizar la herramienta send_email para remitir los datos a [email protected]. El repositorio registra la ejecución real de la herramienta, en lugar de limitarse a buscar en la respuesta del modelo una frase como “correo enviado”.
La tercera fase repite la prueba con una defensa añadida. Antes de que se ejecute send_email, un hook asociado a BeforeToolCallEvent extrae el destinatario y comprueba si su dominio aparece en una lista autorizada. Cuando el dominio no coincide con los permitidos, asigna un mensaje a event.cancel_tool y la llamada queda anulada.
El resultado publicado por la demostración es claro: sin la regla, la herramienta de correo se ejecuta una vez contra la dirección del atacante; con el control activo, ningún mensaje peligroso alcanza la ejecución. La documentación oficial de Strands confirma que FileSessionManager persiste los mensajes y el estado del agente en el sistema de archivos, mientras que los hooks previos a una herramienta permiten cancelar o modificar la operación antes de que se realice.
La diferencia importante está en quién toma la decisión. Un prompt como “no envíes información a personas desconocidas” sigue dependiendo de que el modelo interprete bien la situación y obedezca. Una lista de dominios aplicada mediante código no le pide que se comporte correctamente: impide materialmente la acción cuando no cumple la política.
La técnica es sencilla, pero representa una idea útil para cualquier arquitectura agéntica. El modelo puede proponer una operación, pero una capa externa debe decidir si está autorizada. Esa separación se parece más a los controles tradicionales de una aplicación que a una conversación con un asistente.
Bloquear un correo no limpia una memoria contaminada
La demostración prueba que una regla en la frontera de herramientas puede contener una vía concreta de exfiltración. No demuestra que la inyección haya desaparecido ni ofrece una protección universal contra cualquier acción maliciosa.
La nota envenenada continúa dentro de la memoria. Si el agente dispone de otras herramientas podría intentar enviar la información mediante una aplicación de mensajería, una invitación de calendario, una petición HTTP, un archivo compartido o un formulario web. Una lista aplicada únicamente al correo no cubriría esos canales.
Incluso la validación del destinatario necesita más cuidado en un sistema real. Hay que normalizar las direcciones, tratar correctamente subdominios y alias, evitar comparaciones ambiguas y comprobar todos los destinatarios, incluidos los campos de copia. También conviene limitar el contenido que puede salir, el tamaño de los archivos adjuntos y el tipo de información que cada herramienta puede consultar.
La política tampoco debería residir en un lugar que el propio agente pueda modificar. Si la memoria tiene capacidad para alterar configuraciones, crear herramientas o editar el código que contiene la lista de dominios, el atacante podría intentar desactivar la protección. Las reglas sensibles deben mantenerse fuera del contexto controlado por el modelo y estar protegidas mediante permisos independientes.
Una defensa de producción comienza antes de la llamada a la herramienta. El contenido procedente de internet, correos y documentos debe conservar información sobre su origen y nivel de confianza. No debería convertirse automáticamente en una preferencia permanente ni mezclarse con instrucciones verificadas por el usuario.
Las escrituras en memoria necesitan una política propia. Algunos datos pueden guardarse directamente, mientras que otros deberían permanecer en cuarentena, caducar después de un tiempo o exigir confirmación. Las órdenes que intentan cambiar permisos, destinatarios, credenciales o procedimientos internos no deberían almacenarse como simples hechos.
También debe revisarse la recuperación. Una memoria antigua no gana legitimidad por el mero hecho de proceder del almacén interno. El sistema tiene que conservar su procedencia, distinguir entre observaciones externas y decisiones confirmadas y evitar que una nota recuperada adquiera la misma prioridad que las reglas de seguridad.
Después aparece la frontera de herramientas. Cada operación debe utilizar credenciales con el menor privilegio posible y aceptar parámetros ajustados a su función. Un asistente que prepara borradores no necesita permiso para enviarlos; uno que consulta el calendario no tiene por qué modificarlo; y un agente que busca hoteles no debería acceder automáticamente a toda la agenda de contactos.
Las acciones irreversibles o con consecuencias económicas, legales o de privacidad requieren un paso adicional. Enviar información sensible, realizar pagos, borrar archivos, publicar contenido o cambiar permisos son buenos candidatos para una aprobación humana explícita.
Los registros completan el diseño. La organización debe poder saber qué memoria se recuperó, qué herramienta solicitó el modelo, qué parámetros propuso, qué regla tomó la decisión y si la operación llegó a ejecutarse. Sin esa trazabilidad, un incidente puede quedar oculto detrás de una respuesta aparentemente normal.
La principal enseñanza del ejemplo no es que una allowlist resuelva la inyección de prompts. Su valor está en demostrar que un agente debe considerarse una parte no confiable del sistema, incluso cuando consulta su propia memoria. Puede razonar y proponer acciones, pero los límites efectivos tienen que vivir en código, políticas y servicios que no dependan de su voluntad.
Preguntas frecuentes
¿Qué diferencia hay entre inyección indirecta y envenenamiento de memoria?
La inyección indirecta se introduce mediante contenido externo que lee el agente. El envenenamiento aparece cuando ese contenido se guarda y vuelve a influir en el sistema durante sesiones posteriores.
¿Un buen prompt del sistema puede evitar por completo el ataque?
No. Puede reducir algunos intentos, pero el modelo sigue procesando instrucciones y datos dentro del mismo contexto. Las acciones sensibles necesitan controles deterministas fuera del modelo.
¿Qué bloquea exactamente la demo de Strands Agents?
Bloquea el uso de la herramienta de correo cuando el destinatario no pertenece a uno de los dominios incluidos en una lista autorizada. No elimina la memoria contaminada ni protege automáticamente otras herramientas.
¿Qué controles debería tener un agente que lee la web o el correo?
Debería registrar la procedencia del contenido, controlar qué entra en memoria, revisar qué se recupera, limitar permisos, validar cada herramienta, exigir aprobación en operaciones sensibles y mantener una auditoría completa.
Puedes acceder el código en GitHub desde este repo: resilient-agent-harness-sample-for-aws. Y en esta publicación también hablamos de la demo de Memory Poisoning Defense (02-memory-poisoning-defense). Clona el repositorio y síguelo el paso a paso.
vía: dev.to
