Injection indépendante de la requête : détourner un agent de code quoi qu'on lui demande

De quoi s’agit-il ?

La plupart des travaux sur l’injection de prompt indirecte insèrent une instruction malveillante puis espèrent que la tâche de l’utilisateur en soit assez proche pour la déclencher. QueryIPI, décrit dans un article publié sur arXiv le 27 octobre 2025 (2510.23675), renverse cette hypothèse. La charge est construite pour se déclencher quelle que soit la demande adressée à l’agent de code. Les auteurs parlent d’injection indirecte indépendante de la requête (query-agnostic) et la présentent comme la première méthode de ce type visant des agents de code réalistes.

L’astuce consiste à cesser de viser la partie variable du prompt — la requête de l’utilisateur — pour cibler la partie qui ne change jamais : le prompt système et les descriptions d’outils. Ces éléments sont chargés à chaque tour ; une charge ancrée là est donc présente pour chaque tâche, pas seulement celle que l’attaquant a devinée.

Comment ça marche

Un agent de code assemble son contexte à partir de trois couches : un prompt système fixe, un ensemble de descriptions d’outils (de plus en plus fournies via MCP) et la requête variable de l’utilisateur. QueryIPI utilise une description d’outil comme canal d’injection. Comme cette description est lue dans le contexte du modèle à chaque appel, une instruction qui y est dissimulée côtoie en permanence les ordres légitimes de l’agent.

La difficulté est de faire qu’une seule description prenne le pas de manière fiable sur une intention utilisateur arbitraire. QueryIPI y parvient par une recherche itérative fondée sur le prompt : il affine à répétition la description malveillante, mesure si l’agent la suit sur un éventail de tâches sans rapport, et conserve les variantes qui généralisent. L’article note que cette recherche devient traitable grâce à une faiblesse fréquente — les agents de code tendent à divulguer leur propre prompt interne, ce qui transforme une recherche à l’aveugle en une optimisation contrainte, quasi en boîte blanche. Les chaînes concrètes ne sont pas reproduites ici : c’est le mécanisme qui compte, pas un payload prêt à coller.

Résultat : un outil empoisonné qui paraît normal à l’inspection mais oriente l’agent vers l’action de l’attaquant — par exemple l’exécution d’une commande shell — que l’utilisateur ait demandé de refactoriser une fonction, d’écrire un test ou d’expliquer un fichier.

Pourquoi c’est important

Les agents de code correspondent presque parfaitement à la lethal trifecta de Simon Willison : ils ont accès à du code source et à des secrets privés, ils ingèrent du contenu non fiable (dépendances, sorties d’outils, fichiers récupérés) et ils peuvent agir via le shell et le système de fichiers. L’injection indépendante de la requête supprime la principale source d’incertitude de l’attaquant. Il n’a plus besoin que la victime formule sa demande d’une manière précise : toute interaction avec l’agent empoisonné devient une opportunité.

Elle déplace aussi le risque vers la chaîne d’approvisionnement des descriptions d’outils. Un seul serveur MCP malveillant ou compromis, un outil retourné (rug pull) ou une entrée de marketplace empoisonnée peut porter une charge qui fonctionne contre tous les utilisateurs en aval et toutes les tâches. C’est un modèle de menace très différent d’un document unique qui doit coïncider avec une requête précise.

Défenses

Le réflexe — filtrer le message de l’utilisateur — passe complètement à côté, puisque la charge vit dans la couche des outils, pas dans la requête. Les défenseurs devraient plutôt :

• Traiter les descriptions d’outils comme des entrées non fiables. Figer et relire les descriptions, les comparer (diff) à chaque mise à jour pour détecter les rug pulls, et préférer des serveurs d’outils signés ou attestés aux points de terminaison MCP anonymes.
• Appliquer une séparation architecturale. La capacité shell et système de fichiers ne devrait s’activer qu’en réponse à des instructions d’un propriétaire vérifié, via un canal de confiance — jamais à partir de contenu ou de descriptions récupérés de sources externes. C’est l’Agents Rule of Two appliquée concrètement : ne jamais laisser une entrée non fiable et une capacité sensible partager un contexte sans validation humaine.
• Réduire la fuite de prompt. Puisque la recherche de l’attaque s’amorce sur l’exposition par l’agent de son prompt système et de son schéma d’outils, minimiser cette fuite augmente le coût de l’attaque.
• Ajouter une détection en contexte de code. Une défense de juin 2026, CodeSentinel (2606.19235, publiée en juin 2026), vise exactement cette surface. Elle traite l’injection dans le code comme un problème de neutralisation au niveau de chaque nœud de l’arbre syntaxique concret (CST), combinant structure statique, anomalies de vraisemblance par nœud et influence comportementale au niveau des logits. Les auteurs la disent supérieure aux défenses antérieures (CodeGarrison, DePA, KillBadCode) sur six familles d’attaques récentes.

Aucune couche ne suffit à elle seule ; la réponse durable consiste à tenir le contenu non fiable des descriptions à l’écart de l’action privilégiée.

Statut

Élément	Détail
Attaque (QueryIPI)	arXiv 2510.23675, première mise en ligne le 27 oct. 2025
Canal d’injection	Descriptions d’outils (contexte invariant)
Facteur clé	Fuite du prompt système / schéma d’outils des agents de code
Défense (CodeSentinel)	arXiv 2606.19235, publiée en juin 2026 ; neutralisation par nœud CST
Classe affectée	Agents de code LLM avec accès outils/MCP et capacité shell