Avec l’adoption croissante d’agents d’IA dans les environnements d’entreprise, un nouvel enjeu de sécurité s’impose : les MCP servers protéger l’accès aux systèmes et, surtout, les secrets qu’ils rendent utilisables. Le Model Context Protocol (MCP) facilite la connexion d’un assistant à des outils externes et à des données en temps réel. En pratique, cette commodité crée un point de passage où se concentrent souvent des identifiants, des jetons et d’autres informations sensibles.
Le problème, c’est que cette couche peut devenir une porte d’entrée avant même que les équipes sécurité ne sachent qu’un serveur MCP est en cours d’exécution. Dans cet article, nous passons en revue les modes d’exposition les plus fréquents et des mesures concrètes pour réduire le risque.
Qu’est-ce que le Model Context Protocol (MCP) ?
Le Model Context Protocol (MCP) est une norme ouverte, initialement proposée par Anthropic, qui permet à des assistants IA de se connecter à des outils et à des sources de données externes. L’intérêt est simple : l’agent n’est plus limité à la connaissance « statique » du modèle, puisqu’il peut interroger des systèmes en direct.
Le rôle central revient au MCP server. Ce petit programme agit comme un intermédiaire entre l’IA et les systèmes ciblés. Il expose uniquement les actions autorisées à l’agent : lire un fichier, récupérer un enregistrement depuis une base de données, ou encore appeler une API.
Mais cet intermédiaire devient aussi l’endroit où se trouvent (ou se trouvent souvent) les « clés » nécessaires pour exécuter ces actions. Dès lors, sécuriser le serveur MCP revient à sécuriser le passage entre l’agent et des ressources critiques.
Pourquoi les secrets se retrouvent au cœur des MCP servers
Dans une configuration classique, un agent IA ne se contente pas de générer du texte : il peut agir. Pour accéder aux données internes, il lui faut des identités non humaines (par exemple des jetons d’API). Or, au niveau de l’infrastructure, ces identifiants sont habituellement stockés et utilisés par le MCP server.
Conséquence directe : si un secret fuit, l’impact peut dépasser la simple divulgation d’informations. Il peut permettre à un attaquant d’exécuter à son tour des actions sur les systèmes visés, en profitant des autorisations disponibles.
Principaux scénarios d’exposition de secrets
1) Identifiants en clair dans des fichiers de configuration
Dans de nombreux déploiements, lancer un serveur MCP implique de fournir une chaîne de configuration contenant des jetons et des clés. Si ces données sont laissées sur le disque, elles peuvent être copiées entre environnements ou, pire, accidentellement ajoutées à un dépôt Git.
Une fois qu’un attaquant parvient à atteindre le serveur, ces secrets peuvent devenir lisibles et exploitables.
2) Multiplication incontrôlée des identifiants
Sans lieu central pour gérer les secrets, chaque agent finit par « gérer ses propres » identifiants. Résultat : des doublons se retrouvent dans plusieurs fichiers de configuration et variables d’environnement (développement, préproduction, production).
Comme il n’existe pas forcément d’inventaire complet, la rotation est souvent négligée. Des secrets dispersés et stables dans le temps constituent alors autant de points d’entrée possibles pour une compromission.
3) Injection de prompts
Tout incident n’implique pas nécessairement une intrusion technique. Un attaquant peut manipuler le contenu que l’agent lit avant d’agir : document, ticket de support, page web… L’objectif est d’y dissimuler des instructions.
Quand l’agent suit ces instructions comme si elles faisaient partie des commandes légitimes, on parle d’injection de prompts. L’agent peut alors détourner l’usage de ses outils, voire divulguer des secrets qu’on lui avait pourtant confiés.
4) Droits trop larges
Pour éviter des blocages au moment de développer, les accès sont parfois accordés « large par défaut ». Si cette configuration n’est pas resserrée avant la mise en production, le MCP server peut offrir plus de portée que nécessaire.
Quand le principe du moindre privilège n’est pas appliqué, une compromission unique peut exposer beaucoup plus que ce qui était requis pour la tâche initiale.
5) Risques liés aux serveurs exposés ou non approuvés
Un autre angle de risque concerne l’écosystème : n’importe qui peut publier un serveur MCP. Se connecter à une instance non approuvée revient à introduire un maillon de chaîne d’approvisionnement potentiellement malveillant.
Des cas d’abus documentés ont illustré comment un serveur MCP téléchargé et exécuté côté client peut mener à une exploitation menant à l’exécution de commandes sur l’hôte. À partir de là, il devient possible de cibler les identifiants manipulés par le composant.
Bonnes pratiques pour sécuriser les secrets côté MCP
Le MCP déplace l’endroit où résident les secrets et modifie la manière dont ils sont accessibles. Mais la réponse doit être tout aussi rigoureuse : traiter cette couche comme un composant production capable de détenir des identifiants critiques.
Centraliser plutôt que disperser
Une mesure clé consiste à arrêter le stockage des secrets en dur et à centraliser leur gestion. L’idée est de retirer les identifiants des fichiers de configuration, des variables d’environnement et du code source, puis de les placer dans un espace géré.
À la place du « sprawl » (multiplication) des secrets, les agents peuvent récupérer ce dont ils ont besoin au moment de l’exécution, depuis une source gouvernée.
Utiliser des identifiants à durée de vie courte
Les secrets statiques et de longue durée sont particulièrement attractifs pour un attaquant : ils restent valables. Pour réduire la fenêtre d’exploitation, privilégiez des identifiants temporaires, émis à la demande et arrivant à expiration automatiquement.
Un mécanisme de rotation automatisée rend un secret compromis beaucoup moins utile après exposition.
Appliquer le moindre privilège
Donnez à chaque agent et chaque MCP server uniquement l’accès nécessaire à sa mission. Cette discipline limite l’impact d’une compromission : si un agent est abusé, il ne devrait pouvoir atteindre qu’une fraction des ressources.
Impliquer un humain pour les actions sensibles
Pour les opérations à fort impact—par exemple récupérer un secret non masqué, supprimer un enregistrement, ou toucher à l’environnement de production—préférez une validation explicite.
Ce contrôle humain joue un rôle de barrière. Il peut empêcher qu’une tentative d’injection de prompts aboutisse à une fuite ou à une action irréversible sans supervision.
Chiffrer avec une approche zero-trust
Pour aller plus loin, l’objectif est de chiffrer les secrets selon une logique zero-trust et, autant que possible, zero-knowledge. Le principe : le coffre conserve des données chiffrées, et l’accès en clair ne se produit qu’au moment exact de l’utilisation.
Dans ce modèle, une compromission d’un dépôt de secrets ne signifie pas automatiquement que l’attaquant peut lire immédiatement les valeurs.
Tracer et auditer chaque action de l’agent
Les agents agissent souvent rapidement et sans intervention directe à chaque étape. Pour la conformité et la réponse à incident, il faut pouvoir reconstituer ce qui a été consulté, à quel moment et via quel composant.
Un logging exhaustif et un audit régulier permettent de détecter des comportements anormaux et d’analyser les effets d’une attaque.
Tenir un inventaire des MCP servers
On ne peut pas protéger ce qu’on ne voit pas. Maintenir une visibilité sur les MCP servers réellement en exécution dans l’environnement réduit le risque d’avoir des identités « fantômes » non revues.
Un inventaire aide aussi à mettre en place des contrôles cohérents (droits, rotation, supervision) et à mieux cibler les efforts de durcissement.
Repenser la gestion des secrets pour les agents IA
Le MCP ajoute une couche supplémentaire entre les agents IA et la plupart des systèmes qu’une entreprise cherche à sécuriser. Comme cette couche contient des identifiants qui rendent l’action possible, elle doit bénéficier du même niveau d’exigence que n’importe quel système manipulant des secrets en production.
En pratique, cela signifie centraliser la gestion des identifiants, contrôler finement ce que chaque agent peut atteindre et réduire la probabilité qu’un secret soit exposé en clair. Des outils de gestion de secrets peuvent aussi aider à masquer les valeurs par défaut et à exiger une confirmation avant divulgation.
Conclusion
Les MCP servers offrent une capacité puissante aux agents IA : accéder à des outils et à des données qui alimentent des tâches utiles. Mais ils concentrent aussi les éléments sensibles nécessaires à l’action—jetons, clés et credentials. Pour sécuriser les MCP servers protéger, il faut traiter cette couche comme une surface d’attaque à part entière : centralisation des secrets, durée de vie courte, moindre privilège, validation humaine sur les actions critiques, chiffrement renforcé, audit et inventaire.
En adoptant ces pratiques, vous réduisez fortement le risque qu’une exposition silencieuse devienne une brèche majeure—avant que les équipes sécurité n’aient eu le temps d’intervenir.
Source: https://thehackernews.com/2026/08/how-mcp-servers-can-expose-enterprise.html
