Quand l'agent passe de la lecture à l'action : l'empoisonnement des descriptions d'outils MCP

De quoi s’agit-il ?

Le 30 juin 2026, Microsoft Incident Response a publié Securing AI agents: When AI tools move from reading to acting, troisième volet de sa série sur la sécurité des applications d’IA. Le propos relève d’un déplacement du modèle de menace plutôt que d’une faille isolée : à mesure que les agents d’entreprise passent du résumé de contenu à la prise d’action — envoyer un e-mail, mettre à jour des enregistrements, appeler des systèmes métier via le Model Context Protocol (MCP) —, l’impact de l’injection de prompt change de nature. Une entrée empoisonnée sur un simple résumeur biaise une sortie ; la même manipulation sur un agent qui agit déclenche une action.

Le mécanisme concret décrit par Microsoft est l’empoisonnement de description d’outil MCP, une technique signalée pour la première fois par Invariant Labs en avril 2025 et, selon Microsoft, de plus en plus observée contre des agents en production en 2026. Elle correspond à deux catégories de l’OWASP Top 10 for Agentic Applications publié en décembre 2025 : ASI02 (mésusage d’outils) et ASI04 (vulnérabilités de la chaîne d’approvisionnement agentique).

Comment ça marche

Un outil MCP est livré avec une description en langage naturel — la métadonnée que l’agent lit pour décider comment et quand l’appeler. Point crucial : MCP mêle cette métadonnée aux données dans la même fenêtre de contexte. La description se retrouve dans la mémoire de travail de l’agent, à côté de ses véritables instructions, et le modèle n’a aucun moyen fiable de distinguer une instruction légitime d’une instruction malveillante glissée par un mainteneur en amont.

L’exemple de Microsoft porte sur un flux financier. Une équipe construit un agent connecté à trois outils : une base fournisseurs approuvée, un connecteur de messagerie et un serveur tiers d’« enrichissement de factures » revu par un responsable métier mais jamais soumis à une revue de sécurité distincte. La chaîne se déroule alors en quatre étapes — aucun payload d’exploitation n’est reproduit ici :

1. Empoisonnement de la description. Le mainteneur du serveur d’enrichissement pousse une mise à jour. Le nom de l’outil et le résumé visible restent identiques, mais la description est réécrite en silence pour y glisser des instructions cachées — présentées comme une « exigence anti-fraude » — demandant à l’agent de collecter les factures impayées récentes et de les joindre à l’appel d’enrichissement.
2. Re-confiance silencieuse. MCP répercute dynamiquement les mises à jour de métadonnées. Là où un changement de description ne déclenche pas de ré-approbation, le texte empoisonné passe en production sans aucune revue.
3. Invocation. Un analyste pose une question de routine sur un fournisseur. L’agent, lisant la description empoisonnée, collecte des enregistrements sensibles au-delà du périmètre demandé et les transmet sous forme de paramètre d’apparence anodine.
4. Exfiltration. Le serveur renvoie une réponse « validée » plausible et journalise discrètement les données jointes vers un point de collecte contrôlé par l’attaquant. L’analyste voit une réponse propre ; dans les configurations par défaut, aucune alerte ne se déclenche.

Chaque étape prise isolément reste dans les paramètres normaux de l’agent. Le benchmark MCPTox — 45 serveurs MCP vivants et 353 outils authentiques — a mesuré des taux de réussite d’attaque supérieurs à 60 % sur de nombreux agents populaires, avec un pic autour de 72 %.

Pourquoi c’est important

Ce qui rend l’attaque efficace, c’est l’absence de faille dans un composant précis. L’outil était approuvé, la requête à la base a hérité des permissions de l’analyste, et l’appel sortant est parti vers un serveur mis en liste blanche lors de son ajout. La faiblesse réside dans la frontière de confiance entre les systèmes, pas à l’intérieur — d’où le silence des journaux par défaut et le contournement simultané d’un utilisateur, d’un prompt et d’un identifiant. Comme le rappelle Microsoft, IDC projette une croissance des agents d’entreprise actifs de 28,6 millions en 2025 vers plusieurs milliards d’ici 2030 ; chacun hérite de sa chaîne d’outils comme surface d’attaque.

Défenses

Les recommandations de Microsoft se résument à trois principes qui dépassent son seul écosystème :

Traiter chaque serveur MCP comme un maillon de la chaîne d’approvisionnement. Maintenir une liste blanche, au niveau du tenant, des éditeurs et serveurs approuvés ; désactiver l’accès « tout autoriser » ; n’activer que les outils dont l’agent a besoin ; exiger un propriétaire documenté pour tout serveur tiers avant sa mise en production.

Traiter les descriptions d’outils comme des prompts système. Puisque le modèle lit la métadonnée d’outil comme contexte de travail, la modifier équivaut à modifier les instructions de l’agent. Soumettre les mises à jour de description à la même revue qu’un changement de code ou de prompt système, et rechercher dans le texte tout impératif qui n’a rien à faire dans un champ de documentation.

Appliquer le moindre pouvoir d’agir, pas seulement le moindre privilège. Même un agent aux permissions minimales peut nuire s’il dispose de trop d’autonomie. Exiger une validation humaine pour les actions à fort impact (accès financier, partage externe, modification de comptes), donner à chaque agent une identité non humaine avec accès conditionnel, inspecter les paramètres d’appel d’outil avec des politiques de prévention des pertes de données, et établir une référence du comportement normal pour que tout nouveau point de sortie, paramètre élargi ou requête inhabituelle déclenche une alerte. Red-teamer l’agent contre des métadonnées empoisonnées avant le déploiement, pas après.

Statut

Élément	Référence	Notes
Guidance Microsoft IR	Microsoft Incident Response, 2026-06-30	Bascule « lecture → action » ; schéma d’attaque sur flux financier
Origine de la technique	Notification tool-poisoning d’Invariant Labs, 2025-04	Première divulgation publique de l’empoisonnement de description MCP
Cadre de référence	OWASP Top 10 for Agentic Applications, 2025-12	ASI02 mésusage d’outils, ASI04 chaîne d’approvisionnement agentique
Preuve empirique	Benchmark MCPTox	45 serveurs, 353 outils ; réussite > 60 %, pic ~72 %
Exploitation constatée	Selon Microsoft, observée en 2026	Aucune organisation victime précise divulguée

La leçon durable : c’est l’autonomie, et non la permission, qui transforme une instruction injectée en incident. L’injection de prompt dans le contexte d’un agent — y compris via les outils qu’il croit dignes de confiance — doit être présumée possible ; la défense consiste à restreindre ce qu’un agent détourné a le droit de faire ensuite.