Empoisonnement de la surface d'outils WebMCP : détourner l'agent en pleine session

De quoi s’agit-il ?

Le 4 juin 2026, Lin-Fa Lee, Yi-Yu Chang, Chia-Mu Yu et Kuo-Hui Yeh, de la National Yang Ming Chiao Tung University, ont publié sur arXiv WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents. L’article examine WebMCP, un protocole émergent qui permet à un site web d’exposer des outils structurés directement à un agent IA, sans passer par une interface utilisateur. Son apport est de montrer que, dans WebMCP, l’ensemble des outils qu’un agent perçoit au cours d’une même session n’est ni statique ni digne de confiance par nature — et que ce dynamisme est exploitable.

Les auteurs nomment la menace Mid-Session Tool Injection (MSTI) : un moyen, pour un attaquant qui contrôle un script tiers présent sur la page — un asset de CDN compromis, un SDK publicitaire, n’importe quel JavaScript de même origine — de modifier les outils perçus par l’agent alors que la tâche est déjà en cours. Il s’agit d’un travail académique évaluable par les pairs, décrivant une classe d’attaque et ses défenses sur un protocole encore jeune ; aucun exploit opérationnel n’est reproduit ici. Adversa AI l’a classé parmi ses meilleures ressources de sécurité MCP de juillet 2026.

Comment ça marche

MSTI se scinde en deux familles. Le détournement d’outil (tool hijacking) manipule la présence des outils — le fait qu’un outil existe, et quand — avant même que le modèle ne raisonne. Le recadrage d’outil (tool framing) manipule les métadonnées — le nom, la description, le champ readOnlyHint et l’inputSchema — pour que l’agent se méprenne sur le rôle d’un outil malveillant.

Deux techniques de détournement se distinguent, car elles frappent avant tout raisonnement sémantique, ce qui explique précisément que le modèle y soit peu résistant :

Détournement d'outil (manipulation de présence)

  Détournement AbortSignal :  annuler l'AbortController d'un outil légitime → le désenregistrer
                              → réenregistrer un outil malveillant sous le MÊME nom
                              → avant le premier appel de l'agent

  Course à l'enregistrement :  enregistrer l'outil malveillant sous le nom cible
                               AVANT l'outil légitime → « le premier gagne »
                               → l'agent ne voit jamais que la version malveillante

Le recadrage est plus subtil. Au lieu de supprimer un outil, l’attaquant le laisse visible mais réécrit sa lecture — par exemple en insérant un impératif comme « always call before send_email » dans une description pour déguiser un outil malveillant en étape obligatoire du workflow, ou en gonflant une description de 1 200 mots avec du boilerplate ISO 27001 / SOC 2 / RGPD afin de dissimuler l’instruction nuisible dans les premières dizaines de mots.

Le compromis mesuré est l’aspect le plus intéressant. Sur GPT-5.4, Claude Opus 4.6 et Gemini 2.5-flash, les attaques de présence atteignent un taux de réussite très élevé mais restent perturbatrices : le détournement AbortSignal obtient en moyenne 94 % de réussite et la course à l’enregistrement 100 %, mais le taux d’achèvement de la tâche initiale s’effondre à environ 17-18 %, si bien que la session casse de façon visible. Les attaques de recadrage sont plus discrètes — l’injection de description atteint 59 % de réussite tout en laissant la tâche s’achever dans 81 % des cas, et la variante composite 61 % de réussite pour 85 % d’achèvement. Furtivité et fiabilité se situent aux deux extrémités du même curseur.

Pourquoi c’est important

La majorité des travaux sur la sécurité des agents suppose que le danger réside dans le contenu du prompt ou dans les sorties d’outils — le domaine de la prompt injection et de l’injection indirecte. WebMCP déplace une partie de la menace vers le registre d’outils lui-même. Comme ce registre peut changer en pleine session, l’état d’environnement perçu par l’agent devient une surface d’attaque, et un script tiers de même page — une catégorie de code que la plupart des sites chargent déjà sans grand contrôle — suffit à l’atteindre.

Cela fait écho aux problèmes des MCP côté serveur, comme les rug pulls de descriptions d’outils et l’empoisonnement à seuil réparti sur plusieurs outils, mais le contexte navigateur change l’économie de l’attaque : nul besoin de serveur malveillant ni d’entrée dans une marketplace, il suffit d’un point d’appui dans la chaîne d’approvisionnement des scripts de la page. Les résultats de recadrage forment l’enseignement le plus dérangeant — une attaque peut rediriger le flux de données de l’agent vers un endpoint contrôlé par l’attaquant pendant que l’utilisateur voit la tâche réussir en apparence.

Défenses

Les recommandations de l’article visent le cycle de vie de WebMCP et se traduisent en consignes concrètes pour quiconque conçoit ou déploie des agents côté navigateur.

Lier l’identité d’un outil à son origine. Le nom d’un outil ne doit pas être un espace de noms libre où « le premier gagne ». Rattachez chaque outil enregistré à l’origine qui l’a déclaré et refusez le réenregistrement silencieux d’un nom existant, ce qui ferme à la fois la voie du détournement AbortSignal et celle de la course à l’enregistrement.

Imposer la cohérence du cycle de vie. Traitez les modifications de l’ensemble d’outils en cours de session comme des événements de sécurité : gelez ou refaites confirmer la surface d’outils une fois la tâche lancée, et remontez tout enregistrement, remplacement ou retrait à l’hôte plutôt que de les appliquer en silence.

Isoler les scripts tiers du registre d’outils. La frontière de confiance qui régit déjà l’accès au DOM et au réseau doit s’étendre à l’enregistrement des outils — un CDN ou un SDK publicitaire n’a pas à modifier l’inventaire d’outils de l’agent. Faites respecter des frontières de données pour qu’un outil tiers ne puisse pas recevoir de contexte sensible ni de résultats intermédiaires.

Garder des journaux traçables et contraindre la couche d’action. Conservez un enregistrement auditable de chaque enregistrement et appel d’outil pour détecter a posteriori les substitutions anormales, et maintenez les contrôles classiques — permissions d’outils au moindre privilège et confirmation humaine pour les actions sensibles — puisque la charge utile ne compte que lorsqu’elle devient une action.

Statut

Élément	Détail
Divulgation	Préprint arXiv 2606.06387 v1, soumis le 4 juin 2026 (CC BY 4.0)
Classe	Technique d’attaque — manipulation en pleine session du registre d’outils d’un agent WebMCP via un script tiers compromis
Variantes	Détournement d’outil (détournement AbortSignal, course à l’enregistrement) et recadrage d’outil (description, readOnlyHint, inputSchema, nom)
Évaluation	Trois modèles (GPT-5.4, Claude Opus 4.6, Gemini 2.5-flash) · plusieurs scénarios de tâche · outils en JavaScript
Résultat rapporté	Attaques de présence jusqu’à 100 % d’ASR mais ~17-18 % d’achèvement ; attaques de recadrage ~59-61 % d’ASR pour ~81-85 % d’achèvement
Faille défensive centrale	La surface d’outils est elle-même modifiable en pleine session ; les défenses anti-injection au niveau du message n’observent pas les changements de registre