TRUSTDESC : dériver les descriptions d'outils depuis le code pour désamorcer le tool poisoning

De quoi s’agit-il ?

Un outil qu’un LLM peut appeler comporte deux parties : le code exécutable qui réalise le travail, et une description en langage naturel qui indique au modèle ce que fait l’outil et quand l’utiliser. Le modèle ne voit jamais le code — seulement la description, chargée dans son contexte. Cette description constitue donc une frontière de confiance, et c’est celle que presque personne ne vérifie.

Les attaques par empoisonnement d’outil (tool poisoning attacks, TPA) exploitent précisément cette faille. La classe a été révélée publiquement par Invariant Labs en avril 2025 pour le Model Context Protocol, et étudiée depuis au niveau du descripteur (par ex. arXiv 2512.06556, décembre 2025). TRUSTDESC: Preventing Tool Poisoning in LLM Applications via Trusted Description Generation (Ye, Zhang, Jia et Hu, The Pennsylvania State University ; arXiv 2604.07536, avril 2026) propose une défense qui supprime l’écart au lieu de le surveiller : générer la description à partir de l’implémentation, pour que le texte lu par le LLM soit fidèle au code qui s’exécutera réellement.

Comment ça marche

Le papier distingue deux types de TPA.

Les TPA explicites insèrent des instructions malveillantes directement dans la description d’un outil — par exemple, un texte caché demandant au modèle de lire un fichier de configuration et d’en transmettre le contenu à un autre outil. Elles paraissent anormales et constituent la cible de la plupart des défenses anti-prompt-injection existantes.

Les TPA implicites ne portent aucune instruction. L’attaquant rédige une description d’apparence anodine mais exagérée — en glissant des mots comme « meilleur », « le plus efficace », « à toujours privilégier » — afin de biaiser l’étape de sélection d’outil du modèle vers un outil contrôlé par l’attaquant. Il n’y a rien qu’un détecteur d’instructions puisse signaler, et pourtant le modèle est orienté. Comme l’écrivent les auteurs, déterminer si une description est honnête revient à vérifier qu’elle correspond à l’implémentation — difficile même pour un humain sans lire le code.

Le postulat de TRUSTDESC est que le code source constitue une vérité de référence digne de confiance (les attaquants livrent rarement du code malveillant, car la détection de malwares fonctionne ; ils attaquent la couche descriptive, peu coûteuse et non vérifiée). Il reconstruit chaque description en trois étapes :

base de code
   │
   ▼
[ SliceMin ]   une analyse statique sensible à l'atteignabilité construit
   │           un graphe d'appels par outil ; un LLM élague la logique
   │           inatteignable/non pertinente jusqu'à une tranche de code
   │           minimale et propre à l'outil
   ▼
[ DescGen ]    synthétise une description à partir de la tranche ; retire
   │           commentaires et docstrings, tronque les identifiants
   │           trompeurs, atténue les artefacts de code adverses
   ▼
[ DynVer ]     décompose le brouillon en affirmations vérifiables, les
   │           exécute, et utilise un LLM juge sur les logs pour écarter
   │           toute affirmation que l'exécution ne confirme pas
   ▼
description de confiance

Retirer commentaires, docstrings et noms d’identifiants longs dans DescGen tient au fait que ce sont eux-mêmes des canaux contrôlables par l’attaquant ; DynVer ne conserve ensuite que le comportement réellement démontré par le code, ce qui désamorce les affirmations hallucinées ou exagérées.

Pourquoi c’est important

Les descriptions d’outils sont le tissu conjonctif des écosystèmes d’agents, et MCP en a fait une chaîne d’approvisionnement partagée et tierce : vous installez un serveur, et ses descriptions auto-rédigées entrent dans le contexte de votre modèle avec une confiance totale. Les TPA implicites sont la moitié inquiétante car la première ligne de défense de toute l’industrie — chercher des instructions à l’allure malveillante — ne les voit pas. Une description grammaticale, flatteuse et sans impératifs passe sans encombre.

Re-dériver les descriptions depuis le code a un second effet, mesuré dans le papier : cela améliore l’usage honnête des outils. Sur 208 tâches couvrant 52 outils issus de 12 serveurs MCP, les descriptions générées par TRUSTDESC ont relevé le taux de réussite des tâches de 4,3 % en moyenne par rapport aux descriptions d’origine, et lorsque des variantes d’outils de faible qualité (avec contrôles de sécurité ou fonctionnalités retirés) entraient en concurrence pour la sélection, les descriptions de confiance réduisaient la fréquence à laquelle le modèle choisissait l’outil le plus faible. Une description fidèle est à la fois un contrôle de sécurité et un contrôle de qualité.

Les limites, en toute honnêteté : face à des attaques adaptatives qui plantent des identifiants trompeurs pour biaiser la génération, le taux de réussite de l’attaque oscillait entre 44,7 % et 67,4 % sur 15 itérations — sans tendance ascendante stable, mais loin de zéro. Il s’agit d’une atténuation, pas d’une élimination, et elle dépend de l’accès à un code source lisible (le prototype couvre les serveurs MCP en Python et TypeScript).

Défenses

Enseignements concrets, que vous adoptiez ou non ce framework précis :

1. Traitez les descriptions d’outils fournies par l’auteur comme une entrée non fiable. Elles sont chargées dans le contexte du modèle avec la même autorité que les instructions système, mais sans aucune relecture. Épinglez et relisez le texte exact des descriptions comme vous épingleriez la version d’une dépendance.

2. Défendez la sélection d’outil, pas seulement l’exécution. Les TPA implicites ne déclenchent jamais directement une action dangereuse ; elles biaisent l’outil que le planificateur choisit. Journaliser et contraindre la sélection — listes d’autorisation, routage déterministe pour les capacités sensibles — ferme une porte que les filtres d’instructions laissent ouverte.

3. Comparez la description à l’implémentation. La cause racine est l’écart entre l’affirmation et le comportement. Générer ou valider les descriptions à partir du code (l’approche de TRUSTDESC) attrape l’exagération qu’aucun scanner de mots-clés ne verra. À défaut de code source, la vérification dynamique des affirmations comportementales est le repli.

4. Prévoyez un budget pour les adversaires adaptatifs. Un taux de réussite résiduel de ~45–67 % sous attaque adaptative signifie que la fidélité des descriptions n’est qu’une couche. Conservez en dessous un cadrage des outils au moindre privilège, une validation humaine pour les appels à fort impact, et des contrôles d’exfiltration.

Statut

Élément	Référence	Date	Notes
Framework TRUSTDESC	arXiv:2604.07536	2026-04	SliceMin / DescGen / DynVer ; 52 outils, 12 serveurs MCP
Attaques sémantiques au niveau du descripteur	arXiv:2512.06556	2025-12	Étude antérieure de la manipulation de descripteurs MCP
Tool Poisoning Attacks (origine)	Invariant Labs	2025-04	Première divulgation publique de la classe TPA pour MCP

Le cadrage à retenir est le plus simple : dans un agent outillé, la description est la lettre de motivation du code, et n’importe qui peut aujourd’hui la falsifier. Réduire l’écart entre ce qu’un outil dit faire et ce qu’il fait transforme la description, de maillon le plus faible, en maillon vérifiable.