Réserver une démo →
← Tous les insights AI News

Vos serveurs MCP détiennent les clés. Qui a le fichier de configuration ?

Vos serveurs MCP détiennent les clés. Qui a le fichier de configuration ?

Si quelqu’un dans votre équipe a branché un assistant IA sur quelque chose de réel cette année, il y a de bonnes chances qu’un serveur MCP tourne quelque part dans votre infrastructure. Il a peut-être été monté un après-midi par la personne qui avait besoin que l’assistant atteigne une base de données. Et il tourne probablement encore.

Ce serveur détient des identifiants. Une analyse de risques publiée le 17 août 2026 décrit ce qui arrive quand personne ne le traite comme ce qu’il est devenu : une frontière de sécurité.

Ce qu’est ce serveur, exactement

Le Model Context Protocol est une norme ouverte, présentée à l’origine par Anthropic, qui permet aux assistants IA de se connecter à des outils et des données externes. Au lieu de se limiter à ce que le modèle sait déjà, un agent peut aller chercher un enregistrement, ouvrir un fichier ou appeler une API.

La pièce qui rend cela possible est le serveur MCP : un petit programme placé entre l’assistant et le système qu’il veut atteindre, qui expose les actions précises que l’agent a le droit d’exécuter.

Et c’est exactement là que le risque se concentre. Pour agir sur un système, le serveur a besoin des identifiants de ce système. Selon l’analyse, le serveur « détient généralement les clés de tout ce qu’il touche : identifiants, clés de comptes de service, jetons d’API et autres secrets ».

Le déplacement qui compte : les agents ne produisent plus seulement des réponses, ils agissent. Un secret qui fuit d’un serveur MCP donne plus que des données. Il donne à un attaquant la capacité d’agir dessus.

Cinq façons dont les secrets sortent

Identifiants en clair dans les fichiers de configuration. Mettre un serveur en route consiste souvent à coller une chaîne de configuration qui contient les identifiants eux-mêmes. Ce fichier reste sur le disque, se copie d’une machine à l’autre et finit parfois dans un dépôt.

Identifiants éparpillés sur des serveurs sans gouvernance. Sans endroit central pour ranger les secrets, chaque agent gère les siens. Les mêmes clés se répartissent entre fichiers de configuration et variables d’environnement, dupliquées en développement, préproduction et production. Comme personne n’a l’inventaire complet, elles sont rarement renouvelées et restent valables indéfiniment.

Injection de prompt. Les agents lisent le matériau qu’on leur donne et agissent dessus, ce qui fait de tout texte qu’ils traitent un canal d’instructions possible.

Droits trop larges. Un serveur monté vite reçoit en général un accès large, parce que le restreindre prend du temps et casse des choses pendant l’installation.

Serveurs exposés. L’analyse note que cette exposition apparaît souvent avant que les équipes de sécurité sachent seulement que le serveur existe.

L’exemple nommé mérite d’être retenu : mcp-remote, décrit dans l’analyse comme « un proxy OAuth téléchargé plus de 400 000 fois qui s’exécute sur la machine cliente », par lequel « un serveur malveillant pourrait déclencher une injection de commandes système ». C’est CVE-2025-6514.

Ce que ce chiffre est, et ce qu’il n’est pas

Quatre cent mille est un nombre de téléchargements pour un seul outil proxy. Ce n’est pas un décompte d’installations vulnérables, et l’analyse n’en donne aucun.

La distinction pèse plus lourd qu’il n’y paraît, car le chiffre de téléchargements est le plus facile à saisir de toute l’histoire et le moins parlant. Personne n’a publié combien de serveurs MCP sont exposés. Si ce chiffre vous tombe sous les yeux quelque part, demandez d’où il vient.

Les cinq contre-mesures, telles qu’elles sont écrites

L’analyse en énumère cinq, et elles se lisent comme une liste de vérification plutôt que comme une stratégie :

Rien de tout cela n’est une pensée neuve en sécurité. C’est justement le sujet. Ce sont les pratiques déjà standard pour les identifiants de production, appliquées à une classe de serveurs souvent montés en dehors du processus qui les aurait imposées.

La question gênante du lundi

Quiconque exploite des outils d’agents peut parcourir cette liste en un après-midi. La valeur est dans l’inventaire.

Commencez par la question que l’analyse suggère sans la poser : est-ce que quelqu’un possède une liste des serveurs MCP en fonctionnement, de qui les a montés et de ce que chacun peut atteindre ? Dans beaucoup d’organisations, cette liste n’existe pas, parce que chaque serveur a été ajouté pour résoudre le problème d’une personne, et qu’aucun de ces ajouts n’a ressemblé à de l’infrastructure sur le moment.

La deuxième question découle de la première. Pour chaque serveur de cette liste, que pourrait faire un attaquant avec ce qu’il détient, au-delà de le lire ? Un agent qui écrit dans un système de tickets, une chaîne de déploiement ou une base clients n’est pas la même exposition qu’un agent qui se contente d’aller chercher des documents.

La troisième porte sur le matériau que lisent vos agents. L’injection de prompt fonctionne parce que les agents agissent sur le texte qu’on leur donne, ce qui range chaque document, chaque page et chaque message qu’un agent traite dans la surface d’attaque. La plupart des organisations publient et absorbent énormément de texte sans jamais se demander ce qu’un lecteur automatique en ferait.

Aucune de ces questions n’exige une équipe de sécurité. Elles exigent que quelqu’un écrive la liste.

Sources

Newcomer AI-Visibility Tracker · known from