Les fichiers MCP publics peuvent exposer des accès sensibles

Les fuites d'identifiants MCP deviennent un problème de gouvernance de l'IA

Une configuration publique de Model Context Protocol peut exposer un secret ainsi que des instructions pour l'utiliser. Les configurations MCP indiquent aux agents d'IA de codage quels outils d'entreprise ils peuvent atteindre et comment s'authentifier. Un identifiant exploitable peut donc donner à un agent une identité ayant accès aux applications, services et données de l'entreprise. Les conclusions de Hush Security sur les configurations publiques sur GitHub établissent le problème de gestion des secrets. MCP y ajoute une conséquence de gouvernance de l'IA, car un logiciel peut utiliser ces identifiants de manière autonome.

Cette conséquence découle du rôle de MCP en tant que standard ouvert conçu pour faciliter l'interrogation de bases de données externes et d'environnements de développement par les modèles de langage. MCP devient rapidement un moyen standard pour les agents d'IA de codage de se connecter aux outils et aux données de l'entreprise, si bien que ses fichiers de configuration définissent de plus en plus à la fois les connexions et l'authentification nécessaire pour les utiliser. Une configuration exposée publiquement peut ainsi fournir des éléments d'attaque utiles en montrant comment un outil d'IA se connecte à d'autres systèmes.

Cette combinaison a conduit à des avertissements urgents de la part de spécialistes de la sécurité. « Les RSSI devraient être très inquiets », a déclaré Keith Guttridge, analyste chez Gartner. Matthew Smith, RSSI virtuel et consultant en management spécialisé dans la gestion des risques de cybersécurité et de l'IA, a déclaré à TechTarget que la menace « est réelle, exploitée aujourd'hui, et devrait être une préoccupation majeure pour les RSSI ayant du développement dans leur pipeline ». L'activité de conseil de Smith lui donne un intérêt commercial dans la demande organisationnelle en matière de cybersécurité et d'orientation sur les risques liés à l'IA ; son avertissement doit donc être lu en gardant cette incitation à l'esprit.

Les données sur les configurations publiques établissent une exposition substantielle des secrets

L'exposition immédiate est visible dans l'examen par Hush Security d'environ 82 000 fichiers de configuration MCP publics sur GitHub, couvrant plus d'une douzaine d'agents de codage. Les chercheurs ont inspecté les emplacements d'identifiants, c'est-à-dire les parties de ces configurations utilisées pour fournir des informations d'authentification aux services connectés. Ils ont constaté que 12 % contenaient un identifiant codé en dur, c'est-à-dire qu'un secret réel tel qu'une clé API, un mot de passe ou un jeton d'accès avait été écrit directement dans la configuration.

Cette part est importante, car toute personne disposant d'un accès à internet peut trouver une configuration publiée dans un dépôt GitHub public. Un secret littéral dans la configuration peut potentiellement être réutilisé contre le service, l'application ou les données qui lui sont associés. Les identifiants exposés comprenaient des clés API Anthropic et OpenAI, montrant que les identifiants des services d'IA eux-mêmes font aussi partie du problème.

L'impact peut s'aggraver lorsqu'un identifiant exposé combine une longue durée de vie avec des autorisations étendues. Parmi les identifiants codés en dur trouvés par Hush Security, 24 % étaient à la fois sans expiration et à large périmètre. Ces propriétés peuvent fournir un accès étendu à des actifs, notamment des bases de données et des espaces de travail, pour une durée indéfinie, à moins qu'une autre action n'invalide l'identifiant. Hush Security a un intérêt commercial dans la sécurité des entreprises, ce qui constitue un contexte pertinent pour son interprétation du risque, tout en laissant les mesures rapportées claires.

Ces mesures établissent l'exposition d'identifiants dans des configurations MCP publiques et décrivent des propriétés importantes des secrets exposés. L'identité machine devient pertinente lorsqu'un agent fonctionne avec l'un de ces identifiants. À partir de là, la question de sécurité ne se limite plus à savoir si un secret est public, mais s'étend à ce qu'un logiciel peut faire avec l'identité que ce secret permet.

MCP peut transformer un secret divulgué en identité autonome

Ce basculement peut se produire via un chemin d'exploitation court, car une configuration MCP publique contient déjà les informations dont un agent a besoin pour se connecter. Un attaquant peut trouver une configuration contenant un identifiant codé en dur exploitable, copier les informations de configuration et d'identifiant pertinentes dans un agent d'IA, et potentiellement atteindre les applications, services ou données associés à cette identité. Guttridge a décrit l'effort requis en termes directs : « C'est tout ce qu'il faut. Aucun besoin d'avoir la moindre compréhension technique. »

