Le modèle de confiance de MCP a permis à un agent empoisonné de s’infiltrer dans un autre

Le protocole devenu la manière par défaut de connecter les agents d’IA entre eux souffre d’un problème de confiance, et sa forme mérite d’être comprise avant le prochain incident.

Ars Technica a rapporté le 5 octobre qu’un chercheur indépendant, Syed Anas Mohiuddin, a démontré une classe d’attaques qu’il appelle « protocol pivoting ». L’idée est simple. Au sein d’un réseau, les agents communiquent entre eux via le Model Context Protocol, ou MCP. Les garde-fous sont les plus faibles au moment où un agent confie une tâche à un autre, car le second agent fait confiance au premier par défaut. Injectez une instruction malveillante dans un agent de traduction ou d’analyse de données dépourvu de validation stricte des entrées, et il transmettra l’instruction en aval. Le destinataire obéit, car pourquoi un collègue de confiance mentirait-il ?

La preuve de concept de Mohiuddin a traversé cinq organisations sans lien entre elles : Google, JPMorgan Chase, Weviate, Rapid7, la direction interministérielle du numérique de France et une agence fédérale américaine. Ces organisations ont peu en commun, hormis une utilisation intensive d’agents. C’est là tout l’enjeu. La faiblesse se situe dans la plomberie, pas dans un produit particulier.

Deux CVE et un écart de notation

Les bugs concrets sont ordinaires, ce qui rend l’histoire d’autant plus inconfortable. Le serveur MCP de Rapid7 porte la CVE-2026-97228, que l’entreprise a corrigée en septembre 2026 alors même que la faille était notée 2,7 sur 10. Le problème de Google était mieux classé, avec un 8, et concernait googleapis/mcp-toolbox. Son client HTTP n’avait ni politique CheckRedirect ni validation de l’adresse IP cible, de sorte qu’un paramètre de chemin forgé pouvait rediriger une requête vers un point de terminaison interne. Google a ajouté des listes d’autorisation et de blocage d’IP et fait en sorte que la boîte à outils rejette les URL de base non sûres au démarrage.

L’inadéquation des scores de gravité est une leçon en soi. Deux organisations ont trouvé des faiblesses comparables dans le même protocole et les ont notées très différemment, ce qui suggère que l’industrie n’a pas encore tranché sur ce que devrait coûter un déficit de confiance d’agent à agent.

Tout le monde n’accepte pas le « protocol pivoting » comme une nouvelle catégorie. Markus Vervier, chercheur chez X41 D-Sec, a déclaré à Ars Technica qu’il y voit une injection indirecte de prompt, la même technique que les équipes de sécurité suivent depuis deux ans. Cette lecture est juste, et elle aiguise aussi le problème pratique : la stratégie défensive contre l’injection de prompt suppose que l’entrée vient de l’extérieur. Ici, elle vient de l’intérieur, revêtue d’un identifiant interne.

Le déficit est architectural, et non un simple correctif

Un rapport distinct de l’éditeur de sécurité ClawSecure pousse l’analyse un cran plus loin. Ses chercheurs ont testé Linear, Notion et Dropbox Dash et soutiennent que la faille réside dans la spécification MCP plutôt que dans l’implémentation d’un quelconque fournisseur. Dans Notion et Linear, ils ont trouvé des serveurs MCP qui récupèrent automatiquement des liens contrôlés par l’attaquant dès qu’un contenu est créé, sans aucun modèle dans la boucle. Toute personne disposant d’un accès en écriture à un espace de travail peut le transformer en canal de fuite, sans avoir besoin d’un prompt habilement formulé.

Leurs chiffres sont sans appel. Sur 20 techniques d’obfuscation, notamment les caractères Unicode de largeur nulle et les homoglyphes, 17 ont survécu à l’aller-retour. Sur 14 modèles issus de cinq laboratoires, aucun n’a bloqué les menaces de manière cohérente ; le meilleur, Claude Opus 4.7, suivait encore des instructions malveillantes dans environ 26,7 % des cas.

ClawSecure vend des produits de sécurité et le rapport n’a pas été répliqué indépendamment ; il convient donc de traiter l’affirmation sur la couche plateforme avec la prudence qui s’impose. Les conditions sous-jacentes sont toutefois faciles à vérifier. MCP enregistre plus de 500 millions de téléchargements mensuels du SDK et près de 16 000 serveurs publics, et selon un décompte, seuls 8,5 % de ces serveurs utilisent OAuth. L’adoption a devancé le durcissement.

