Un recensement des infrastructures Model Context Protocol indexées publiquement met en évidence des lacunes de gouvernance concernant l’hébergement, la propriété des domaines et le code exécuté par les services distants.
OX Security indique avoir examiné 15 465 fiches de serveurs MCP provenant de cinq registres, puis regroupé ces enregistrements en 5 095 noms d’hôte uniques. Ces résultats ne correspondent pas à 15 465 exploitants distincts ni à autant d’organisations touchées : le premier chiffre désigne les fiches de serveurs indexées, tandis que le second correspond aux noms d’hôte distincts.
Selon le compte rendu de l’étude publié par OX Security, certains serveurs répertoriés étaient hébergés dans des juridictions potentiellement non autorisées, accessibles par des tunnels grand public ou associés à des domaines qui ne répondaient plus.
Il ne s’agit pas d’un rapport faisant état d’une compromission avérée. Dans son compte rendu publié, OX n’a identifié ni victime, ni vol de données confirmé, ni exploitation active liée aux serveurs étudiés. L’étude décrit plutôt les situations dans lesquelles un agent d’IA pourrait faire confiance à une infrastructure dont la propriété, l’emplacement ou le comportement évolue par la suite.
Des milliers de fiches ramenées à 5 095 noms d’hôte
Le MCP a vu le jour en 2024 comme norme permettant de connecter des modèles d’IA, des agents logiciels et des environnements de développement intégrés à des outils externes et à des sources de données. Un serveur MCP peut mettre des fonctionnalités à la disposition d’un agent et ainsi s’intégrer à des flux de travail sensibles.
L’analyse d’OX porte sur cinq registres MCP, mais le compte rendu publié ne les nomme pas et ne décrit pas leurs procédures respectives d’inscription et d’examen. Il est donc difficile de comparer les registres ou de déterminer si tous appliquent les mêmes contrôles.
La distinction entre fiches et infrastructures est importante. OX a recueilli 15 465 serveurs indexés publiquement, puis la déduplication a ramené ce total à 5 095 noms d’hôte uniques. Plusieurs entrées de registre peuvent donc pointer vers un même nom d’hôte.
Les pourcentages communiqués concernent les noms d’hôte, et non les personnes. Ils ne doivent pas être interprétés comme le nombre de systèmes compromis, de clients ou d’organisations.
Contrairement à un avis de vulnérabilité classique, l’étude ne désigne aucune version de produit défectueuse, n’attribue aucun CVE et ne fournit aucun score de gravité. Le problème est plus général : des agents peuvent se connecter à des services tiers sans garanties suffisantes quant à leur exploitant, au chemin emprunté par les requêtes ou au code backend qui les traite.
L’emplacement de l’hébergement peut créer un flux de données non autorisé
OX indique que 15,6 % des noms d’hôte pointaient vers des infrastructures situées hors des États-Unis. Le compte rendu mentionne précisément 19 noms d’hôte en Chine et 18 en Russie, mais ne fournit pas de répartition complète par pays.
La localisation géographique ne prouve pas qu’un serveur est malveillant. Elle peut toutefois déterminer la juridiction applicable et le respect des exigences internes de résidence des données lorsque l’agent transmet à ce service des prompts, du code source, des identifiants ou des informations commerciales.
Une entreprise peut avoir approuvé un outil d’IA sans examiner séparément chacun des points de terminaison MCP auxquels cet outil peut faire appel. Dans ce cas, la connexion d’un agent risque de créer un flux de données hors des régions autorisées par l’organisation.
OX décrit également un scénario dans lequel un exploitant héberge d’abord un service sur une adresse IP américaine, puis le redirige ailleurs. Les résultats publiés ne permettent pas d’affirmer qu’OX a observé une telle évolution parmi les serveurs étudiés. Il s’agit d’un scénario de menace qui illustre pourquoi une vérification ponctuelle de la localisation ne garantit pas une sécurité durable.
L’enjeu pratique est celui de la vérification continue. Un nom d’hôte peut rester inchangé alors que l’infrastructure qui se trouve derrière est déplacée, sans que les configurations d’agents existantes soient mises à jour.
Les tunnels grand public ne garantissent pas l’identité de l’exploitant du serveur
OX indique que 0,45 % des noms d’hôte étudiés acheminaient le trafic via des services de tunnellisation grand public, principalement ngrok-free.
Un tunnel peut exposer une application exécutée localement sans que son exploitant ait à la déployer sur une infrastructure d’hébergement classique. Cette solution est pratique pour les démonstrations et le développement, mais elle donne aux entreprises moins d’informations sur l’environnement situé derrière le point de terminaison public.
Selon OX, les services répertoriés qui utilisaient des tunnels fonctionnaient sur des ordinateurs personnels. L’organisme estime également qu’ils étaient probablement reliés à des réseaux domestiques, mais cette affirmation sur l’emplacement réseau est une déduction, et non un résultat confirmé pour chaque point de terminaison.
Le problème concerne le contrôle opérationnel, et non une compromission démontrée de la plateforme de tunnellisation. Un service MCP répertorié publiquement peut dépendre de l’ordinateur d’un particulier, d’un processus de déploiement informel ou d’une infrastructure qui échappe aux systèmes habituels de surveillance et de gestion des changements d’une organisation.
Cela peut nuire à la disponibilité comme à la sécurité. L’agent voit un point de terminaison accessible, mais son exploitant ne fournit pas nécessairement les garanties d’identité, de cycle de vie et de chaîne d’approvisionnement attendues d’un service d’entreprise.
Un domaine expiré peut transférer l’identité d’un serveur de confiance
OX a constaté que 2,3 % des noms d’hôte ne résolvaient plus. Six d’entre eux seraient associés à des domaines expirés disponibles à l’enregistrement pour un montant estimé entre 4 et 12 $ par an.
Cela crée un risque de transfert d’identité. Si un agent reste configuré pour contacter l’un de ces domaines, un nouvel acquéreur pourrait réactiver le nom d’hôte et commencer à recevoir les requêtes destinées à l’ancien exploitant du serveur MCP.
Le domaine prend de la valeur parce que la confiance peut subsister dans les configurations des clients après l’expiration de son enregistrement. Les utilisateurs peuvent continuer à reconnaître le nom du serveur, tandis que les agents automatisés risquent de ne pas distinguer l’ancien exploitant du nouvel acquéreur.
OX ne signale pas qu’un attaquant ait effectivement enregistré l’un des six domaines. Le compte rendu ne fait pas non plus état de requêtes interceptées par leur intermédiaire. Le constat met en évidence une possibilité de prise de contrôle, et non une prise de contrôle réalisée ou une exposition confirmée.
Les conséquences dépendraient également de l’usage fait du point de terminaison par l’agent. Les chiffres publiés ne précisent pas quels outils, quelles autorisations ou quelles informations étaient accessibles aux clients configurés pour utiliser les domaines concernés.
Un dépôt public ne prouve pas ce qu’exécute un serveur distant
L’étude remet également en question une idée répandue lors de l’examen de logiciels : consulter un dépôt public suffirait à établir le comportement d’un service MCP distant.
L’examen d’un dépôt peut aider à évaluer le code source, les dépendances et les fonctionnalités déclarées. Mais si les utilisateurs ne peuvent pas vérifier le lien entre ce code et le service déployé, le backend distant peut exécuter une autre version, voire une logique entièrement différente.
OX estime que les places de marché MCP ne disposent pas d’un dispositif équivalent à l’analyse des applications contre les logiciels malveillants pratiquée par les boutiques d’applications. Selon l’organisme, les éditeurs peuvent y proposer des serveurs sans procédure de vérification comparable. Le compte rendu ne nomme pas les cinq registres et ne décrit pas leurs contrôles respectifs ; les informations disponibles ne permettent donc pas de généraliser ce constat à chacun d’eux.
L’article cite Google Bouncer, que Google utilisait en 2012 pour analyser les applications Android, à titre de comparaison. Il rappelle aussi que des chercheurs ont trouvé des moyens de contourner Bouncer. Une telle vérification ne constitue donc pas une garantie absolue, mais elle peut ajouter une étape d’examen qui, selon OX, fait défaut dans l’écosystème MCP.
Le rapport complet d’OX, intitulé « 15,465 MCP Servers, 0 Governance », contiendrait une preuve de concept d’injection de prompt ainsi que d’autres scénarios de menace. Le résumé publié ne fournit pas assez de détails techniques pour déterminer les conditions nécessaires à la preuve de concept ni si celle-ci a été testée contre un service tiers en production.
Les entreprises doivent encadrer les connexions, pas seulement examiner le code
OX appelle les places de marché MCP à mettre en place des contrôles des éditeurs, la signature du code et la vérification de l’origine. Ces mesures permettraient de répondre à trois questions distinctes : qui est autorisé à publier, si un artefact a été modifié et si un service distant correspond à la source attendue.
Les organisations qui utilisent MCP peuvent également intégrer ces connexions à leurs programmes de gouvernance existants. L’étude préconise notamment des règles de résidence des données, des frontières Zero Trust, une gestion granulaire des identités et des accès (IAM) et des audits de la chaîne d’approvisionnement.
Appliquées aux déploiements MCP, ces mesures impliquent de savoir quels serveurs sont accessibles à chaque agent et de vérifier que leurs points de terminaison restent dans les juridictions et sous les régimes de propriété autorisés. L’état d’un domaine et la localisation d’un hébergement ne sont pas immuables : une autorisation accordée après un examen initial peut donc devenir obsolète.
L’examen d’un dépôt doit lui aussi être considéré comme une source d’information parmi d’autres, et non comme une preuve du comportement à l’exécution. Pour les flux de travail qui traitent des informations sensibles, les organisations doivent obtenir des garanties sur le service déployé et son exploitant, et pas seulement sur le code présenté dans un projet public.
OX fait également référence à des travaux antérieurs portant sur des vulnérabilités du code source MCP d’Anthropic. L’organisme qualifie ces problèmes de critiques et indique que le code aurait été téléchargé plus de 150 millions de fois. Le compte rendu disponible ne fournit ni identifiants CVE, ni versions concernées, ni éléments techniques, ni détails sur les mesures correctives. Ces constats antérieurs ne peuvent donc pas être évalués dans le cadre de l’étude actuelle sur les serveurs.
Les mesures présentées restent celles d’OX et n’ont pas fait l’objet d’une validation indépendante dans les documents disponibles pour cet article. Elles mettent néanmoins en évidence un problème concret de gouvernance : la relation de confiance d’un agent d’IA peut perdurer au-delà de l’infrastructure, du propriétaire du domaine ou de l’implémentation logicielle qui la justifiait à l’origine.
