Votre programme CTEM ignore probablement MCP. Voici comment y remédier

Le Model Context Protocol (MCP) est le tissu conjonctif des outils d’IA modernes et est devenu discrètement l’un des angles morts les plus importants des programmes de sécurité modernes. Comme l’informatique fantôme avant elle, l’IA fantôme – en particulier en ce qui concerne le risque MCP – introduit une nouvelle classe d’expositions que les équipes de sécurité ne disposent pas des outils adéquats pour détecter et traiter. L’intégration des risques MCP dans un programme de gestion continue de l’exposition aux menaces (CTEM) peut aider les équipes de sécurité à suivre le rythme en fournissant une méthodologie structurée et l’agilité opérationnelle nécessaire pour faire apparaître les expositions MCP avant les attaquants.

La sécurité a toujours été une course entre la vitesse à laquelle la surface d’attaque augmente et la rapidité avec laquelle les défenseurs peuvent la voir. La gestion des vulnérabilités a été la première tentative sérieuse de mener cette course systématiquement. Cela a fonctionné jusqu’à ce que l’environnement devienne trop complexe et que les équipes de sécurité se retrouvent à donner la priorité à ce qui était le plus bruyant plutôt qu’à ce qui était le plus dangereux. CTEM repose sur le même instinct fondamental consistant à détecter les vulnérabilités avant les attaquants, mais reflète mieux les réalités commerciales et techniques des environnements informatiques modernes. La plupart des programmes de sécurité matures en ont déjà les bases. La question avec MCP n’est pas de savoir si CTEM s’applique. Il s’agit de savoir si la portée a été étendue pour l’inclure.

Introduit par Anthropic fin 2024, MCP fait office d’architecture de plugin pour l’IA agentique. Si votre équipe ne recherche pas, ne cartographie pas ou ne surveille pas les risques MCP, vous vous retrouvez face à un angle mort qui s’agrandit à chaque fois qu’un développeur installe un nouvel outil. MCP prend les « anciens » risques tels que les attaques de la chaîne d’approvisionnement, les informations d’identification codées en dur, l’élévation des privilèges, l’exécution de code à distance et les rend à nouveau nouveaux.

Voici comment procéder :

Shadow AI : vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir

En 2025, les chercheurs ont documenté le premier serveur MCP malveillant confirmé dans la nature. Le véhicule était un package npm appelé postmark-mcp, un outil qui aidait les développeurs à intégrer des assistants IA au service de messagerie Postmark. L’agresseur a été patient. Ils ont publié quinze versions légitimes au fil du temps, ont réalisé environ 1 500 téléchargements hebdomadaires et ont gagné une véritable confiance dans la communauté des développeurs. Ensuite, une version livrée avec une seule ligne de code injectée qui transmettait chaque e-mail sortant en BCC vers une adresse externe.

Environ 300 organisations ont été touchées avant que quiconque ne s’en aperçoive. Réinitialisations de mots de passe, factures, mémos internes, documents confidentiels – exfiltrés pendant des semaines sans déclencher une seule alerte. La tactique reflète le manuel de jeu de SolarWinds : établir d’abord la légitimité, corrompre ensuite et compter sur le fait qu’une fois qu’une chose est fiable, elle cesse d’être scrutée.

Les entreprises ont accumulé des niveaux de gouvernance pour gérer les risques liés aux logiciels tiers : examens des achats, évaluations des fournisseurs, approbations de sécurité. L’écosystème MCP n’a encore rien de tout cela. Les développeurs extraient les serveurs de npm de la même manière qu’ils extraient n’importe quelle dépendance open source : rapidement, en toute confiance, sans trop réfléchir à ce qui se passe lorsque l’outil se connecte à leur agent IA et, via lui, aux données internes. Ce n’est pas une critique ; c’est un problème de visibilité. Les problèmes de visibilité ne sont pas résolus par la politique. Ils sont résolus en connaissant ce qu’il y a dans votre environnement.

Clés sous le paillasson : informations d’identification codées en dur dans les configurations IA

En 2023, les logiciels malveillants voleurs d’informations ont récolté plus de 225 000 identifiants ChatGPT. Beaucoup étaient livrés avec des clés API que les développeurs avaient codées en dur directement dans les fichiers de configuration – non par négligence, mais par la même logique qui a toujours conduit aux raccourcis de sécurité : c’est plus rapide, cela fonctionne et les conséquences semblent abstraites jusqu’à ce qu’elles ne le soient pas.

Le scénario le plus instructif est plus simple : un développeur valide accidentellement un fichier .env de production contenant des clés API pour OpenAI, Stripe, AWS et SendGrid. Les robots automatisés le trouvent en quelques heures. Des frais de cloud frauduleux s’ensuivent. Aucun attaquant sophistiqué n’est requis : il suffit d’une erreur restée dans un référentiel suffisamment longtemps pour qu’un scanner la trouve.

