ClawTrojan : l'injection stockée devient une porte dérobée persistante d'agent
Un paper arXiv du 29 mai 2026 montre qu'une injection cachée dans un fichier peut être stockée par un agent local puis exécutée plus tard — 95,5 % de réussite là où l'injection mono-tour frôle zéro.
De quoi s’agit-il ?
Le 29 mai 2026, Jiejun Tan, Zhicheng Dou, Xinyu Yang, Yuyang Hu, Yiruo Cheng, Xiaoxi Li et Ji-Rong Wen ont publié From Prompt Injection to Persistent Control: Defending Agentic Harness Against Trojan Backdoors (arXiv:2605.31042, cs.CR/cs.AI/cs.CL). Le code et le benchmark sont diffusés sous l’organisation GitHub RUC-NLPIR.
La contribution n’est pas un nouveau payload. C’est la mesure d’un angle mort : dans un harness agentique local — où un LLM lit et écrit des fichiers, appelle des outils et réutilise l’état du workspace d’une session à l’autre — une instruction injectée n’a pas besoin d’agir immédiatement. Elle peut être stockée et exécutée bien plus tard. Les auteurs construisent un benchmark, ClawTrojan, pour révéler ces chevaux de Troie multi-étapes, et une défense, DASGuard, qui retrace l’origine réelle du texte « de contrôle » présent dans un workspace. Sur un workspace simulé de type OpenClaw exécutant GPT-5.4, ClawTrojan atteint un taux de réussite d’attaque (ASR) de 95,5 %, tandis que les injections classiques mono-tour frôlent zéro sur le même modèle.
Comment ça marche
L’attaque répartit un objectif malveillant unique sur plusieurs étapes d’apparence anodine. L’attaquant place une injection dans un contenu que l’agent va rencontrer — un fichier, une sortie d’outil, un fragment de contexte récupéré. L’agent lit cette instruction cachée et, point décisif, l’écrit dans le workspace : un fichier de configuration, un fichier de notes, un état persisté. Plus tard — éventuellement dans une autre session — l’agent relit son propre workspace, traite le texte planté comme un contenu de contrôle légitime, et l’exécute.
Étape 1 L'agent lit un fichier/une sortie d'outil non fiable contenant du texte caché
Étape 2 L'agent écrit ce texte dans un fichier local sensible [porte dérobée plantée]
... (ressemble à de la maintenance ordinaire du workspace)
Étape N L'agent relit le fichier et exécute l'instruction plantée
L’intuition clé est structurelle : aucune étape, prise isolément, ne paraît malveillante. Écrire dans un fichier de config est routinier. Relire l’état du workspace est routinier. Le danger n’existe que dans la séquence. Le paper note que les défenses existantes inspectent chaque étape isolément : elles peuvent bloquer une action finale clairement nuisible, mais manquent totalement l’écriture antérieure qui a planté la porte dérobée. C’est pourquoi l’injection mono-tour frôle zéro sur GPT-5.4 alors que la variante multi-étapes réussit 95,5 % du temps — le refus par étape du modèle reste intact ; c’est le workflow qui est exploité.
C’est la leçon de la contamination temporelle de la mémoire et de l’exfiltration par mémoire dormante, appliquée désormais à l’état sur fichier d’un harness de code local plutôt qu’à une mémoire vectorielle.
Pourquoi c’est important
Les harnesses agentiques locaux sont précisément les environnements les plus concernés. Ils conservent un état persistant par conception — c’est ce qui les rend utiles d’une session à l’autre — et ils accordent à l’agent l’écriture de fichiers et l’exécution d’outils. Cette combinaison transforme une chaîne stockée en contrôle latent. C’est la triade létale (contenu non fiable, capacité sensible, persistance) exprimée à travers le système de fichiers.
Deux conséquences. D’abord, les garde-fous par action créent un faux sentiment de sécurité : un harness peut refuser chaque requête individuellement dangereuse et rester totalement compromis, car l’instruction dangereuse a été blanchie via une écriture anodine plus tôt dans son historique. Ensuite, le rayon d’impact est durable. Une porte dérobée écrite dans l’état du workspace survit aux frontières de session : une seule exposition à un fichier empoisonné peut donner le contrôle d’exécutions futures que l’opérateur ne relie jamais à l’injection initiale.
Ce sont des résultats simulés sur un benchmark, non une campagne observée en conditions réelles, et le harness est de type OpenClaw plutôt qu’un produit commercial précis. La bonne lecture est une borne inférieure sur une classe de faiblesse, pas un bug propre à un éditeur.
Défenses
La défense proposée, DASGuard, repose sur le traçage de provenance, et sa conception se généralise en consignes concrètes.
-
Tracer la provenance du texte « de contrôle ». DASGuard analyse les fichiers locaux sensibles à la recherche de contenu ressemblant à des instructions ou à du flux de contrôle, en retrace l’origine, et supprime le contenu de contrôle ne provenant pas d’une source fiable. Le principe : l’autorité d’une chaîne doit dépendre de son origine, pas de l’endroit où elle se trouve maintenant. Cela rejoint les travaux data-flow-is-not-authority et graphe de provenance.
-
Défendre la séquence, pas l’étape. Comme aucune action seule n’est malveillante, le filtrage par action est insuffisant. Corrélez les opérations d’écriture avec les lectures ultérieures du même artefact, et faites de « l’agent écrit du texte en forme d’instruction dans son propre état, puis agit dessus plus tard » une cible de détection à part entière.
-
Combiner blocage à l’exécution et commits assainis. DASGuard associe le blocage de l’attaque à l’exécution à des commits assainis vers le workspace : il ne se contente pas d’arrêter l’action en direct, il nettoie la porte dérobée plantée dans l’état persisté pour qu’elle ne se déclenche pas plus tard. Traitez l’état du workspace comme non fiable jusqu’à validation, en écriture comme en lecture.
-
Contraindre le harness. Accès aux fichiers au moindre privilège, séparation de l’état modifiable par l’agent et de la configuration lisible par l’agent, et contrôle de l’egress bornent ce qu’une instruction plantée peut accomplir, quel que soit son mode de blanchiment. C’est la posture architecturale de la règle de deux des agents.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| Paper publié | arXiv:2605.31042 [cs.CR] | 2026-05-29 | « From Prompt Injection to Persistent Control: Defending Agentic Harness Against Trojan Backdoors » |
| Benchmark | ClawTrojan | — | Détection des trojans multi-étapes dans les harnesses agentiques locaux |
| Défense | DASGuard | — | Scan de provenance du texte de contrôle + commits assainis |
| Évaluation | Workspace type OpenClaw, GPT-5.4 | — | 95,5 % d’ASR multi-étapes vs. quasi-nul en mono-tour |
| Code & données | github.com/RUC-NLPIR/ClawTrojan | — | Publiés avec le paper |
| Statut d’exploitation | Rien d’observé en conditions réelles | — | Benchmark simulé ; aucun payload sur système vivant publié |
L’enseignement n’est pas « les agents sont vulnérables à l’injection » — c’est connu. C’est que la persistance transforme une instruction refusée en instruction stockée, et que la défense doit lire l’historique du workspace de l’agent, pas seulement sa prochaine action.