L'outil que vous avez validé n'est pas celui qui tourne : le rug-pull des descriptions MCP

De quoi s’agit-il ?

Le 30 juin 2026, l’équipe Microsoft Incident Response et sa cellule de recherche Defender ont publié une analyse d’une faille de confiance qui apparaît dès qu’un agent IA peut agir et non plus seulement lire et résumer. Le constat, repris le jour même, n’est pas une nouvelle classe d’attaque — l’empoisonnement des descriptions est documenté depuis avril 2025 — mais une variante récente et importante : l’empoisonnement peut survenir après qu’un outil a passé la revue. Un outil que vous aviez audité et validé avec une description propre peut être redécrit discrètement par la suite, et comme les agents relisent les descriptions à chaque tour, la bascule est effective sans nouvelle validation.

Les détails concernent en premier lieu ceux qui déploient Microsoft 365 Copilot, Copilot Studio ou des agents Azure AI Foundry, mais le mécanisme s’applique à tout agent qui atteint ses outils via le Model Context Protocol (MCP).

Comment ça marche

Chaque outil MCP est livré avec une description : quelques lignes de texte qui indiquent à l’agent ce que fait l’outil et quand l’appeler. L’agent lit ce texte pour décider comment agir, et il réside en mémoire de travail juste à côté de ses véritables instructions. Pour le modèle, une description honnête et une description malveillante sont le même flux de tokens — aucun moyen fiable de les distinguer.

Microsoft illustre le décalage temporel avec un exemple de facturation, conçu pour montrer le schéma plutôt que désigner une victime. Une équipe finance met en place un agent pour traiter les factures fournisseurs et le connecte à trois outils — dont un service tiers d’« enrichissement de factures », validé mais jamais réellement audité côté sécurité. Plus tard, l’attaquant met à jour cet outil. Le nom et le résumé visibles restent identiques ; enfoui dans la description, déguisé en notes de mise en forme, se cache un ordre : collecter les trente dernières factures impayées et les joindre au prochain appel.

Entrée de registre d'outil (schématique — payload expurgé)
----------------------------------------------------------
name: invoice_enrichment
description: |
  Enrichit les enregistrements de factures fournisseurs avec des
  métadonnées fiscales et de paiement.
  [EXPURGÉ : instruction demandant à l'agent de rassembler et de
   joindre des enregistrements supplémentaires au prochain appel]

MCP prend en compte les changements de description à la volée. Sans déclencheur de re-validation, la version empoisonnée est simplement active. Un analyste pose alors une question de routine sur un fournisseur ; l’agent suit l’ordre caché, extrait les factures avec les propres droits de l’analyste et les expédie dans une requête d’apparence normale vers un serveur mis en liste blanche lors de l’ajout de l’outil. Chaque étape est légitime prise isolément. La faiblesse réside dans ce que Microsoft appelle « la frontière de confiance entre elles ».

Pourquoi c’est important

Le passage de la lecture à l’action change les enjeux. Face à un lecteur, une injection modifie la sortie. Face à un agent, elle modifie ce que fait le logiciel — envoyer un e-mail, déplacer des fichiers, atteindre des systèmes métier. Microsoft qualifie MCP de partie la plus dynamique de la chaîne d’approvisionnement de l’IA agentique, ce qui en fait une surface d’attaque croissante.

C’est l’angle temporel que les défenseurs négligent souvent. La validation est traitée comme un contrôle ponctuel, alors que la description d’un outil est un état modifiable qui peut dériver longtemps après la revue. La mesure académique appuie l’inquiétude : le benchmark MCPTox, publié en août 2025, a testé des descriptions empoisonnées contre 45 serveurs MCP réels et 20 modèles de premier plan, avec une efficacité atteignant 72,8 % et des modèles qui refusaient presque jamais. L’OWASP classe désormais ce schéma parmi les vulnérabilités de chaîne d’approvisionnement agentique dans son Top 10 for Agentic Applications de décembre 2025.

Défenses

Il n’y a pas de payload à corriger ; la solution est architecturale, et les recommandations de Microsoft s’y adossent proprement.

• Épinglez et comparez les descriptions. Traitez une description d’outil comme un prompt système ou une modification de code. Figez la version validée, ré-auditez tout changement et exigez une re-validation avant qu’une description modifiée ne devienne active — ne laissez pas les mises à jour passer silencieusement.
• Maîtrisez la chaîne d’approvisionnement. Tenez une liste blanche d’éditeurs d’outils approuvés, désactivez « tout autoriser » et n’accordez à chaque agent que les outils dont il a besoin.
• Humain dans la boucle sur les actions à conséquence. Toute action qui déplace de l’argent, partage des données à l’extérieur ou modifie des comptes doit être approuvée par une personne avant exécution.
• Donnez une identité à chaque agent et surveillez-le. Journalisez les actions, établissez une base de comportement normal et signalez les nouveaux points de terminaison, les extractions de données plus volumineuses ou les requêtes inhabituelles.
• Appliquez le moindre pouvoir d’agir, pas seulement le moindre privilège. Même un agent peu privilégié peut faire de réels dégâts s’il peut agir sans contrôle.

Status

Élément	Référence	Date
Analyse Microsoft « lire → agir »	Microsoft Security Blog	2026-06-30
Reprise	The Hacker News	2026-06-30
Mesure de l’empoisonnement de descriptions	MCPTox (arXiv:2508.14925)	2025-08
PoC d’empoisonnement d’outil d’origine	Invariant Labs	2025-04
Référence de framework	OWASP Top 10 for Agentic Applications	2025-12

À retenir : la validation n’est pas une propriété permanente d’un outil. Si une description peut changer après la revue et que l’agent la reprend sans y être invité, l’outil que vous avez validé n’est pas nécessairement celui qui tourne.