MCP aggrave structurellement la situation, car les agents d’IA ont besoin d’informations d’identification pour fonctionner. Ils ont besoin de clés pour le LLM, de clés pour les services cloud et de clés pour les intégrations tierces. Ces clés doivent aller quelque part où l’agent peut les atteindre : variables d’environnement dans les fichiers de configuration, texte brut dans les fichiers d’instructions de démarque ou codées en dur dans la définition du serveur lui-même. Tout cela est une cible de texte brut statique. Les pirates n’ont pas besoin de s’introduire s’ils peuvent simplement se connecter. La question est de savoir si vos programmes d’analyse ont été pointés vers les configurations du serveur MCP, les fichiers contextuels de démarque consommés par les agents IA et les blocs de variables d’environnement où se trouvent les informations d’identification. La plupart ne l’ont pas été.

« Mode Dieu » : lorsque des agents d’IA trop privilégiés sont compromis

L’exécution d’agents IA avec des privilèges élevés est courante. En 2025, les chercheurs avaient besoin de deux CVE juste pour commencer à faire valoir leurs arguments. CVE-2025-6514, une faille d’exécution de code à distance dans le score mcp-remote 9.6 sur l’échelle CVSS, a été la première RCE complète démontrée sur un système client via une connexion MCP — déclenchée simplement par la connexion à un serveur non fiable. CVE-2025-49596, affectant le MCP Inspector d’Anthropic, a obtenu un score de 9,4 et a obtenu le même résultat grâce à un exploit de navigateur en chaîne, donnant aux attaquants un accès complet aux machines des développeurs.

Au-delà des CVE, les chercheurs ont découvert que les serveurs MCP étaient configurés avec des commandes à privilèges élevés (sudo, doas, runas) dès le départ, car les droits d’administrateur facilitaient le développement et personne ne les resserrait par la suite. Ce modèle a été documenté dans le cadre de la recherche IDEsaster menée par le chercheur en sécurité Ari Marzouk, qui a répertorié plus de 30 vulnérabilités dans Cursor, GitHub Copilot, Windsurf et autres. Les IDE d’IA avaient effectivement supprimé le logiciel de base de leur propre modèle de menace : les fonctionnalités existantes étaient considérées comme sûres car elles étaient là depuis des années, jusqu’à l’arrivée d’un agent autonome capable de les invoquer sans rien demander.

Si un agent de votre réseau est compromis, la question n’est pas de savoir s’il peut exfiltrer des données, mais plutôt s’il est autorisé à effacer un serveur ou à installer un ransomware. C’est une question de configuration, et la plupart des organisations ne connaissent pas la réponse.

Comment CTEM résout ce problème – et ce qu’il faut pour y parvenir

CTEM est le bon framework, non pas parce qu’il a été conçu pour MCP, mais parce qu’il a été conçu pour des surfaces d’attaque qui se développent plus rapidement que les équipes de sécurité ne peuvent les suivre. Les cinq phases ont chacune une application directe ici :

• Cadrage nécessite un aveu honnête : la chaîne d’outils d’IA n’est pas encore dans le champ d’application, et elle doit l’être. Cela signifie définir explicitement les postes de travail des développeurs, les environnements de codage IA et les configurations MCP comme des actifs à protéger. Cela nécessite également un alignement précoce avec les responsables de l’ingénierie, car le travail de remédiation incombe aux équipes de développement et celles-ci doivent comprendre le risque avant de s’engager.
• Découverte suit. Les serveurs MCP n’apparaissent pas dans les inventaires d’actifs traditionnels. Ils vivent dans des postes de travail de développeurs, des configurations d’outils d’IA et des packages npm installés en vingt secondes, sans ticket de modification. Les trouver signifie énumérer activement les serveurs MCP configurés et détecter les modifications entre les analyses. Un serveur qui se met à jour silencieusement est le scénario postmark-mcp qui se rejoue.
• Priorisation signifie résister à l’envie de tout signaler et d’y parvenir de manière linéaire. Le meilleur cadre est celui de l’impact de l’attaquant : que peut réellement faire quelqu’un à partir de cette exposition, et où est-ce que cela se connecte ? Les signaux de risque tels que les transports basés sur le réseau, les clés API dans les variables d’environnement ou les fichiers d’instructions et les commandes à privilèges élevés dans les définitions de serveur aident à distinguer les problèmes graves des problèmes moins urgents.
• Validation teste si les expositions signalées sont réellement exploitables dans leur contexte, en utilisant des techniques telles que la cartographie des chemins d’attaque et la simulation de violations et d’attaques pour confirmer la différence entre le risque réel et le risque théorique.
• Mobilisation est plus dur que le travail technique. Les développeurs considèrent les serveurs MCP comme une infrastructure qui accélère leur travail, et non comme un problème de sécurité. Parler de sécurité avec les développeurs se passe mieux quand ils sont concrets : voici l’outil, voici à quoi il peut accéder, voici le chemin d’attaque. La spécificité convertit les conseils en un ticket de remédiation qui est effectivement clôturé.

Rien de tout cela ne nécessite un nouveau programme, juste une extension d’un programme existant. La sécurité a rattrapé le cloud. Il rattrape désormais l’IA. La seule question est de savoir si votre programme y parvient avant un attaquant.

Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?