Cette facilité de réutilisation devient plus lourde de conséquences lorsque l'identifiant dispose d'autorisations étendues et reste valide indéfiniment. Un identifiant exposé, à large périmètre et sans expiration, peut continuer à fournir un accès substantiel jusqu'à ce que quelqu'un l'invalide. MCP ajoute une dimension d'exploitation autonome à cet accès, car un logiciel peut agir avec cette identité sans qu'une personne ait à effectuer chaque opération.

Hush Security a formulé cette distinction de manière directe : « Pire encore, cela accorde cet accès à un agent, pas à une personne. » Les chercheurs ont poursuivi : « Un serveur MCP agit sous cette identité de manière autonome : aucun humain dans la boucle, aucun processus d'arrivée-mobilité-départ pour la révoquer, et souvent aucune trace de la personne qui l'a créée. » Les processus d'arrivée-mobilité-départ régissent les accès lorsque les employés rejoignent une organisation, changent de poste et la quittent ; un agent en dehors de ces processus peut donc conserver une identité sans les événements organisationnels habituels qui déclenchent les changements d'accès.

Cette autonomie fait de l'identité machine une composante du problème de gouvernance de l'IA. Un serveur MCP peut fonctionner avec les autorisations de l'identifiant alors que les signaux normaux liés à un compte humain peuvent être absents. Les équipes de sécurité doivent donc savoir quels agents possèdent des identités, ce que ces identités peuvent atteindre et comment leur accès sera supprimé.

La même identité peut aussi exposer deux types d'actifs organisationnels : l'information et la capacité de dépense. Smith a averti que des attaquants pourraient utiliser des identifiants MCP exposés pour voler des informations privées et générer d'importantes facturations de tokens d'IA pour l'organisation propriétaire de la clé. Un identifiant de service d'IA peut donc créer une exposition financière directe lorsqu'un attaquant utilise la capacité de consommation payante de l'organisation.

Ce risque de dépense explique pourquoi Smith a déclaré que les attaquants recherchent spécifiquement des clés d'IA pour alimenter leur consommation de tokens. La réutilisation d'une clé API Anthropic ou OpenAI exposée peut imposer des coûts importants à l'organisation victime, car la consommation est facturée au détenteur légitime. Pour les responsables sécurité et ingénierie, le périmètre d'un identifiant inclut donc à la fois les systèmes auxquels une identité peut accéder et les ressources qu'elle peut consommer.

L'historique Git peut conserver l'exposition des identifiants

Lorsqu'une équipe découvre un identifiant MCP codé en dur, modifier la configuration actuelle laisse une partie importante de la réponse inachevée. Hush Security a constaté que des secrets supprimés des configurations actuelles pouvaient rester présents dans des versions antérieures stockées dans l'historique Git. Le fichier visible peut être propre alors qu'une révision plus ancienne expose encore un identifiant fonctionnel à quiconque le récupère.

Cette persistance rend nécessaire l'invalidation côté fournisseur, car supprimer la valeur littérale ne modifie que la configuration actuelle. Des copies historiques peuvent rester exploitables tant que l'identifiant lui-même reste valide. La conclusion de Hush Security est explicite : « La seule chose qui mette réellement fin à l'exposition est la rotation de l'identifiant chez le fournisseur. » La rotation met fin à l'utilité de la valeur exposée partout où une copie subsiste.

Après la rotation, les équipes peuvent modifier le modèle de configuration qui a créé l'exposition. Hush Security a identifié des approches plus sûres, notamment l'expansion $, qui fournit un identifiant via une variable, ainsi que les prompts natifs du client, les gestionnaires de secrets et les placeholders. Ces modèles gardent la valeur réelle de l'identifiant hors de la configuration validée, réduisant la probabilité que l'historique Git devienne un enregistrement durable d'un secret actif.

Gouverner les connexions MCP existantes

Une gestion plus sûre des identifiants ne résout pas pour autant le problème de gouvernance plus large, car l'adoption de MCP peut s'étendre au-delà des déploiements d'IA officiellement approuvés. Guttridge a déclaré que les organisations disposant d'agents d'IA, qu'ils soient approuvés ou non, utilisent probablement déjà MCP pour connecter ces agents aux systèmes de l'entreprise. Il a qualifié MCP de problème « d'aujourd'hui » et a averti : « Si vous n'avez pas commencé à gouverner MCP, vous êtes déjà en train de courir après le retard. »

