Des secrets qui fuient des serveurs MCP : détecter une exposition induite par le protocole

De quoi s’agit-il ?

Le Model Context Protocol (MCP) est devenu la manière standard de connecter les grands modèles de langage à des outils et données externes. Un article arXiv de fin juin 2026, “What Happens Locally, Leaks Globally”: Detecting Privacy Leakage Risks in MCP Servers (2606.21338), soutient que cette commodité s’accompagne d’un risque précis et peu examiné : des valeurs sensibles s’échappent du code d’un serveur MCP non par un appel d’exfiltration évident, mais par la mécanique ordinaire du protocole lui-même.

L’observation centrale est que la fuite est ici induite par le protocole. Dans une application classique, une fuite de données passe généralement par une requête sortante explicite — un POST HTTP, une écriture socket, un log expédié hors machine. Dans un serveur MCP, un identifiant, une clé d’API ou une donnée personnelle (PII) peut franchir la frontière entre la machine locale et le LLM simplement en étant retourné par un gestionnaire d’outil, écrit dans un journal, ou levé dans un message d’exception. Aucun send() à rechercher dans le code source. La valeur quitte le contexte local de confiance dès qu’elle atterrit dans quelque chose que le modèle va lire.

Pour mesurer la fréquence du phénomène, les auteurs ont construit MCPPrivacyDetector, un cadre d’analyse statique, et l’ont exécuté sur 10 655 serveurs MCP réels. Ils rapportent une fuite dans plus de 10 % d’entre eux, avec des cas confirmés incluant des jetons Bearer exposés, des clés d’API propagées et des identifiants d’authentification en clair.

Comment ça marche

Le problème de détection est plus difficile qu’une analyse de teinte (taint analysis) classique, pour deux raisons que l’article traite directement.

D’abord, les serveurs MCP sont écrits dans de nombreux langages — Python, TypeScript, Go et d’autres — si bien qu’un analyseur mono-langage passe à côté de la majorité de l’écosystème. MCPPrivacyDetector transpose ces bases de code hétérogènes vers une représentation de programme unifiée, de sorte que la même logique d’analyse s’applique quel que soit le langage source.

Ensuite, les « puits » (sinks) dangereux ne sont pas les habituels. Un outil standard cherche des puits réseau ou d’écriture de fichier. Ici, les puits sont spécifiques au protocole et implicites : la valeur de retour d’un gestionnaire d’outil, une instruction de journalisation, un objet d’erreur remonté à l’appelant. Le cadre encode ceux-ci comme puits, applique un filtrage sémantique sensible au contexte pour séparer les valeurs réellement sensibles (jetons, clés, PII) des chaînes anodines, puis exécute une analyse de teinte pour énumérer les flux possibles d’une source sensible vers l’un de ces puits implicites.

Source sensible               Puits MCP implicite          Résultat
─────────────────             ──────────────────           ──────
variable d'env / secret  ──►  retour de gestionnaire  ──►  la valeur atteint le contexte du LLM
identifiant de config    ──►  instruction de log      ──►  la valeur écrite dans des journaux partagés
jeton d'auth             ──►  exception / message      ──►  la valeur remontée à l'appelant

Aucun code d’exploitation n’est publié ; la contribution est une étude de mesure assortie d’un détecteur. C’est le même schéma du « canal que les défenseurs inspectent le moins » que l’on voit dans l’injection via les métadonnées de fichiers et dans les failles de serveurs de type taint dans l’écosystème MCP — la différence est qu’ici, le chemin de fuite ressemble, dans le code source, à un comportement d’outil parfaitement normal.

Pourquoi c’est important

Les serveurs MCP manipulent couramment de vrais secrets : tout l’intérêt d’un outil est de s’authentifier auprès d’une base de données, d’une API SaaS ou d’un service interne pour le compte du modèle. Quand ces secrets s’écoulent dans les sorties de gestionnaires, les journaux ou les erreurs, ils deviennent lisibles par le modèle — et, à travers lui, par tout ce à quoi le modèle est exposé. Ajoutez un modèle qui voit aussi du contenu non fiable et peut agir vers l’extérieur, et vous obtenez la trifecta létale classique : un jeton fuité dans une réponse d’outil n’est qu’à une injection indirecte de son exfiltration.

L’échelle fait l’histoire. Un taux de fuite supérieur à 10 % sur plus de dix mille serveurs n’est pas une poignée de déploiements mal configurés ; c’est une propriété structurelle de la façon dont les serveurs MCP sont écrits aujourd’hui, en écho au tableau plus large des motifs de vulnérabilité des backends MCP et à des incidents antérieurs sur un seul serveur comme la fuite de jeton du serveur MCP Splunk. Comme la fuite n’a pas d’appel sortant explicite, elle échappe aussi à la revue de code et à de nombreuses passes de détection de secrets qui ciblent les puits réseau. Cette classe relève directement de l’OWASP LLM02, Divulgation d’informations sensibles.

Défenses

Le principe unificateur : traiter tout ce qu’un gestionnaire d’outil retourne, journalise ou lève comme une donnée qui atteindra le modèle, et donc comme un canal sortant.

Séparez les secrets de la sortie de l’outil. Un gestionnaire ne doit retourner que le résultat dont le modèle a besoin, jamais l’identifiant utilisé pour l’obtenir ; gardez jetons et clés dans une couche que le modèle ne voit jamais. Caviardez avant de retourner : filtrez les valeurs de retour, les lignes de journal et les messages d’erreur pour repérer les chaînes à haute entropie et les formats de secrets connus, afin qu’une exception ne puisse pas expédier un jeton Bearer à l’appelant. Réduisez la portée des identifiants pour qu’un identifiant fuité soit de faible valeur et éphémère, et effectuez une rotation à tout soupçon d’exposition — la même discipline que celle recommandée pour la fuite d’identifiants dans les skills d’agents. Intégrez en CI une analyse statique du type démontré par cet article, en vérifiant spécifiquement les flux vers les puits du protocole plutôt que les seuls puits réseau classiques. Enfin, alignez le déploiement sur les recommandations publiées : les considérations de conception de sécurité MCP de la NSA (juin 2026) et les mitigations cartographiées dans les travaux plus larges sur la confidentialité des agents insistent toutes deux sur une validation stricte des sorties et des frontières à moindre privilège entre un agent et ses fournisseurs de contexte.

Statut

Élément	Détail
Divulgation	Préprint arXiv 2606.21338, fin juin 2026 (étude de mesure + détecteur)
Nature	Fuite induite par le protocole de secrets/PII via retours, journaux et messages d’erreur des gestionnaires d’outils MCP
Détecteur	MCPPrivacyDetector — analyse statique multi-langage + filtrage sémantique contextuel + analyse de teinte vers les puits MCP implicites
Échelle	10 655 serveurs MCP réels analysés ; fuite trouvée dans >10 % ; jetons Bearer, clés d’API, identifiants en clair confirmés
Concernés	Implémentations de serveurs MCP manipulant des secrets (indépendant du langage et du modèle)
Classe	OWASP LLM02 — Divulgation d’informations sensibles

Les résultats reflètent l’étude citée. Un analyseur statique signale des flux possibles, pas des expositions confirmées en production — validez les chemins signalés sur votre propre déploiement avant de conclure quoi que ce soit sur un serveur donné.