Les agents IA passent du stade expérimental aux flux de travail en production, et le Model Context Protocol (MCP) devient la couche de connexion permettant à ces agents d'accéder aux données, applications, API, dépôts et outils d'automatisation de l'entreprise. Cela rend le MCP puissant, mais aussi critique pour la sécurité. À mesure que les organisations adoptent l'IA agentique, elles doivent comprendre non seulement comment le MCP améliore la connectivité, mais aussi comment il crée de nouveaux défis en matière de visibilité, de gouvernance et de surface d'attaque.
Qu'est-ce que le MCP et pourquoi est-ce important pour l'IA en entreprise ?
Le Model Context Protocol est un standard ouvert qui offre aux systèmes d'IA un moyen cohérent de découvrir et d'interagir avec des outils, des sources de données et des systèmes métier externes. Pour le définir simplement : le MCP est un plan de contrôle standardisé permettant de connecter les agents IA au contexte et aux actions de l'entreprise.
C'est essentiel car l'IA en entreprise n'est utile que lorsqu'elle peut atteindre les systèmes où le travail est réellement effectué. Un agent de support peut avoir besoin d'interroger une plateforme de billetterie. Un assistant de développement peut devoir inspecter un dépôt de code source. Un assistant financier peut avoir besoin de récupérer des enregistrements de base de données. Un agent opérationnel peut devoir invoquer une API interne ou lancer un flux de travail.
Le MCP fonctionne comme une couche d'abstraction un-à-plusieurs. Au lieu de créer des intégrations distinctes pour chaque application et système d'IA, les organisations peuvent exposer des outils, des ressources et des invites via des serveurs MCP. Les clients IA peuvent alors appeler des API, interroger des bases de données, lire des fichiers, récupérer du contexte et déclencher des flux de travail via un protocole partagé.
L'adoption a été rapide. Anthropic a introduit le MCP en novembre 2024 en tant que standard ouvert pour connecter les assistants IA aux systèmes où résident les données. Dès 2025, OpenAI, Microsoft et Google avaient annoncé ou documenté la prise en charge du MCP dans leurs produits et services.
En décembre 2025, Anthropic a fait don du MCP à l'Agentic AI Foundation, un fonds dirigé par la Linux Foundation et cofondé par Anthropic, Block et OpenAI, avec le soutien de Google, Microsoft, AWS, Cloudflare, Bloomberg et d'autres. Le MCP est désormais largement considéré comme le standard par défaut émergent pour la connectivité de l'IA agentique.
Comment l'architecture MCP crée des vulnérabilités de sécurité
Le MCP utilise une architecture client-serveur. Une application IA agit comme hôte et exécute un ou plusieurs clients MCP. Ces clients se connectent à des serveurs MCP, qui exposent des outils, des ressources et des invites. Un serveur peut fournir un accès à un dépôt Git, une base de données, une application SaaS, un compte cloud ou une API interne.
Cela ressemble à un modèle d'API traditionnel, mais le MCP modifie le schéma d'interaction. Les serveurs MCP ne se contentent pas de renvoyer des données statiques. Ils décrivent les outils disponibles aux systèmes d'IA, influencent le contexte de l'agent et exécutent des actions pour le compte des clients connectés. Dans les flux de travail agentiques, le modèle peut décider quand et comment invoquer ces outils en fonction des instructions et du contexte.
Cela crée des vecteurs d'attaque qui diffèrent des risques liés aux API traditionnelles. Un utilisateur donne une instruction, un agent IA l'interprète, un client MCP sélectionne un outil, un serveur MCP exécute une action et les systèmes en aval répondent. Chaque transfert peut introduire une faille de politique, de validation ou de visibilité.
Les serveurs MCP sont également souvent des intermédiaires privilégiés. Un seul serveur peut se situer entre un agent IA et des gestionnaires de code source, des bases de données, des services cloud, des API internes, des systèmes de fichiers ou des outils d'observabilité. Si ce serveur dispose de privilèges excessifs ou est mal sécurisé, il devient une cible de grande valeur.
Le protocole a été conçu pour être flexible, ce qui a favorisé son adoption. Mais cela signifie aussi que de nombreux contrôles sont laissés à la discrétion des implémenteurs. L'authentification, l'autorisation, la validation des entrées, l'approbation des outils, la gestion des sessions, la journalisation et l'application des politiques ne sont pas uniformément imposées au niveau du protocole. Deux serveurs MCP effectuant des fonctions similaires peuvent donc présenter des postures de sécurité totalement différentes.
Principaux risques de sécurité MCP auxquels les organisations sont confrontées aujourd'hui
Les risques de sécurité liés au MCP couvrent l'identité, l'autorisation, l'intégrité des invites, la gestion des sessions, la gestion du contexte et l'exposition de la chaîne d'approvisionnement logicielle. Quatre domaines méritent une attention immédiate.
Le premier est le contrôle d'accès. Le MCP n'exige pas d'authentification ou de contrôle d'accès basé sur les rôles au niveau du protocole. Des déploiements robustes peuvent ajouter ces contrôles, mais les premières implémentations peuvent reposer sur des hypothèses de confiance locale, des identifiants partagés ou un accès trop permissif aux outils. Si un serveur MCP peut lire des dépôts, interroger des bases de données ou appeler des API internes, un contrôle d'accès faible au niveau de la couche MCP peut se traduire par un contrôle d'accès faible sur l'ensemble des systèmes connectés.
Le second est l'empoisonnement des outils et injection de prompt. Dans une attaque par empoisonnement d'outil, un serveur MCP malveillant ou compromis intègre des instructions cachées dans les descriptions d'outils, les métadonnées, les invites ou les sorties. Un agent IA peut interpréter ces instructions comme un contexte légitime et effectuer des actions non souhaitées, telles que la fuite de données, l'ignorance des consignes de sécurité ou la transmission de secrets à un autre outil. L'injection de prompt crée un risque connexe lorsque les agents traitent du contenu non fiable provenant de tickets, de documents, de dépôts, de pages web ou de sorties d'outils.
Le troisième point concerne la vulnérabilité des jetons et des sessions. De nombreux déploiements MCP dépendent de jetons porteurs, de permissions déléguées, de flux OAuth ou de modèles de transfert de jetons. Des jetons à longue durée de vie, des portées trop larges, une révocation inefficace et une gestion médiocre du cycle de vie des sessions peuvent permettre aux attaquants de passer de la couche MCP aux systèmes en aval. MCP crée également des opportunités pour des attaques de type « député confus », où un composant de confiance est manipulé pour utiliser son autorité d'une manière non prévue par l'utilisateur.
Le quatrième point est la sérialisation non sécurisée du contexte. MCP échange couramment des objets structurés via JSON-RPC. Sans une application stricte des schémas et une isolation adéquate, les charges utiles malformées, la désérialisation non sécurisée, le parcours de répertoire, l'injection et les risques d'exécution de commandes peuvent atteindre des outils ou des environnements d'exécution privilégiés.
Le problème de la découverte et de l'inventaire des serveurs MCP
Les serveurs MCP deviennent une nouvelle forme de shadow IT. Ils sont faciles à déployer pour les développeurs, souvent construits avec des frameworks open source, et peuvent s'exécuter sur des postes de travail, dans des conteneurs, au sein de systèmes CI/CD ou dans des environnements cloud. Un développeur peut rapidement connecter un assistant IA à des fichiers, des dépôts, des identifiants, des journaux, des bases de données ou des API internes sans passer par un processus formel de revue de sécurité.
Cela crée un problème de visibilité. Sans découverte continue des serveurs MCP, les équipes de sécurité ne peuvent pas répondre à des questions fondamentales telles que : quels serveurs existent ? Où sont-ils exécutés ? Qui les possède ? Quels outils exposent-ils ? Quels agents les utilisent ? À quelles données peuvent-ils accéder ? Sont-ils authentifiés ? Sont-ils autorisés ? Les permissions ont-elles été modifiées ?
Un audit ponctuel ne suffira pas. Les environnements MCP évoluent à mesure que les développeurs testent des frameworks, ajoutent des outils, mettent à jour des identifiants ou étendent les permissions. Les équipes de sécurité ont besoin d'un inventaire en temps réel qui capture l'emplacement, le propriétaire, l'exposition des outils, le statut d'authentification, la portée d'accès, le comportement à l'exécution et le statut d'autorisation sur l'ensemble des terminaux et des environnements cloud.
Cela devrait sembler familier aux équipes ayant déjà géré des API fantômes : points de terminaison inconnus, propriété floue, exposition de données non documentée et contrôles incohérents. Les serveurs MCP posent un défi similaire, mais avec une complication supplémentaire. Ils n'exposent pas seulement des données aux applications. Ils exposent des capacités à des agents IA capables de raisonner, de choisir des outils et d'initier des actions.
Incidents de sécurité MCP réels illustrant le risque
MCP est encore relativement récent, mais des recherches documentées montrent déjà pourquoi les équipes de sécurité ont besoin de contrôles avant tout déploiement à grande échelle.
Des chercheurs ont démontré des attaques par injection de paramètres d'outils contre des agents MCP open source, montrant comment des entrées non assainies peuvent exposer des données sensibles du serveur ou influencer l'exécution des outils. Ces cas mettent en évidence deux modes de défaillance courants : les entrées sont jugées fiables trop tôt et la journalisation est insuffisante pour reconstruire les événements a posteriori.
Les scénarios MCP liés à GitHub ont également montré le danger des permissions excessives sur les dépôts. Dans une catégorie d'attaques, un outil connecté via MCP disposant d'un accès étendu aux dépôts pouvait lire le contenu d'un dépôt privé et l'écrire dans un dépôt public sans que l'utilisateur ne comprenne pleinement le cheminement de l'action. Le problème réside dans la frontière floue entre l'intention de l'utilisateur, les permissions de l'outil et les actions API en aval.
La vulnérabilité de l'inspecteur MCP d'Anthropic a constitué un autre avertissement. L'inspecteur MCP est un outil de développement destiné au test et au débogage des serveurs MCP. En 2025, des chercheurs ont signalé la CVE-2025-49596, une vulnérabilité critique d'exécution de code à distance impliquant des attaques basées sur le navigateur contre les environnements de développement locaux. Les rapports décrivaient comment un site web malveillant pouvait déclencher des commandes sur la machine d'un développeur sous certaines conditions, ce qui a conduit à un correctif dans la version 0.14.1. La leçon pour les entreprises est directe : même les outils MCP fournis par les éditeurs nécessitent une revue de sécurité, une gestion des versions et une utilisation contrôlée.
Bonnes pratiques de sécurité MCP pour le déploiement en entreprise
Les organisations doivent traiter MCP comme une infrastructure de connectivité de production, et non comme une commodité pour les développeurs. La première exigence est l'authentification et l'autorisation pour chaque interaction MCP. Les serveurs MCP non authentifiés ne doivent pas avoir accès à des outils, des données ou des flux de travail sensibles. Lorsque OAuth est utilisé, suivez les recommandations d'OAuth 2.1, imposez un consentement explicite par client, restreignez les portées, liez les jetons aux destinataires prévus et évitez tout transfert de jeton inutile.
Le principe du moindre privilège doit s'appliquer à chaque niveau : utilisateur, agent, client, serveur, outil et système aval. Un serveur conçu pour lire de la documentation ne devrait pas avoir d'accès en écriture aux dépôts de code source. Un serveur utilisé pour l'analyse de données ne devrait pas être en mesure de modifier l'infrastructure cloud. Les autorisations des outils doivent être réexaminées à chaque mise à jour des serveurs ou ajout de nouvelles fonctionnalités.
Utilisez des environnements isolés (sandbox) pour les serveurs MCP afin de limiter l'impact des traversées de répertoires, des injections de commandes, de l'exécution de code arbitraire, de l'élévation de privilèges et de l'épuisement des ressources. Les limites du système de fichiers, l'isolation des conteneurs, les contraintes d'exécution et le contrôle des flux réseau sortants permettent de réduire le rayon d'action d'une éventuelle compromission.
Une validation stricte du schéma JSON-RPC doit être appliquée avant que les requêtes n'atteignent les environnements d'exécution. Les paramètres des outils doivent être assainis, les sorties doivent être traitées comme non fiables et la désérialisation ne doit avoir lieu que dans des contextes contrôlés.
La journalisation complète des audits est également essentielle. Les équipes de sécurité ont besoin d'une séquence d'activités traçable sur l'ensemble des sessions, incluant l'initiateur de la requête, les agents et clients impliqués, le serveur ayant reçu l'appel, l'outil invoqué, la décision d'autorisation prise, le système aval sollicité et toute violation éventuelle du contrôle d'accès basé sur les rôles (RBAC). Les journaux utiles doivent inclure les données d'en-tête HTTP pertinentes, les événements d'autorisation, les enregistrements d'exécution des outils, les identifiants de session et les résultats anormaux.
Enfin, évaluez les serveurs MCP tiers avant toute utilisation en production. Les serveurs issus de la communauté doivent être examinés au même titre que les paquets tiers, les images de conteneurs ou les dépendances open source. Examinez le code source lorsque cela est possible, recherchez les comportements malveillants, comprenez les autorisations requises, validez le fonctionnement de l'authentification et effectuez des tests dans un environnement hors production avant de les connecter à des systèmes sensibles.
Mise en place d'un programme de gouvernance MCP
La sécurité MCP ne peut reposer sur la seule discipline des développeurs. Les entreprises ont besoin d'une gouvernance qui fasse de l'adoption sécurisée la norme par défaut.
Commencez par la découverte. Les équipes de sécurité doivent disposer d'un inventaire complet des serveurs MCP sur les terminaux, les postes de travail des développeurs, les instances cloud, les conteneurs, les systèmes CI/CD et l'infrastructure de production. Une fois identifié, chaque serveur doit être classé par niveau de risque en fonction de la sensibilité des données, des outils exposés, de la posture d'authentification, de l'étendue des accès, de l'exposition externe, de l'importance critique pour l'activité et du statut d'approbation.
Des contrôles doivent ensuite être appliqués en fonction du risque. Les serveurs expérimentaux à faible risque peuvent nécessiter des garde-fous de base et des politiques d'expiration. Les serveurs à haut risque peuvent exiger une authentification forte, une autorisation stricte, une isolation (sandboxing), des flux d'approbation, une surveillance continue et une gestion formelle des changements.
La surveillance continue permet de maintenir le programme à jour. Elle doit détecter les nouveaux serveurs MCP en temps quasi réel, distinguer les déploiements approuvés de ceux qui ne le sont pas, identifier les changements dans l'exposition des outils et signaler tout comportement suggérant une utilisation abusive ou une compromission.
La gouvernance MCP doit également être intégrée aux programmes de sécurité existants de l'entreprise. Les équipes IAM doivent comprendre comment les utilisateurs, les agents, les clients et les serveurs sont autorisés. Les équipes EDR doivent pouvoir visualiser les outils MCP sur les terminaux. Les équipes de sécurité cloud doivent suivre les serveurs MCP dans les environnements cloud. Les équipes de sécurité des API doivent surveiller les API aval appelées par les agents via MCP. Les équipes SIEM et de réponse aux incidents ont besoin d'une télémétrie suffisante pour reconstituer les activités pilotées par les agents.
C'est ici que la sécurité MCP rejoint directement la sécurité des API. Les agents IA génèrent de la valeur métier en appelant des outils, des API, des bases de données et des flux de travail. MCP se situe au cœur de ce parcours. Sa sécurisation nécessite une visibilité à la fois sur la couche MCP et sur les API et systèmes qu'elle atteint.
La sécurité MCP commence par la visibilité
Chaque changement technologique majeur crée une nouvelle infrastructure que les équipes de sécurité finissent par devoir gouverner. Pour l'adoption du cloud, il s'agissait des comptes cloud non gérés. Pour les API, c'était les API fantômes. Pour les agents IA, les serveurs MCP deviennent rapidement le prochain défi en matière de visibilité.
Le risque ne vient pas de MCP lui-même. Le protocole résout un problème réel en offrant aux systèmes d'IA un moyen standardisé d'interagir avec les applications, les sources de données et les flux de travail de l'entreprise. Le défi réside dans le fait que les organisations déploient des serveurs MCP beaucoup plus rapidement qu'elles ne mettent en place des contrôles autour de ceux-ci.
Les équipes de sécurité ne peuvent pas protéger ce qu'elles ne voient pas. Avant de pouvoir évaluer les modèles d'authentification, examiner les autorisations ou détecter les tentatives d'empoisonnement d'outils, elles doivent savoir quels serveurs MCP existent, quels systèmes ces serveurs peuvent atteindre et quels agents IA les utilisent.
À mesure que les agents IA s'intègrent aux processus métier, les serveurs MCP ressembleront de plus en plus aux API : une infrastructure de connectivité critique nécessitant une découverte, une surveillance et une gouvernance continues. Les organisations qui assurent cette visibilité dès maintenant seront bien mieux armées que celles qui tenteront de sécuriser un écosystème MCP dont elles ignoraient l'existence. Obtenir une évaluation de surface pour identifier chaque serveur MCP de votre infrastructure IA.
Questions fréquentes sur la sécurité MCP
En quoi la sécurité MCP diffère-t-elle de la sécurité API classique ?
La sécurité API traditionnelle se concentre sur des interactions client-serveur prévisibles. Le protocole MCP ajoute une couche de décision IA, la découverte dynamique d'outils, une autorité déléguée et un contexte capable d'influencer le comportement des agents. Cela introduit des risques tels que l'empoisonnement d'outils, l'injection de prompts, les attaques par député confus et les actions non intentionnelles des agents.
Comment identifier tous les serveurs MCP en cours d'exécution dans mon organisation ?
Utilisez une découverte continue sur les terminaux, les environnements cloud, les postes de travail des développeurs, les conteneurs, les systèmes CI/CD et l'infrastructure de production. L'inventaire doit consigner l'emplacement, le propriétaire, les outils exposés, le statut d'authentification, les systèmes connectés, la portée des accès et le statut de validation.
Qu'est-ce que l'empoisonnement d'outils dans MCP et comment cela fonctionne-t-il ?
L'empoisonnement d'outils survient lorsqu'un serveur MCP malveillant ou compromis dissimule des instructions dans les descriptions d'outils, les métadonnées, les prompts ou les sorties. Un agent IA peut interpréter ces instructions comme un contexte légitime et effectuer des actions non souhaitées.
Le protocole MCP exige-t-il une authentification par défaut ?
Non. Le protocole MCP n'impose ni authentification ni contrôle d'accès basé sur les rôles (RBAC) au niveau du protocole. Les organisations doivent mettre en œuvre des contrôles d'identité, d'autorisation, de consentement, de jetons et de politiques pour tout serveur MCP connecté à des données ou des actions sensibles.
Qu'est-ce qu'une attaque par député confus dans MCP et comment puis-je la prévenir ?
Une attaque par député confus se produit lorsqu'un composant MCP de confiance utilise son autorité d'une manière non prévue par l'utilisateur. Prévenez-la grâce à un consentement explicite, des portées OAuth restreintes, des jetons liés à l'audience, des vérifications d'autorisation par outil et des décisions de politique prenant en compte l'utilisateur, l'agent, le client, le serveur, l'outil et l'action demandée.
Comment évaluer un serveur MCP tiers avant de l'utiliser en production ?
Évaluez-le comme vous le feriez pour un package tiers, une image de conteneur ou une dépendance open source. Examinez le code source si possible, analysez la présence de code malveillant, comprenez les autorisations requises, validez le comportement d'authentification, testez dans un environnement hors production et surveillez son comportement avant toute connexion à des systèmes sensibles.