Cette adoption existante fait de la découverte le prochain problème de contrôle. Brandon Dixon, CTO et cofondateur de l'entreprise de cybersécurité IA Ent, présente la tâche du RSSI en deux volets : sécuriser les processus internes de développement logiciel IA de l'organisation et identifier quelles ressources privilégiées les utilisateurs connectent aux modèles d'IA via des serveurs MCP. Ent a un intérêt commercial dans la demande de cybersécurité IA ; ses recommandations proviennent donc d'une entreprise susceptible de bénéficier des investissements des organisations dans ce domaine.

Dixon relie directement ce problème de découverte à l'adoption non approuvée. « C'est un appel à l'action immédiat », a-t-il déclaré. « L'IA est utilisée au sein de l'organisation, que le RSSI ait approuvé le logiciel ou non. » Un inventaire des logiciels d'IA approuvés peut donc laisser des clients MCP, des serveurs et des connexions privilégiées en dehors de l'environnement connu de l'organisation.

Une fois ces connexions identifiées, la configuration elle-même fournit le premier point de contrôle opérationnel. Les équipes de sécurité peuvent examiner les configurations des serveurs MCP pour repérer les variables codées en dur et vérifier que les emplacements d'identifiants utilisent des modèles tels que l'expansion de variables d'environnement, les prompts natifs du client, les gestionnaires de secrets ou les placeholders. Cet examen traite les éléments d'authentification là où les agents sont configurés pour atteindre d'autres systèmes et peut révéler des identifiants nécessitant une rotation côté fournisseur.

Les connexions identifiées nécessitent ensuite une gestion délibérée des accès. Les approches recommandées incluent la gestion de l'accès aux serveurs MCP via une passerelle IA ou MCP, ou l'utilisation d'un agrégateur MCP. Ces points de contrôle peuvent intégrer les relations client-serveur individuelles dans un processus commun de gestion des accès, au lieu de laisser chaque connexion dépendre de décisions de configuration séparées.

Les contrôles centralisés ont toujours besoin d'une couverture de détection, car des utilisateurs ou des équipes de développement peuvent créer des connexions sans les enregistrer. Les organisations devraient évaluer si leurs plateformes existantes de détection et réponse réseau ainsi que leurs systèmes de gestion des terminaux peuvent détecter l'utilisation non approuvée de clients et de serveurs MCP. Compte tenu de l'exposition et de la probabilité d'une adoption déjà approuvée et non approuvée, la recommandation est que les RSSI évaluent leur exposition à MCP « cette semaine ».

Cette évaluation couvre également la version du protocole exécutée dans les systèmes déployés. Les développeurs devraient utiliser la dernière version de MCP, en particulier la spécification Model Context Protocol 2026-07-28, qui ajoute des contrôles de sécurité. L'utilisation de cette spécification applique les dispositions de sécurité les plus récentes au niveau du protocole, en complément de la rotation des identifiants, de la découverte des connexions et de la gestion des accès.

Points clés à retenir pour les décideurs

• Traitez les fuites d'identifiants MCP comme un risque de gouvernance de l'IA : Les configurations MCP publiques peuvent exposer des identifiants qui donnent aux agents d'IA un accès autonome aux systèmes, aux données et à la capacité de dépense de l'entreprise. Les RSSI doivent avoir de la visibilité sur les agents qui détiennent des identités machine et sur ce à quoi ces identités peuvent accéder.
• Donnez la priorité aux identifiants longue durée et à large périmètre : Hush Security a trouvé des identifiants codés en dur dans 12 % d'environ 82 000 configurations MCP publiques, et 24 % de ces identifiants étaient à la fois sans expiration et à large périmètre. Les équipes de sécurité peuvent prioriser ces expositions pour une investigation et une remédiation immédiates.
• Gouvernez les identités et les autorisations des agents : MCP peut permettre à un logiciel d'utiliser de manière autonome des identifiants exposés, étendant le risque au-delà de la fuite initiale du secret. Les équipes de sécurité ont besoin de contrôles sur la propriété des identités d'agents, les autorisations, la surveillance et la révocation.
• Faites tourner les identifiants exposés chez le fournisseur : Supprimer un secret codé en dur de la configuration actuelle peut laisser des copies exploitables dans l'historique Git. Les équipes de développement et de sécurité doivent faire tourner les identifiants exposés et déplacer les secrets actifs vers des variables d'environnement, des gestionnaires de secrets ou d'autres mécanismes plus sûrs.
• Découvrez et contrôlez les connexions MCP : Des outils d'IA approuvés ou non approuvés peuvent déjà se connecter à des ressources d'entreprise privilégiées via MCP. Les RSSI peuvent inventorier les clients et serveurs MCP, centraliser les accès via des passerelles ou des agrégateurs, détecter les connexions non approuvées et faire évoluer les déploiements vers la dernière spécification MCP.