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

De quoi s’agit-il ?

WebMCP est une capacité web émergente qui permet à un site d’exposer des outils structurés directement à un agent IA qui pilote le navigateur — y compris un agent hébergé dans une extension. Au lieu de deviner comment cliquer sur une page, l’agent se voit déclarer des outils appelables (avec noms, paramètres et descriptions) qu’il peut invoquer. Cette commodité crée une nouvelle surface d’attaque dynamique : l’ensemble des outils disponibles pour un agent, et les métadonnées qui les décrivent, sont fournis par la page web que l’agent est en train de lire, et peuvent changer à l’exécution.

Un article arXiv de juin 2026, WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents (2606.06387), formalise ce problème sous le nom de Mid-Session Tool Injection (MSTI) — la manipulation de la surface d’outils d’un agent pendant une session active, plutôt que via un manifeste statique enregistré à l’avance. Le même mois, Chrome a publié un guide de sécurité officiel pour les agents utilisant WebMCP (9 juin 2026), et la synthèse MCP de juillet 2026 d’Adversa AI a cité la technique parmi les menaces agentiques notables du mois. Comme il s’agit d’une faiblesse de conception dans la façon dont les agents consomment les définitions d’outils, il vaut la peine de la comprendre avant que l’adoption de WebMCP ne s’élargisse.

Comment ça marche

La MSTI fonctionne parce qu’un LLM traite les métadonnées d’outils et les sorties d’outils comme faisant partie du même flux de tokens dans lequel il lit ses instructions — le problème classique de l’injection indirecte de prompt, appliqué à un registre d’outils vivant. La recherche regroupe les attaques en deux familles.

Le détournement d’outils (tool hijacking) modifie quels outils l’agent voit. Un script tiers présent sur la page peut enregistrer ou désenregistrer des outils après que l’agent a déjà commencé une tâche, en exploitant des fenêtres temporelles — par exemple une course à l’enregistrement (registration race), ou l’annulation d’un enregistrement en cours via l’API AbortSignal du navigateur — si bien que l’agent se retrouve avec un ensemble d’outils que l’auteur du site n’avait jamais prévu. Le cadrage d’outils (tool framing) laisse l’ensemble d’outils intact mais manipule la perception qu’a l’agent de chaque outil, en plaçant du contenu trompeur dans des champs de métadonnées comme le nom, la description, readOnlyHint ou inputSchema. Un outil annoté comme « lecture seule », ou décrit comme inoffensif, peut ainsi être orienté vers une action que l’utilisateur n’a jamais autorisée.

Le guide de Chrome décrit la même surface en deux vecteurs : les manifestes malveillants (instructions cachées dans les noms, paramètres ou descriptions d’outils) et les sorties contaminées (un site de confiance renvoyant des données tierces — un commentaire d’utilisateur, par exemple — porteuses d’instructions injectées). Le flux conceptuel, sans reproduire de charge active fonctionnelle :

[ web page ] -- declares/mutates --> [ WebMCP tool surface ]
      │                                        │
      │ third-party script                     │ metadata: name, description,
      │ (registration race / AbortSignal)      │ readOnlyHint, inputSchema
      ▼                                        ▼
[ tool set the agent sees ]  ◄── poisoned ──  [ attacker-influenced framing ]
      │
      ▼
[ agent plans + calls tools in the user's authenticated session ]

L’article rapporte des taux de succès élevés pour ces manipulations à l’exécution. Comme le contrôle injecté réside dans la couche des outils plutôt que dans le texte visible de la page, il peut échapper aux défenses qui n’inspectent que le contenu de la page.

Pourquoi c’est important

La gravité tient à l’endroit où s’exécutent les agents de navigateur : à l’intérieur de la session authentifiée de l’utilisateur. Un agent connecté à une messagerie, un CRM, un hébergeur de code ou une application comptable hérite de toutes les permissions que cette session détient déjà. Un appel d’outil détourné ou mal cadré peut alors lire, envoyer, modifier ou supprimer des données sans nouvelle demande d’authentification. La MSTI relève l’enjeu par rapport à l’empoisonnement d’outils statique, car le manifeste qu’un agent a validé au début d’une tâche n’est pas garanti d’être celui sur lequel il agit quelques instants plus tard — une confiance établie une fois ne tient pas pour toute la session.

Défenses

Le guide de Chrome de juin 2026 recommande une défense en profondeur répartie entre garde-fous déterministes et probabilistes, et elle s’applique directement à la MSTI.

Mettez en place des garde-fous déterministes : plafonnez les tokens des réponses d’outils entrantes et rejetez les charges qui dépassent la limite ; restreignez l’ensemble des origines web avec lesquelles un agent peut interagir à celles pertinentes pour la tâche en cours, réduisant la surface d’exfiltration ; et gardez l’humain dans la boucle en exigeant une confirmation pour les actions qui modifient un état — supposez qu’un outil modifie l’état sauf si ses annotations le démentent clairement, et ne considérez jamais readOnlyHint comme un contrôle de sécurité.

Ajoutez des garde-fous probabilistes : appliquez le spotlighting pour que le modèle traite les sorties et les métadonnées d’outils comme des données non fiables, et non comme des instructions. Chrome décrit deux méthodes — un délimitage léger pour le contenu à faible risque, et l’encodage en base64 du contenu non fiable pour les cas à haut risque (robuste face à l’évasion par injection de délimiteur, au prix d’environ un tiers de tokens en plus) — le tout ancré par une instruction système qui indique au modèle de décoder uniquement pour analyse et de ne jamais exécuter ce qu’il y trouve.

Superposez classifieurs et critiques : analysez les descriptions d’outils et les sorties d’outils à la recherche d’instructions injectées avant tout appel, et utilisez un modèle « critique » distinct — non exposé au contenu non fiable — pour vérifier que chaque appel d’outil planifié correspond au véritable objectif de l’utilisateur et ne transporte que le minimum de données nécessaire. Enfin, revalidez la surface d’outils en continu plutôt qu’une seule fois au démarrage de la tâche, traitez l’enregistrement et le désenregistrement d’outils en cours de session comme des événements de sécurité, et surveillez la production pour détecter des anomalies telles que des pics d’épuisement de tokens. Des suites de red teaming open source (par exemple Promptfoo) et des outils d’audit d’agents permettent de mesurer si ces mitigations tiennent réellement avant la mise en production.

Statut

Élément	Référence	Date	Notes
Article de recherche	WebMCP Tool Surface Poisoning, arXiv 2606.06387	juin 2026	Formalise l’injection d’outils en cours de session (MSTI)
Familles d’attaque	Détournement d’outils ; cadrage d’outils	juin 2026	Registration race / AbortSignal ; manipulation de métadonnées
Guide éditeur	Chrome — Considérations de sécurité pour les agents WebMCP	2026-06-09	Garde-fous déterministes + probabilistes
Veille industrie	Adversa AI — synthèse sécurité MCP	2026-07-06	Citée comme menace agentique de juillet 2026
Surface affectée	Agents de navigateur WebMCP, extensions comprises	—	S’exécute dans la session authentifiée de l’utilisateur