Tool poisoning : définition, risques MCP et parades

Comment fonctionne le tool poisoning ?

Le tool poisoning détourne un agent par le texte qui décrit un outil. Un serveur MCP présente chaque outil par un nom, une description et des paramètres. L’agent reçoit ces descriptions quand il découvre les outils du serveur ; le modèle les lit pour choisir quel outil appeler, et comment. L’utilisateur n’en voit souvent qu’un résumé.

Invariant Labs a décrit l’attaque le 1er avril 2025. Dans sa démonstration, un outil d’addition demandait au modèle de lire la clé SSH privée de l’utilisateur et de la glisser dans un paramètre. La fenêtre de confirmation de Cursor n’affichait pas ce paramètre en entier.

Le piège prend trois formes :

1. La description piégée : les instructions figurent dans la description dès l’installation.

2. Le rug pull : le serveur change la description après votre validation. Si ce changement ne déclenche aucune nouvelle validation, les nouvelles consignes s’appliquent sans revue (Microsoft, 30 juin 2026).

3. Le tool shadowing : un outil malveillant modifie l’usage d’un autre outil, digne de confiance. En avril 2025, Invariant Labs a ainsi fait fuiter, dans une démonstration, un historique de messages par le serveur WhatsApp légitime.

Dans les études MCPTox et MCP-ITP, l’attaque ne passe pas par l’outil piégé : sa description pousse l’agent vers un outil légitime, avec vos droits.

Tool poisoning ou injection de prompt indirecte : quelle différence ?

Dans le tool poisoning, le piège se trouve dans l’outil ; dans l’injection de prompt indirecte, il arrive avec un contenu que l’agent lit. Les deux exploitent la même faiblesse : le modèle ne sépare pas de façon sûre consignes et données. Un courriel piégé agit sur la tâche qui le lit. Une description piégée accompagne l’agent dans chaque tâche, tant que le serveur reste branché.

Le cas GitHub qu’Invariant Labs a décrit le 26 mai 2025 relève de l’injection indirecte. Un ticket piégé, déposé dans un dépôt public, conduit un agent à publier des données de dépôts privés dans une pull request de ce dépôt. L’attaque n’exige aucun outil MCP piégé, précise Invariant Labs.

Que mesurent les études sur le tool poisoning ?

Les études mesurent des taux de réussite élevés, en laboratoire, sur des modèles sortis en 2025 ou avant.

• MCPTox (Wang et al., conférence AAAI 2026) bâtit 1 348 cas d’attaque sur 353 outils de 45 serveurs MCP réels. Sur 20 configurations de modèles, l’attaque réussit en moyenne dans 36,5 % des cas, et jusqu’à 72,8 % avec o1-mini. Le modèle le plus prudent, Claude 3.7 Sonnet, refuse moins de 3 % des attaques. Selon les auteurs, les modèles plus capables sont souvent plus vulnérables : l’attaque exploite leur meilleure capacité à suivre les instructions.

• MCP-ITP (Li et al., prépublication du 12 janvier 2026) génère automatiquement des descriptions piégées. Dans cette prépublication, sur le jeu MCPTox et 12 agents, l’attaque réussit au mieux dans 84,2 % des cas, avec GPT-3.5-turbo. Face aux deux détecteurs testés, elle échappe plus souvent à la détection que les attaques de MCPTox.

Hors laboratoire, Microsoft, qui vend des outils de sécurité, signale ces techniques en 2026 contre des agents d’entreprise de plus en plus variés. Il ne nomme aucune victime. En août 2026, l’éditeur de sécurité Pillar Security a décrit la campagne Deadbugz. En 74 minutes, 23 pull requests proposaient à des projets GitHub un serveur MCP qui change ses descriptions après trois appels. Aucune n’était fusionnée lors de son analyse. Le projet OWASP MCP Top 10, encore en bêta, range le tool poisoning parmi ses dix risques, sous le code MCP03:2025.

Que change le tool poisoning pour votre décision ?

• Un serveur MCP tiers est une dépendance logicielle, description comprise. Microsoft recommande de traiter ses descriptions comme des consignes système et de relire leurs mises à jour sur les agents critiques. Invariant Labs conseille de figer la version de chaque serveur et de ses outils.

• Tenez un inventaire et une liste blanche. Microsoft recommande une liste des éditeurs et des serveurs MCP approuvés, et un propriétaire désigné pour chaque serveur tiers avant la production. Une skill d’agent se charge elle aussi par sa description : soumettez-la à la même revue.

• Limitez ce que l’agent peut atteindre. Microsoft conseille de n’activer que les outils utiles à l’agent, pas tous ceux d’un serveur. Des droits limités à chaque tâche bornent les dégâts d’une description piégée. Évitez qu’un même agent lise vos données sensibles et charge un outil tiers capable de les envoyer au-dehors.

• Faites valider les actions à risque, paramètres en entier. La spécification MCP recommande d’afficher les paramètres d’un appel avant son envoi, contre les fuites de données. Une validation qui masque un paramètre ne protège rien : réglez votre human in the loop en conséquence.

• Ne confiez pas la défense au modèle. Un modèle plus capable ne résiste pas forcément mieux. Placez les contrôles hors du modèle, dans les guardrails de l’agent, et testez vos propres agents.

Exemple illustratif

Ce cas est fictif. Une ETI relie son agent comptable à un serveur MCP tiers de conversion de devises. Trois mois plus tard, une mise à jour de description demande à l’agent de joindre à chaque appel la liste des factures impayées. La DSI a figé la version : la mise à jour attend une revue, qui la rejette.