DualView : combler la faille d'injection « stockée » des agents IA personnels

De quoi s’agit-il ?

Les agents IA personnels — ceux qui tournent sur votre propre machine et automatisent la recherche web, la messagerie et la gestion de fichiers — se placent devant une surface vaste et sensible : le réseau, le système de fichiers et le shell. C’est précisément cet accès qui rend l’injection de prompt indirecte (IPI) dangereuse : toute page web, tout e-mail ou tout document que l’agent lit peut transporter des instructions que l’agent exécute ensuite. Un papier arXiv de juillet 2026, DualView: Preventing Indirect Prompt Injection in Personal AI Agents (2607.03821), de Juhee Kim, Woohyuk Choi, Taehyun Kang, Youngmin Kim et Byoungyoung Lee, identifie un angle mort dans l’un des principaux motifs défensifs et propose un correctif.

Le motif en question est le design Dual LLM, décrit par Simon Willison en avril 2023 puis formalisé par des systèmes comme CaMeL (Defeating Prompt Injections by Design, arXiv 2503.18813). L’idée est de tenir le contenu non fiable éloigné du modèle qui détient les outils : un composant privilégié planifie et agit, tandis que les données non fiables sont remplacées par des symboles opaques que l’agent peut manipuler mais jamais réellement lire. L’apport de DualView est de montrer que cette comptabilité s’arrête au bord du contexte de l’agent — et que les attaquants peuvent contourner ce bord.

Comment ça marche

La faille que le papier nomme est l’IPI stockée (stored IPI). Les défenses Dual LLM ne suivent le caractère non fiable d’une donnée que tant qu’elle réside dans le contexte de travail de l’agent. Dès que l’agent écrit quelque chose à l’extérieur — enregistre un extrait web dans un fichier, ajoute une note, place une valeur dans une variable de shell — cette étiquette de provenance est perdue. Lorsque l’agent relit ensuite le même contenu, il revient comme une donnée neuve, considérée comme fiable plutôt que comme un symbole protégé. Si l’instruction d’un attaquant s’y cachait, elle vient de se « blanchir » : passée de « non fiable » à « fiable » par un simple aller-retour via le système de fichiers.

La séquence, à un niveau conceptuel :

[ page web / e-mail portant une chaîne en forme d'instruction ]
        │  lecture dans le contexte  →  étiquetée NON FIABLE (affichée comme symbole)
        ▼
[ l'agent écrit la valeur dans un fichier / une note / une variable de shell ]
        │  l'étiquette de provenance NE suit PAS la donnée hors du contexte
        ▼
[ plus tard, l'agent relit le fichier ]
        │  la donnée revient sans étiquette  →  traitée comme FIABLE
        ▼
[ l'agent « voit » désormais l'instruction plantée et peut y obéir ]

La réponse de DualView est d’étendre le suivi des données non fiables au-delà de la fenêtre de contexte, jusque dans l’environnement lui-même — système de fichiers, shell, réseau et autres agents. Chaque canal reçoit deux vues de la même donnée. Dans l’AgentView, l’agent continue de voir le contenu non fiable comme des symboles même après l’avoir écrit puis relu, ce qui ferme la voie de l’IPI stockée. Dans l’HumanView, la donnée d’origine est préservée pour que les utilisateurs humains et les outils ordinaires continuent de voir les vraies valeurs et de fonctionner normalement. Autrement dit, l’étiquette est rendue persistante partout où la donnée circule, au lieu de s’évaporer à la frontière du contexte du modèle.

Pourquoi c’est important

L’IPI stockée compte parce qu’elle met en échec une défense que beaucoup d’équipes considèrent désormais comme une base solide. Les approches Dual LLM et à base de capacités séduisent justement parce qu’elles promettent une protection structurelle plutôt qu’un filtrage au mieux — CaMeL, par exemple, rapporte résoudre 77 % des tâches d’AgentDojo avec une sécurité prouvée contre l’injection, contre 84 % pour un agent non défendu. Mais une défense qui suppose que les données non fiables peuvent être confinées dans le contexte comporte une frontière implicite, et un agent personnel qui lit et écrit des fichiers toute la journée franchit cette frontière en permanence. L’attaquant n’a pas besoin d’un exploit inédit ; il lui suffit de placer son texte dans quelque chose que l’agent enregistrera puis rouvrira, ce qui, pour un assistant de gestion de fichiers, relève de son fonctionnement normal. Le risque résiduel est la persistance : une injection qui survit sur disque peut se réarmer chaque fois que l’agent revisite le fichier.

Défenses

La leçon du papier est éminemment pratique : traitez la provenance comme une propriété de la donnée, non d’un moment de la conversation. Si vous vous appuyez sur un schéma Dual LLM ou de substitution symbolique, vérifiez si son suivi des données non fiables accompagne le contenu à travers les écritures et les lectures vers le système de fichiers, le shell et le réseau — et supposez que, si ce n’est pas le cas, l’IPI stockée fait partie de votre surface d’exposition. Une approche à double vue qui maintient l’étiquette « non fiable » attachée partout où la valeur voyage est un moyen de combler cette faille ; le principe général s’applique quelle que soit l’implémentation.

Au-delà de ce correctif précis, la littérature environnante sur les motifs de conception reste valable. Gardez le composant qui peut agir séparé du contenu non fiable, comme dans le catalogue de motifs de Willison et de ses collaborateurs et son papier associé (arXiv 2506.08837). Appliquez le moindre privilège à la portée fichier, shell et réseau de l’agent, afin qu’une instruction blanchie ait moins de leviers. Et lorsque vous évaluez une défense contre l’injection, testez-la avec des charges écrites sur disque puis relues — pas seulement des injections en contexte sur un seul tour — pour que l’IPI stockée fasse partie du modèle de menace avant le déploiement, et non après.

Statut

Élément	Référence	Date	Notes
Papier de recherche	DualView: Preventing Indirect Prompt Injection in Personal AI Agents, arXiv 2607.03821	Juillet 2026	Définit l’« IPI stockée » ; suivi à double vue AgentView/HumanView
Défense antérieure	Defeating Prompt Injections by Design (CaMeL), arXiv 2503.18813	Mars 2025	Dual-LLM à capacités ; 77 % des tâches AgentDojo avec sécurité prouvée
Filiation de conception	Motif Dual LLM (Simon Willison)	Avril 2023	Acteur privilégié + lecteur en quarantaine ; réponses symboliques
Catalogue de motifs	Design Patterns for Securing LLM Agents against Prompt Injections, arXiv 2506.08837	Juin 2025	Ensemble élargi de motifs défensifs pour agents