Inyección almacenada: cuando una inyección sobrevive a la sesión

What is this?

El artículo What If Prompt Injection Never Left? Exploring Cross-Session Stored Prompt Injection in Agentic Systems, publicado en arXiv en junio de 2026, plantea una idea precisa: la mayoría de la investigación sobre inyección de prompts estudia una única ventana de contexto, pero los agentes modernos conservan estado. Memorias, archivos, borradores, puntos de control (checkpoints) y artefactos visibles para las herramientas persisten entre ejecuciones. En cuanto un texto malicioso alcanza uno de esos almacenes, la inyección no termina con la conversación: puede releerse en un contexto de ejecución futuro, para el mismo usuario o para otro.

Los autores toman prestado deliberadamente el vocabulario de la seguridad web. La inyección de prompts clásica se comporta como un XSS reflejado: la entrada maliciosa se procesa una vez, en el turno que la entregó. La inyección almacenada entre sesiones se comporta como un XSS almacenado: la carga se escribe en el estado persistente y se vuelve a servir más tarde. La distinción importa, porque las defensas, las ventanas de detección y el radio de impacto son distintos.

No es un ataque inédito inventado aquí: el artículo formaliza un patrón que los profesionales ya venían reportando. La Unit 42 de Palo Alto documentó una inyección indirecta que envenena la memoria a largo plazo de un agente, y el argumento más amplio de que el despliegue agéntico empeora la inyección se expone en el análisis de Christian Schneider. El aporte del artículo de junio es el encuadre a nivel de sistema.

How it works

El mecanismo es estructural, no una cadena ingeniosa. Un agente lee contenido no confiable durante una tarea — una página web, un documento, el resultado de una herramienta, el mensaje de otro agente. En ese contenido hay una instrucción oculta. En lugar de actuar solo en el momento (o además de hacerlo), el agente escribe un residuo de ese contenido en su estado persistente: una entrada de memoria, un archivo de notas, un historial resumido, un plan guardado.

En una ejecución posterior, el prompt de orquestación del agente se ensambla en parte a partir de ese estado persistente. El agente trata su propia memoria y sus archivos como contexto con autoridad y no como entrada no confiable — así, la instrucción implantada se reincorpora y puede influir en el comportamiento, por ejemplo empujando al agente a reenviar discretamente el historial de la conversación o a ejecutar una acción que el nuevo usuario nunca pidió.

Sesión 1 (atacante presente)
  contenido no confiable ──▶ agente ──▶ escribe un residuo en el ESTADO PERSISTENTE
                                         (memoria / archivo / resumen / checkpoint)

   ... el atacante se va, pasa el tiempo, la monitorización se reinicia ...

Sesión N (víctima presente)
  ESTADO PERSISTENTE ──▶ prompt de orquestación ──▶ el agente actúa sobre la instrucción implantada

El artículo destaca varios canales de persistencia que hacen el ataque duradero. Un estado registrado en checkpoint y luego reanudado permite que una inyección quede latente más allá de un lapso temporal, frustrando a los monitores que esperan un efecto inmediato. Un historial de solo anexado (por ejemplo, funciones reductoras que solo añaden a un registro de mensajes compartido) puede volver casi permanente una inyección de inicio de sesión. No reproducimos aquí una carga funcional — la lección no lo requiere. La clave: cualquier ruta de escritura desde contenido no confiable hacia un estado reutilizado es un canal candidato.

Why it matters

Las defensas de una sola sesión pierden esta clase por construcción. Una barrera que inspecciona el turno actual, o un sandbox que se reinicia por tarea, puede ser perfectamente eficaz y aun así dejar pasar una inyección almacenada, porque la instrucción maliciosa llega desde el estado de confianza del propio agente, en un turno limpio. Un artículo complementario de mayo de 2026 sostiene sin rodeos que los agentes de IA podrían caer siempre en la inyección de prompts; la persistencia eleva las apuestas de ese pesimismo, porque el coste de una sola inyección exitosa ya no se limita a una conversación.

La dimensión entre usuarios es lo que los defensores subestiman. Si el estado persistente es compartido — un almacén de memoria de equipo, una base de conocimiento común, un agente multiinquilino — una inyección implantada por un usuario puede aflorar en la sesión de otro. Esto convierte una molestia por sesión en algo más cercano a un punto de apoyo persistente, con una ventana de detección medida en días en lugar de segundos.

Defenses

Ningún control aislado elimina esta clase; el objetivo es romper el ciclo de escribir-y-luego-reutilizar y tratar el estado persistente como no confiable.

• Trate la memoria y los archivos como entrada no confiable, no como contexto con autoridad. El error de fondo es que el agente confía en su propio estado. Revalide el contenido persistente al leerlo con el mismo rigor que el contenido externo nuevo, en vez de suponer «está en mi memoria, luego es verdad».
• Separe lo confiable de lo no confiable en la capa de almacenamiento. Etiquete o compartimente el estado por procedencia. El contenido derivado de fuentes no confiables debe ponerse en cuarentena y nunca inyectarse directamente en prompts de orquestación o planificación sin saneamiento.
• Haga explícitas y auditables las escrituras al estado persistente. Condicione las escrituras de memoria mediante política: qué se puede escribir, desde qué tarea, desde qué fuente. Registre cada escritura con su procedencia para que una investigación posterior pueda rastrear un comportamiento hasta la sesión que lo implantó.
• Acote y caduque el estado de forma agresiva. Prefiera el aislamiento por usuario y por tarea frente a una memoria mutable compartida. Aplique TTL y olvido para que el contenido latente no pueda esperar indefinidamente una reanudación. Evite los diseños de solo anexado para todo lo que retroalimente los prompts.
• Vigile efectos diferidos y entre sesiones, no solo inmediatos. Una detección que solo revisa el turno de llegada de una entrada se perderá el checkpoint-y-reanudación. Vigile lecturas anómalas de memoria, exfiltraciones inesperadas y comportamientos que se desvíen de la solicitud del usuario actual.
• Restrinja las rutas de exfiltración desde el contexto del agente. La mayoría de las cargas de inyección almacenada terminan en una acción saliente — un mensaje, una llamada a herramienta, una petición. Herramientas de mínimo privilegio y monitorización de la salida reducen lo que una instrucción reactivada puede lograr.

Status

Aspecto	Inyección reflejada (clásica)	Inyección almacenada entre sesiones
Vida útil	Una ventana de contexto	Persiste en memoria / archivos / checkpoints
Disparador	El turno que la entrega	Una ejecución posterior que relee el estado
Víctima	La sesión actual	Sesiones futuras, incluso otros usuarios
Ventana de detección	Inmediata	Diferida (días), sobrevive a los reinicios
Control principal	Barreras de entrada/salida	Estado tipado por procedencia, escrituras controladas, aislamiento

La lección del artículo de junio de 2026 no es un nuevo exploit sino un desplazamiento del modelo de amenaza: en un agente con estado, el artefacto duradero es la vulnerabilidad. Una sola inyección que alcanza el estado persistente da al atacante un tiempo y un alcance que una inyección de un solo turno nunca permite, y las defensas pensadas únicamente para la ventana de contexto actual seguirán pasándola por alto.