Tool poisoning MCP : tester les descriptions piégées

Qu’est-ce que le tool poisoning MCP ?

C’est une injection de prompt indirecte placée dans les métadonnées d’un outil. Invariant Labs a décrit l’attaque le 1er avril 2025 : une description d’outil contient des instructions « invisibles pour l’utilisateur mais visibles pour le modèle », et le modèle agit en conséquence.

Le mécanisme tient à la façon dont MCP fonctionne. Le client demande la liste des outils (tools/list) et transmet au modèle le nom, la description et le schéma de chaque outil. Le modèle traite ce texte comme du contexte fiable, alors qu’il vient d’un serveur tiers. Notre page sécurité MCP détaille cette surface d’attaque ; la logique est la même que pour l’injection de prompt classique, sauf que le canal est la définition de l’outil et non le contenu d’un document.

Dans l’expérience décrite par Invariant, un serveur proposait un outil add d’apparence anodine. Sa description demandait au modèle de lire ~/.cursor/mcp.json et les clés SSH, puis de les passer en paramètre à l’outil. Le client testé était Cursor, et la fenêtre de confirmation n’affichait qu’une version simplifiée de l’appel, sans les arguments complets.

Qu’est-ce qu’un « rug pull » de serveur MCP ?

Un rug pull est un changement de comportement après l’approbation. Invariant le décrit ainsi : un serveur malveillant modifie la description d’un outil une fois que le client l’a validé, et l’utilisateur qui lui faisait confiance est attaqué plus tard. L’analogie retenue est celle des mises à jour malveillantes sur les registres de paquets.

Invariant a publié le 7 avril 2025 une variante contre whatsapp-mcp : un serveur affiche d’abord un outil inoffensif (un « fait du jour »), l’utilisateur l’approuve, puis au lancement suivant la description devient piégée et demande d’envoyer des messages WhatsApp à un numéro contrôlé par l’attaquant, avec les conversations de l’utilisateur dans le corps du message. Le serveur malveillant n’a même pas besoin d’être appelé : c’est la description qui pilote l’agent.

Le cas postmark-mcp montre le même schéma côté chaîne d’approvisionnement. D’après BleepingComputer (25 septembre 2025), ce paquet npm non officiel était propre jusqu’à la version 1.0.15 ; la version 1.0.16 a ajouté une ligne qui mettait l’éditeur en copie cachée de chaque e-mail envoyé, pour environ 1 500 téléchargements. Ce n’est pas une description piégée, mais c’est bien un serveur qui change après qu’on lui a fait confiance.

Que dit la spécification MCP sur ce risque ?

Elle demande de ne pas faire confiance aveuglément aux serveurs. La spécification (version du 18 juin 2025) indique que les clients doivent considérer les annotations d’outils comme non fiables, sauf si elles viennent d’un serveur de confiance, et qu’il devrait toujours y avoir un humain capable de refuser un appel.

Elle recommande aussi aux clients d’afficher les entrées d’un outil à l’utilisateur avant l’appel, pour éviter une exfiltration accidentelle ou malveillante, et de journaliser les usages. Côté serveur, elle liste la validation des entrées, le contrôle d’accès et la limitation de débit. Le serveur peut enfin signaler un changement de liste d’outils avec la notification notifications/tools/list_changed : traitez ce signal comme un événement de sécurité à journaliser et à contrôler.

Comment tester le tool poisoning et le rug pull ?

Testez quatre choses : ce que voit l’utilisateur, ce que suit le modèle, ce qui change dans le temps, et ce qui sort. Tous les essais se font sur un serveur de test que vous contrôlez et sur un environnement de développement ou de recette, jamais sur des données réelles.

1. Inventaire. Listez les serveurs MCP branchés à l’agent, leur version, leur origine (éditeur, dépôt, paquet) et les outils exposés. Un serveur dont personne ne connaît l’origine est déjà un résultat.
2. Empreinte. Calculez un hash du nom, de la description et du schéma de chaque outil, et conservez-le. Invariant recommande d’épingler les versions et de vérifier les descriptions par hash avant usage.
3. Comparaison dans le temps. Relancez tools/list à chaque session et après chaque list_changed. Toute différence de description doit bloquer l’outil jusqu’à revue humaine.
4. Test d’affichage. Sur un serveur de test, mettez dans une description un marqueur inoffensif très long, dont une partie est masquée (retours à la ligne, texte en fin de champ). Vérifiez ce que le client montre : description complète, tronquée, ou seulement le nom.
5. Test d’obéissance. Dans la description d’un outil de test, demandez au modèle d’ajouter un jeton canari à un paramètre. Si le canari arrive au serveur, le modèle suit les descriptions sans contrôle.
6. Test de shadowing. Déployez deux serveurs de test : l’un légitime avec un outil d’envoi, l’autre dont la description tente de rediriger les destinataires. Comparez le destinataire demandé par l’utilisateur et celui qui part réellement.
7. Test de rug pull. Faites changer la description du serveur de test entre deux sessions. L’agent a-t-il redemandé une approbation ? Un journal garde-t-il la trace du changement ?
8. Test des paramètres. Vérifiez si la fenêtre de confirmation montre les arguments complets. Dans l’exemple d’Invariant, c’est précisément ce qui manquait.

Notre méthode décrit comment nous cadrons ces essais ; rien n’est conservé sans l’accord du client.

Quelles défenses mettre en place ?

Épinglez, affichez, cloisonnez, filtrez. Les recommandations d’Invariant se recoupent avec la spécification :

• Épingler les versions de serveurs et les descriptions d’outils, avec vérification par hash.
• Afficher la description complète et les arguments avant tout appel sensible, en distinguant le texte destiné à l’utilisateur de celui destiné au modèle.
• Cloisonner les serveurs entre eux : un serveur ne doit pas pouvoir influencer l’usage des outils d’un autre. Invariant parle de contrôles de flux de données entre serveurs.
• Limiter les droits de chaque outil : un outil d’addition n’a pas besoin d’accès au système de fichiers ni au réseau.
• Valider les sorties et les paramètres côté serveur, et garder un humain dans la boucle pour les actions irréversibles (voir notre article sur la validation humaine).
• Journaliser les listes d’outils vues, les changements et les appels.

Invariant insiste sur un point : protéger les descriptions ne suffit pas, il faut aussi contrôler les données qui entrent et sortent du modèle.

Quels référentiels citer dans un rapport ?

Le tool poisoning relève de LLM01 (injection de prompt) et LLM03 (chaîne d’approvisionnement) dans l’OWASP Top 10 for LLM Applications 2025, et de LLM06 (agentivité excessive) quand l’outil dispose de droits trop larges. Côté agents, l’OWASP Top 10 for Agentic Applications (publié le 9 décembre 2025) contient une entrée ASI04 sur la chaîne d’approvisionnement agentique et une entrée ASI02 sur l’usage détourné des outils.

Comment CleanIssue teste ce risque ?

Nous traitons le tool poisoning et le rug pull comme deux cas d’un même contrôle : la confiance accordée à ce qui décrit un outil. Dans le Red Team Agent Express, nous branchons un serveur MCP de test sur l’agent, sur votre environnement de développement ou de recette, et nous mesurons ce que le client affiche, ce que le modèle exécute et ce qui change entre deux sessions. Pour plusieurs agents et plusieurs serveurs, le périmètre se chiffre dans un Red Team sur mesure. Le livrable suit le format de l’exemple de rapport.

Un premier échange de 30 minutes, gratuit, permet de lister vos serveurs MCP et de décider si ce test a un sens pour vous.