AWS a apporté ses propres éléments de preuve dans un bulletin publié le 2 octobre. Trois failles dans sa plateforme open source d’orchestration d’agents Loom pouvaient permettre une prise de contrôle administrative non authentifiée, la divulgation d’identifiants OAuth2 et l’accès à des services internes. La plus grave, CVE-2026-103956, laissait n’importe quel client réseau atteindre le plan de contrôle des agents dans les déploiements sans fournisseur d’identité configuré. Les versions 1.6.1 et 1.7.0 de Loom comblent ces failles.

Pourquoi l’hypothèse de confiance par défaut constitue la véritable découverte

Mettez de côté les CVE et un choix de conception ressort. Les agents sont conçus pour coopérer : ils s’authentifient mutuellement, puis se comportent comme si un identifiant valide signifiait aussi une requête valide. Le zéro trust classique dit l’inverse : prouver chaque requête sur ses propres mérites, même depuis l’intérieur du périmètre.

Les attaques de Mohiuddin fonctionnent en exploitant cette inversion. L’instruction malveillante franchit la frontière d’autorisation entre systèmes précisément parce qu’elle ne franchit jamais de frontière dans le code. Elle se déplace d’agent en agent au sein d’un même tissu de confiance, et plus aucune couche n’est là pour demander si la requête avait un sens.

Ce que les équipes peuvent faire cette semaine

Les correctifs immédiats sont peu glamour et disponibles dès maintenant. Traitez toute instruction provenant d’un modèle de langage comme une entrée hostile, quel que soit l’agent qui l’a produite. Appliquez une gestion stricte des redirections et validez les IP de destination. Exigez une authentification par agent avant qu’un agent délègue à un autre, et journalisez la délégation afin qu’une chaîne de transmissions puisse être reconstituée a posteriori.

À plus long terme, attendez-vous à ce que les organismes de normalisation codifient le protocol pivoting comme une classe de menace nommée, ce qui pousserait les fournisseurs à intégrer des contrôles zéro trust à l’intérieur de MCP plutôt qu’à côté. Les auditeurs suivront, et les questions sur les garde-fous entre agents commenceront à apparaître dans les revues de conformité, comme les règles de pare-feu il y a une génération.

La partie inconfortable de cette histoire, c’est que l’astuce fonctionne mieux une fois que les agents se font confiance. Chaque organisation qui se précipite pour connecter ses outils via MCP est en train de bâtir ce tissu de confiance, et la plupart du temps sans plan pour ce qui se passe lorsqu’un membre de l’équipe se révèle menteur.

Pourquoi cela arrive maintenant

Aucune des techniques sous-jacentes n’est nouvelle. Les vulnérabilités de type server-side request forgery et les bugs d’injection figurent sur la liste OWASP depuis des années. Ce qui a changé, c’est l’endroit où elles s’exécutent. Les agents ont donné à ces vieux bugs une nouvelle voie de livraison, car un agent agira volontiers sur une phrase dans un document, un champ dans une ligne de base de données ou une ligne dans la sortie d’un autre agent. L’instruction n’a pas besoin d’être saisie par un attaquant. Il suffit qu’elle finisse quelque part où le modèle la lit.

C’est pourquoi la divulgation couvre une banque, un moteur de recherche, un éditeur de sécurité et une direction gouvernementale. Ils ne partageaient ni code ni fournisseur. Ils partageaient une architecture, et cette architecture porte l’hypothèse que chaque participant est digne de confiance. MCP est passé d’une idée nouvelle à une infrastructure critique en environ un an, avec des téléchargements mesurés en centaines de millions par mois, et l’examen de sécurité qui accompagnerait normalement cette croissance n’a pour l’essentiel pas eu lieu.

Il existe une version de cette histoire qui se termine bien. Les bugs sont en cours de correction, les responsables du protocole sont réactifs, et les attaques nécessitent soit un accès en écriture, soit un point d’appui à l’intérieur du réseau, ce qui constitue un seuil significatif. Mais le correctif qui compte est culturel plutôt que technique. Les équipes qui adoptent des agents doivent cesser de considérer un identifiant interne valide comme la preuve qu’une requête est légitime, et commencer à valider chaque requête comme si elle venait d’un inconnu. C’est un changement plus difficile à livrer que n’importe quel patch, et c’est celui que la prochaine série d’incidents mettra à l’épreuve.