Injection stockée : quand une injection survit à la session

What is this?

Le papier What If Prompt Injection Never Left? Exploring Cross-Session Stored Prompt Injection in Agentic Systems, déposé sur arXiv en juin 2026, formule un constat net : la recherche sur la prompt injection étudie le plus souvent une fenêtre de contexte unique, alors que les agents modernes conservent un état. Mémoires, fichiers, brouillons, points de reprise (checkpoints) et artefacts visibles par les outils persistent d’une exécution à l’autre. Dès qu’un texte malveillant atteint l’un de ces magasins, l’injection ne s’arrête pas avec la conversation : elle peut être relue dans un contexte d’exécution futur, pour le même utilisateur ou pour un autre.

Les auteurs empruntent délibérément le vocabulaire de la sécurité web. La prompt injection classique se comporte comme un XSS réfléchi : l’entrée malveillante est traitée une fois, dans le tour qui l’a délivrée. L’injection stockée inter-sessions se comporte comme un XSS stocké : la charge est écrite dans l’état persistant puis re-servie plus tard. La distinction compte, car les défenses, les fenêtres de détection et le rayon d’impact diffèrent.

Ce n’est pas une attaque inédite inventée ici — le papier formalise un schéma déjà rapporté par les praticiens. L’Unit 42 de Palo Alto a documenté une injection indirecte empoisonnant la mémoire long terme d’un agent, et l’argument plus large selon lequel le déploiement agentique aggrave l’injection est exposé dans l’analyse de Christian Schneider. L’apport du papier de juin est le cadrage au niveau système.

How it works

Le mécanisme est structurel, pas une chaîne astucieuse. Un agent lit du contenu non fiable pendant une tâche — une page web, un document, un résultat d’outil, le message d’un autre agent. Une instruction y est dissimulée. Au lieu d’agir uniquement sur le moment (ou en plus de cela), l’agent écrit un résidu de ce contenu dans son état persistant : une entrée de mémoire, un fichier de notes, un historique résumé, un plan sauvegardé.

Lors d’une exécution ultérieure, le prompt d’orchestration de l’agent est assemblé en partie à partir de cet état persistant. L’agent traite sa propre mémoire et ses fichiers comme un contexte faisant autorité plutôt que comme une entrée non fiable — l’instruction implantée est donc réintégrée et peut influencer le comportement, par exemple en poussant l’agent à transférer discrètement l’historique de conversation ou à exécuter une action que le nouvel utilisateur n’a jamais demandée.

Session 1 (attaquant présent)
  contenu non fiable ──▶ agent ──▶ écrit un résidu dans l'ÉTAT PERSISTANT
                                    (mémoire / fichier / résumé / checkpoint)

   ... l'attaquant part, le temps passe, la surveillance se réinitialise ...

Session N (victime présente)
  ÉTAT PERSISTANT ──▶ prompt d'orchestration ──▶ l'agent agit sur l'instruction implantée

Le papier met en avant plusieurs canaux de persistance qui rendent l’attaque durable. Un état mis en checkpoint puis repris permet à une injection de rester dormante au-delà d’un intervalle temporel, mettant en échec les moniteurs qui attendent un effet immédiat. Un historique en ajout seul (par exemple des fonctions de réduction qui ne font qu’ajouter à un journal de messages partagé) peut rendre quasi permanente une injection de début de session. Nous ne reproduisons pas de charge fonctionnelle ici — la leçon n’en a pas besoin. L’essentiel : tout chemin d’écriture du contenu non fiable vers un état réutilisé est un canal candidat.

Why it matters

Les défenses mono-session ratent cette classe par construction. Un garde-fou qui inspecte le tour courant, ou un bac à sable réinitialisé à chaque tâche, peut être parfaitement efficace et laisser malgré tout passer une injection stockée, car l’instruction malveillante arrive depuis l’état de confiance de l’agent lui-même, dans un tour propre. Un papier complémentaire de mai 2026 affirme sans détour que les agents IA pourraient toujours tomber dans la prompt injection ; la persistance relève la mise de ce pessimisme, car le coût d’une seule injection réussie n’est plus borné à une conversation.

La dimension inter-utilisateurs est ce que les défenseurs sous-estiment. Si l’état persistant est partagé — magasin de mémoire d’équipe, base de connaissances commune, agent multi-tenant — une injection implantée par un utilisateur peut ressurgir dans la session d’un autre. On passe d’une gêne par session à quelque chose de plus proche d’un point d’ancrage persistant, avec une fenêtre de détection mesurée en jours plutôt qu’en secondes.

Defenses

Aucun contrôle isolé n’élimine cette classe ; l’objectif est de briser la boucle écriture-puis-réutilisation et de traiter l’état persistant comme non fiable.

• Traitez la mémoire et les fichiers comme une entrée non fiable, pas comme un contexte faisant autorité. L’erreur de fond est que l’agent fait confiance à son propre état. Re-validez le contenu persistant à la lecture avec la même rigueur que le contenu externe frais, au lieu de supposer « c’est dans ma mémoire, donc c’est vrai ».
• Séparez le fiable du non fiable au niveau du stockage. Étiquetez ou cloisonnez l’état par provenance. Le contenu issu de sources non fiables doit être mis en quarantaine et jamais injecté directement dans les prompts d’orchestration ou de planification sans assainissement.
• Rendez les écritures dans l’état persistant explicites et auditables. Encadrez les écritures de mémoire par une politique : quoi écrire, par quelle tâche, depuis quelle source. Journalisez chaque écriture avec sa provenance afin qu’une investigation ultérieure puisse remonter un comportement jusqu’à la session qui l’a implanté.
• Limitez et expirez l’état de façon agressive. Préférez l’isolation par utilisateur et par tâche à une mémoire mutable partagée. Appliquez des TTL et un oubli afin qu’un contenu dormant ne puisse pas attendre indéfiniment une reprise. Évitez les conceptions en ajout seul pour tout ce qui réalimente les prompts.
• Surveillez les effets différés et inter-sessions, pas seulement immédiats. Une détection qui ne vérifie que le tour d’arrivée d’une entrée manquera le checkpoint-puis-reprise. Guettez les lectures anormales de mémoire, les exfiltrations inattendues et les comportements qui divergent de la demande de l’utilisateur courant.
• Contraignez les chemins d’exfiltration depuis le contexte de l’agent. La plupart des charges d’injection stockée finissent par une action sortante — un message, un appel d’outil, une requête. Des outils à moindre privilège et une surveillance de la sortie réduisent ce qu’une instruction réactivée peut accomplir.

Status

Aspect	Injection réfléchie (classique)	Injection stockée inter-sessions
Durée de vie	Une fenêtre de contexte	Persiste en mémoire / fichiers / checkpoints
Déclencheur	Le tour qui la délivre	Une exécution ultérieure qui relit l’état
Victime	La session courante	Sessions futures, voire autres utilisateurs
Fenêtre de détection	Immédiate	Différée (jours), survit aux réinitialisations
Contrôle principal	Garde-fous entrée/sortie	État typé par provenance, écritures encadrées, isolation

L’enseignement du papier de juin 2026 n’est pas un nouvel exploit mais un déplacement du modèle de menace : dans un agent à état, l’artefact durable est la vulnérabilité. Une seule injection qui atteint l’état persistant offre à un attaquant un temps et une portée qu’une injection mono-tour ne permet jamais, et les défenses pensées uniquement pour la fenêtre de contexte courante continueront de la manquer.