Les équipes de sécurité me demandent sans cesse ce que recouvre réellement la sécurité MCP. Pas dans le sens « veuillez définir cet acronyme ». Dans le sens « nous avons trouvé trois serveurs MCP qui tournent sur des ordinateurs portables de développeurs et personne ne sait à qui ils appartiennent ». Voilà la vraie question. Et elle diffère de celles auxquelles la plupart des guides de sécurité des API sont conçus pour répondre.
La sécurité MCP n'est pas la sécurité des API sous un nouveau nom. Le protocole crée une relation de confiance entre les agents IA et les systèmes de production que la plupart des contrôles existants n'ont jamais été conçus pour inspecter. Une passerelle API standard surveille le périmètre. MCP remet à un agent IA les clés de ce qui se trouve à l'intérieur, puis vous demande de définir la gouvernance plus tard.
C'est ce que les équipes découvrent trop tard.
La surface d'attaque que personne n'avait budgétée
- MCP crée un canal de confiance bidirectionnel entre les agents IA et les systèmes internes, que les passerelles API standard n'inspectent pas.
- 53 % des serveurs MCP utilisent des secrets statiques de longue durée — exactement le type d'identifiants qui simplifie les compromissions de chaîne d'approvisionnement.
- Le détournement au niveau du registre est possible sans aucune vulnérabilité au niveau du code ; les métadonnées seules suffisent.
- Un LLM renforcé et des systèmes sous-jacents renforcés vous laissent tout de même exposé si la couche des serveurs MCP n'est pas maîtrisée.
- Les vulnérabilités classiques s'appliquent à grande échelle : 43 % d'injection de commandes et 22 % de traversée de chemins dans les implémentations testées.
Ce que signifie réellement la sécurité MCP
La sécurité MCP couvre les contrôles, protections et mécanismes de supervision appliqués aux hôtes, serveurs et registres MCP afin d'empêcher l'exposition de données, l'exécution non autorisée d'outils et les abus au niveau du protocole. Cette définition semble maîtrisable jusqu'à ce que vous examiniez ce qu'elle doit couvrir en pratique.
La sécurité API standard protège une frontière requête/réponse. Vous authentifiez à la périphérie, vous validez les entrées, vous journalisez ce qui traverse la frontière. MCP fait quelque chose de structurellement différent. Il crée une relation de confiance bidirectionnelle entre un agent IA et les systèmes auxquels il se connecte : l'agent ne se contente donc pas d'interroger une ressource, il peut appeler des outils, lire des fichiers, exécuter des commandes et enchaîner ces actions sur plusieurs systèmes connectés. L'agent IA se trouve à l'intérieur du périmètre. Le serveur agit comme un pont.
Ce pont est précisément ce que la plupart des passerelles API ne sont pas conçues pour inspecter. Elles peuvent constater qu'une requête a eu lieu. Elles ne peuvent généralement pas voir ce qui a été demandé à l'agent IA, quel outil il a décidé d'appeler, ni si la description de l'outil à laquelle il s'est fié a été altérée en amont. La surface d'attaque s'étend à la couche protocolaire, au registre dans lequel les serveurs sont découverts et à l'environnement hôte dans lequel l'agent s'exécute. Aucune de ces couches n'existe dans une intégration API conventionnelle.
Cette distinction est importante, car les équipes qui traitent MCP comme « une simple intégration supplémentaire » appliquent les mauvais contrôles, auditent les mauvais journaux et passent à côté des mauvaises défaillances — généralement après que des données ont déjà été déplacées alors qu'elles n'auraient pas dû l'être.
Comment fonctionne MCP et où se situe la frontière de confiance
Le Model Context Protocol comporte trois composants, et chacun présente un problème distinct de frontière de confiance. Les comprendre séparément n'a rien d'académique. C'est la différence entre savoir où placer les contrôles et les installer au mauvais endroit.
L'hôte est l'environnement dans lequel l'agent IA s'exécute réellement. Un IDE tel que Claude Desktop ou Cursor est un hôte. Une plateforme d'orchestration, un exécuteur de pipeline agentique ou une application personnalisée intégrant un modèle IA le sont également. L'hôte décide quels serveurs l'agent peut atteindre, gère la manière dont le contexte de l'agent est construit et détermine en définitive le rayon d'impact en cas de problème. Un hôte compromis ou mal configuré n'expose pas seulement un outil. Il expose tout ce que l'agent peut voir depuis cet environnement.
Le client est le connecteur au niveau du protocole. Il gère la communication effective entre l'hôte et un serveur MCP spécifique : initialisation des sessions, envoi des requêtes, réception des réponses des outils. Le client traduit l'intention d'un agent en appel réseau concret.
Le serveur expose les outils, ressources et prompts à l'agent. C'est le composant le plus proche de vos systèmes réels — vos bases de données, vos référentiels de code source, vos API cloud. Lorsque l'agent appelle un outil, le serveur l'exécute. Cette exécution peut lire des fichiers, déclencher des pipelines CI/CD, lancer des requêtes ou appeler des API en aval selon ce que le serveur expose.
L'important est que ces composants forment une chaîne de confiance déléguée. L'hôte fait confiance au client. Le client fait confiance au serveur. Le serveur fait confiance aux définitions des outils qu'il expose. Un attaquant capable d'influencer n'importe quel maillon de cette chaîne peut influencer le comportement de l'agent — non pas en attaquant directement le LLM, mais en manipulant l'environnement dans lequel le LLM opère.
Hôte MCP et client MCP : ce que contrôle chaque composant
Les équipes confondent constamment ces deux éléments. J'ai vu des architectes sécurité définir des contrôles pour la couche client parce que l'activité réseau y a lieu, tout en ignorant complètement que c'est l'hôte qui définit réellement les autorisations de l'agent.
L'hôte MCP contrôle l'environnement d'exécution global. Il définit les serveurs auxquels l'agent peut se connecter, gère la configuration locale des serveurs MCP et détermine le contexte reçu par l'agent. C'est au niveau de l'hôte que le périmètre de sécurité doit d'abord être établi, car il régit l'ensemble de l'espace d'action de l'agent. Un hôte mal configuré implique un rayon d'impact mal configuré.
Le client MCP envoie des requêtes au niveau du protocole à un serveur spécifique. C'est un connecteur, pas une autorité de gouvernance. Le client ne décide pas de ce que l'agent est autorisé à faire — c'est le rôle de l'hôte. Mais le client établit bien la session, gère l'authentification et prend en charge la couche de transport pour chaque connexion au serveur. Il s'agit d'un point de contrôle plus restreint que ce que la plupart des équipes imaginent lorsqu'elles entendent le mot « client ».
MCP fonctionne avec ces deux composants qui interviennent successivement. L'hôte définit l'environnement ; le client y exécute les actions. Ne pas les distinguer conduit à placer les contrôles d'accès au mauvais endroit — exactement là où commencent la plupart des mauvaises configurations.
Où s'insère le serveur MCP dans un pipeline IA agentique
Le serveur MCP est la cible à plus forte valeur dans le pipeline. Tout ce que l'agent IA peut réellement faire passe par lui. Un ou plusieurs serveurs MCP exposent les outils, ressources et prompts que l'agent peut appeler — et, dans ce contexte, les « outils » correspondent à un accès réel aux systèmes : lire un fichier, interroger une base de données, pousser du code, appeler une API externe, envoyer une notification.
Lorsqu'un agent IA appelle le serveur MCP, il ne pose pas une question. Il demande l'exécution d'une action. La réponse du serveur façonne ce que l'agent fait ensuite. Les outils disponibles sont répertoriés dans le manifeste du serveur, et l'agent les sélectionne selon ses instructions et son contexte. C'est pourquoi la sécurité des serveurs MCP est plus importante qu'elle ne peut le sembler de l'extérieur : contrôler le serveur, c'est contrôler les actions de l'agent. Compromettre le serveur, c'est transformer le pipeline IA agentique en mécanisme d'exécution de tout ce que l'attaquant souhaite lancer.
C'est généralement là que débute l'incident.
Les risques MCP que vous rencontrerez réellement
Les risques d'un déploiement MCP ne sont pas des cas limites hypothétiques décrits par des chercheurs en quête de conférences. Ils sont mesurables, reproductibles, et plusieurs sont présents dans la majorité des implémentations réelles. Le paysage des menaces se répartit en plusieurs catégories distinctes, qui exigent des défenses différentes.
Empoisonnement du contexte et injection indirecte de prompts via MCP
Ce risque surprend les équipes, car il ne ressemble pas à une vulnérabilité vue de l'extérieur. Un acteur malveillant n'a pas besoin d'attaquer le modèle IA ni la base de données sous-jacente. Il lui suffit d'introduire du contenu malveillant dans la fenêtre de contexte du modèle via MCP — au moyen d'un document lu par l'agent, d'une réponse API qu'il reçoit ou d'une sortie d'outil qu'il traite.
Une fois ce contenu présent dans le contexte, il peut transmettre au modèle des instructions qui remplacent ou redirigent son comportement. L'utilisateur ne le voit pas. L'interface visible paraît normale. Pourtant, l'agent peut désormais exfiltrer des identifiants, envoyer des données vers un endpoint contrôlé par un attaquant ou effectuer des actions que l'utilisateur n'a jamais autorisées — uniquement parce qu'une entrée externe de l'environnement MCP le lui a demandé. Invariant Labs a démontré cette catégorie d'attaque à l'aide d'exemples fonctionnels contre de vrais déploiements MCP. La défense ne consiste pas à faire davantage confiance au modèle. Elle consiste à isoler le contenu externe non fiable afin qu'il n'arrive jamais dans le contexte du modèle comme une entrée porteuse d'instructions.
Injection de commandes, traversée de chemins et SSRF : des vulnérabilités classiques toujours applicables
Une idée reçue récurrente veut que le principal enjeu de sécurité de MCP soit l'injection de prompts — un problème d'IA qui nécessiterait des défenses IA. Les données disent le contraire.
Une étude empirique des implémentations MCP a révélé que 43 % des serveurs testés présentaient des failles d'injection de commandes, 22 % autorisaient la traversée de chemins ou la lecture arbitraire de fichiers, et 30 % comportaient des vulnérabilités SSRF. Il s'agit de faiblesses traditionnelles des applications web qui apparaissent dans les outils IA à des taux qui seraient préoccupants dans n'importe quel autre contexte. Elles s'appliquent ici parce que les serveurs MCP acceptent des entrées, les transmettent à des commandes système et à des opérations sur les fichiers, puis effectuent des requêtes réseau sortantes — tous les schémas qui produisent ces vulnérabilités dans les applications conventionnelles.
Le cadre MCP ne modifie pas les mécanismes sous-jacents. Un serveur qui transmet une entrée non nettoyée à une commande shell est vulnérable à l'injection de commandes, que cette entrée ait été générée par un LLM ou saisie par un humain. Ce qui change avec MCP, c'est la portée de l'attaquant : il peut influencer l'entrée sans jamais toucher directement le serveur, en manipulant ce que l'agent IA a reçu l'instruction d'envoyer.
📊 En chiffres :
Dans les implémentations MCP testées, près de la moitié présentaient des failles exploitables d'injection de commandes et près d'un tiers des vulnérabilités SSRF. Il ne s'agit ni de cas limites ni d'expositions théoriques — ce sont les mêmes catégories de vulnérabilités qui ont provoqué des violations majeures dans les infrastructures web conventionnelles, et elles apparaissent désormais dans la couche qui donne aux agents IA un accès direct aux systèmes internes.
Détournement de serveurs au niveau du registre et risque de chaîne d'approvisionnement
C'est le risque qui réfute le plus directement l'argument selon lequel « si nous renforçons le LLM et les systèmes sous-jacents, MCP n'est qu'une plomberie d'infrastructure ».
Une étude portant sur 67 057 serveurs MCP répartis sur six registres publics a identifié 833 serveurs vulnérables et 18 dotés de descriptions suspectes permettant la manipulation d'invocations et le détournement au niveau du registre. L'attaque ne nécessite aucune vulnérabilité au niveau du code. Des contrôles de propriété insuffisants et des métadonnées non fiables dans le registre suffisent. Un attaquant capable d'insérer dans le registre un serveur malveillant ou modifié, découvert ensuite par un agent ou un développeur, peut influencer le raisonnement du modèle et le comportement de l'agent à grande échelle, avant même que l'agent n'atteigne le LLM renforcé ou la base de données renforcée.
Les serveurs MCP tiers récupérés depuis des registres publics comportent un risque de chaîne d'approvisionnement comparable à celui des packages npm non vérifiés — et, dans l'écosystème MCP, l'infrastructure de vérification est beaucoup moins mature. Des chercheurs en sécurité ont démontré des attaques d'empoisonnement d'outils dans lesquelles des descriptions de serveur apparemment inoffensives contenaient des instructions cachées poussant les agents à exfiltrer des données ou à rediriger des actions sans aucune indication visible pour l'utilisateur final. La couche de découverte de l'écosystème MCP constitue une surface d'attaque. Les équipes qui ne la traitent pas comme telle s'appuient sur une hypothèse que les données ne confirment pas.
Les contrôles de sécurité qui font réellement passer le risque MCP de théorique à maîtrisable
La théorie s'arrête ici. Les contrôles suivants répondent aux modes de défaillance spécifiques décrits ci-dessus, et non à la catégorie générale de la « sécurisation des systèmes IA ». Ils s'appuient sur le guide pratique MCP de la Coalition for Secure AI et sur les recherches d'Astrix Security concernant les pratiques d'identifiants MCP.
Authentification, autorisation et accès aux outils selon le principe du moindre privilège
Commencez par l'identité. Chaque connexion à un serveur MCP doit exiger une authentification forte. TLS au minimum ; TLS mutuel pour les connexions serveur à serveur lorsque vous contrôlez les deux extrémités. Les identifiants doivent être de courte durée et limités à un périmètre précis — et non des clés API stockées dans des variables d'environnement, que Astrix Security dans son rapport « State of MCP Server Security 2025 » a trouvées dans 79 % des implémentations, alors qu'elles représentent exactement le type de secret statique qui facilite le vol d'identifiants.
L'autorisation MCP doit être limitée à ce dont l'agent IA a précisément besoin pour la tâche qu'il exécute — et non à ce qu'il est pratique d'exposer. Un outil dont un agent a besoin pour lire des enregistrements CRM ne doit pas également disposer d'un accès en écriture, sauf si le workflow l'exige explicitement. Traiter les outils MCP comme une frontière de confiance, comme le recommande la communauté de la sécurité, implique de limiter l'accès à des répertoires et API spécifiques plutôt que d'accorder des autorisations larges en faisant confiance au modèle pour rester dans les limites.
Une liste de contrôle pratique pour commencer :
- Remplacez les clés API statiques par OAuth ou des jetons de courte durée Seuls 8,5 % des serveurs MCP utilisent actuellement OAuth. Ce chiffre doit être bien plus élevé dans tout déploiement que vous contrôlez.
- Limitez les identifiants par outil, et non par serveur Un serveur exposant dix outils ne doit pas utiliser un unique ensemble d'identifiants donnant accès à tout ce dont ces dix outils pourraient théoriquement avoir besoin.
- Faites tourner les secrets selon un calendrier, et non après une violation Si la rotation des identifiants nécessite des étapes manuelles, elle ne sera pas appliquée de manière cohérente. Automatisez-la ou acceptez qu'elle n'aura pas lieu.
- Auditez chaque trimestre le périmètre des autorisations des outils Les outils disponibles accumulent des droits au fil du temps. Ce qui commence par un accès en lecture seule tend à s'étendre. Vérifiez-le.
Validation des entrées, exécution en sandbox et données à ne pas journaliser
Compte tenu des taux d'injection de commandes et de traversée de chemins observés dans les déploiements réels, traiter toutes les entrées externes comme non fiables n'est pas facultatif. Validez et nettoyez tout avant qu'une entrée n'atteigne un outil qui exécute des commandes, lit des fichiers ou effectue des requêtes sortantes. Ce point n'est pas propre à MCP : il relève des pratiques standard de développement sécurisé que le cadrage IA conduit parfois les équipes à ignorer, car elles pensent que le modèle est la couche de validation. Ce n'est pas le cas.
L'exécution en sandbox limite le rayon d'impact lorsqu'un élément parvient à passer. Un serveur MCP qui lance des processus enfants ou accède au système de fichiers local doit s'exécuter dans un environnement où ces capacités sont explicitement limitées — répertoires spécifiques, destinations réseau spécifiques, aucun accès aux secrets de production depuis la sandbox. Les limites strictes sur le système de fichiers et le réseau constituent une bonne pratique nommée pour une raison : un serveur MCP local disposant d'un accès illimité au système de fichiers est une vulnérabilité de traversée de chemins qui attend que quelqu'un découvre l'entrée appropriée.
Concernant la journalisation : auditez chaque invocation d'outil. Journalisez ce qui a été appelé, avec quels arguments et ce qui a été renvoyé. Mais un serveur MCP malveillant pourrait tenter d'extraire des jetons sensibles depuis les journaux si ceux-ci sont accessibles. Ne journalisez pas les valeurs brutes des identifiants, les jetons d'authentification ni les secrets présents dans les payloads. Journalisez suffisamment pour reconstituer ce qui s'est passé, mais pas assez pour fournir à un attaquant ce dont il a besoin si le journal est compromis. C'est la recommandation de Black Hills Information Security que les équipes ignorent systématiquement.
Superviser les interactions MCP et conserver une visibilité sur l'ensemble du graphe
Un serveur MCP ne réalise pas un seul appel API. Il peut déclencher des chaînes d'appels d'outils sur plusieurs systèmes, et ces chaînes peuvent se ramifier. Une interaction compromise peut se propager dans un workflow de manières invisibles dans les journaux d'un système pris isolément, mais clairement visibles dans une vue au niveau du graphe de la séquence d'interactions.
La supervision continue des déploiements MCP implique de suivre non seulement si un outil a été appelé, mais également ce qu'il a appelé en aval. Surveillez notamment : les appels d'outils vers des ressources hors de leur périmètre attendu, les schémas d'arguments inhabituels (chaînes longues dans les chemins de système de fichiers, adresses réseau inattendues), les échecs d'authentification lors des invocations d'outils, ainsi que tout outil qui commence soudainement à s'exécuter beaucoup plus fréquemment que son niveau de référence. Les fichiers de configuration de serveurs MCP obsolètes sont également un signal : un serveur qui n'a pas été modifié depuis six mois peut avoir dérivé de sa posture de sécurité initiale sans que personne ne s'en aperçoive.
Les équipes qui construisent cela dans Latenode bénéficient d'un avantage : AI Agent Builder permet une orchestration en plusieurs étapes dans laquelle chaque action de l'agent constitue une étape de workflow distincte avec son propre journal d'exécution. Les chaînes d'appels d'outils deviennent donc visibles sous la forme de séquences d'exécution structurées plutôt que de traces d'inférence opaques — une approche pratique pour obtenir la visibilité au niveau du graphe qu'exige la supervision MCP, sans créer de toutes pièces une pile d'observabilité personnalisée.
Qui a réellement besoin de contrôles de sécurité MCP et ce qu'ils cherchent à empêcher
Trois types d'équipes font face à différentes versions de ce problème aujourd'hui. Chacune tente d'empêcher une défaillance spécifique, et non une catégorie générale de « risque de sécurité IA ».
Les équipes de sécurité et d'ingénierie de plateforme qui exposent des données d'observabilité et de CI/CD aux agents IA
Ces équipes connectent des agents IA aux pipelines de déploiement, aux systèmes de supervision et aux API d'infrastructure afin que les développeurs puissent interroger le statut des builds, déclencher des restaurations ou analyser des incidents via une interface conversationnelle. Ce qu'elles cherchent à empêcher est un chemin vers la production non maîtrisé : un agent capable de lire les journaux de déploiement peut aussi, dans de mauvaises conditions, déclencher des déploiements. Le modèle de menace associe un périmètre d'outil mal configuré à une injection de prompt suffisamment persuasive dans un rapport d'incident ou une entrée de journal. Le contrôle qui leur manque le plus souvent est l'accès aux outils selon le principe du moindre privilège — accès en lecture et accès en écriture clairement séparés au niveau du serveur MCP. L'adoption de l'IA dans ce contexte avance assez vite pour que les contrôles de sécurité soient ajoutés après coup, c'est-à-dire précisément lorsque l'exposition a déjà eu lieu.
Les équipes d'expérience développeur et d'outillage IA qui conçoivent des intégrations IDE et des workflows d'assistants de code
Ces équipes connectent des serveurs MCP aux référentiels de code source, aux systèmes de suivi des tickets et aux outils de revue de code afin que les assistants IA puissent aider les développeurs à trouver le contexte, proposer des correctifs et comprendre les bases de code. Elles cherchent à empêcher les modifications de code non autorisées et l'exfiltration d'identifiants via l'empoisonnement d'outils — par exemple, un serveur MCP tiers qui semble être un outil de recherche de code utile, mais contient des instructions cachées dans sa description d'outil afin de rediriger l'agent vers l'exfiltration de clés API depuis des fichiers .env. Les professionnels de la sécurité dans cet espace traitent de plus en plus chaque entrée de registre MCP tierce comme les équipes de sécurité applicative traitent les packages npm non vérifiés : comme un artefact non fiable qui exige une revue avant d'être utilisé en production. Les assistants IA ayant accès aux référentiels de code constituent des cibles de grande valeur, et le vecteur de chaîne d'approvisionnement via les registres est celui que la plupart des équipes d'outillage développeur n'ont pas encore pleinement pris en compte.
Les équipes AppSec et DevSecOps qui cherchent à anticiper une nouvelle surface de sécurité IA
Ces équipes font face à MCP comme à du shadow IT : de nouveaux outils IA continuent d'apparaître dans les environnements de production, chacun avec sa propre configuration de serveur MCP, sans inventaire centralisé et avec des périmètres d'accès flous. Elles cherchent à empêcher le détournement de registre et les chemins d'accès non comptabilisés — des situations dans lesquelles un agent a reçu l'accès à un système dont la conformité exige un audit, mais où personne n'a ajouté le serveur MCP à l'inventaire des actifs parce qu'il a été installé par un développeur un vendredi après-midi. Le nouveau défi IA n'est pas technique. Il concerne la gouvernance. Les agents eux-mêmes sont de plus en plus bien gouvernés ; les serveurs auxquels ils se connectent ne le sont pas.
Trois idées reçues sur la sécurité MCP qui créent de vraies failles
Ces trois idées reçues apparaissent régulièrement avant les incidents. Pas au stade théorique, où elles seraient faciles à corriger. Au stade de la conception, où elles façonnent l'architecture.
Première idée reçue : MCP n'est qu'un système de plugins supplémentaire, donc les contrôles de sécurité API suffisent. Cela paraît raisonnable jusqu'à ce que vous examiniez le modèle de confiance. Une intégration API conventionnelle dispose d'un client défini, d'un endpoint défini et d'un ensemble fixe d'opérations que le client peut demander. MCP permet à un agent IA de découvrir et d'appeler dynamiquement des outils selon son contexte et ses instructions d'exécution. Les décisions de l'agent sont influencées par des entrées que la pile de sécurité ne touche souvent jamais — descriptions d'outils, contexte injecté depuis des documents externes, métadonnées de registre. Les contrôles API standard ne peuvent pas auditer ce que l'agent a reçu comme instruction pour prendre sa décision ; ils peuvent uniquement observer ce qu'il a ensuite demandé. Cet écart constitue la surface d'attaque spécifique à MCP.
Deuxième idée reçue : si le LLM et les systèmes sous-jacents sont renforcés, MCP n'est qu'une considération secondaire au niveau du middleware. C'est le cadrage dans lequel tombent le plus souvent les équipes soucieuses de sécurité, ce qui explique également pourquoi il est le plus dangereux. Les équipes ayant fortement investi dans la sécurité des LLM et le renforcement de l'infrastructure ont tendance à considérer MCP comme de la plomberie — le tuyau entre deux éléments sécurisés. Pourtant, ce tuyau est précisément le chemin d'attaque identifié par les recherches à l'échelle des registres. L'étude arXiv portant sur 67 057 serveurs a identifié des conditions propices au détournement au niveau du registre dans les registres publics, sans aucune vulnérabilité au niveau du code dans les systèmes sous-jacents. L'agent ne peut agir qu'au moyen des outils MCP. Contrôlez les outils et vous contrôlez l'agent — indépendamment du niveau de renforcement du modèle ou de la base de données qui se trouve derrière.
🤔 Attendez.
Si un agent IA ne peut agir qu'au moyen d'outils MCP, un serveur MCP compromis dispose alors d'un accès direct à tout ce que l'agent a été autorisé à toucher. L'entraînement du LLM à la sécurité n'aide pas ici — cet entraînement porte sur ce que le modèle refuse de générer, et non sur ce qu'une instruction d'outil manipulée lui demande d'exécuter. Le rayon d'impact d'un serveur compromis est exactement égal au périmètre des autorisations du serveur. L'avez-vous délimité récemment ?
Troisième idée reçue : l'injection de prompts est le seul véritable enjeu de sécurité MCP ; si vous la gérez, vous êtes couvert. Les statistiques d'Equixly sur l'injection et les SSRF réfutent directement cette idée. 43 % d'injection de commandes, 30 % de SSRF, 22 % de traversée de chemins — il s'agit de vulnérabilités d'infrastructure classiques qui apparaissent dans les outils IA à des taux qui déclencheraient des programmes de remédiation dans n'importe quel contexte conventionnel. L'injection de prompts est une catégorie de menace réelle et importante. Ce n'est pas la seule. Les serveurs MCP acceptent des entrées d'agents IA et exécutent des opérations réelles sur des systèmes réels. Ce sont des services accessibles sur le web. Ils doivent recevoir les mêmes pratiques de développement sécurisé que tout autre service accessible sur le web.
Je vois sans cesse des équipes ignorer le travail sur les vulnérabilités classiques parce que la conversation sur la sécurité MCP a été dominée par les vecteurs d'attaque propres à l'IA. Ce cadrage est exact dans ce qu'il couvre. Il ne va tout simplement pas assez loin.
À quoi ressemblera la sécurité MCP à mesure que l'écosystème mûrit
Certaines évolutions sont clairement en cours. D'autres constituent de véritables problèmes ouverts qu'aucun fournisseur ni organisme de normalisation n'a encore résolus.
La gouvernance des registres est la lacune la plus évidente. La discussion autour de la checklist de sécurité MCP a rapidement mûri au cours de l'année écoulée, mais il n'existe toujours pas de processus standardisé de vérification des serveurs pour les registres publics. N'importe qui peut publier un serveur MCP. L'adoption de MCP dans les outils de développement a dépassé la capacité de l'écosystème à vérifier ce qui est adopté. Les serveurs MCP distants découverts via des registres publics présentent le même risque de chaîne d'approvisionnement que les packages open source non examinés, sans même les signaux de gouvernance sociale que les communautés npm et PyPI utilisent pour identifier les packages suspects.
La signature standardisée des serveurs constitue la réponse technique, mais prendre en charge une signature à l'échelle de l'écosystème MCP exige une coordination entre plusieurs opérateurs de registres et fournisseurs de chaînes d'outils. Cette coordination n'en est qu'à ses débuts. La conclusion des recherches d'Astrix selon laquelle 88 % des serveurs exigent des identifiants, tandis que la plupart utilisent des secrets statiques, suggère que la couche d'identité doit faire l'objet d'un travail de normalisation avant que la couche de signature ne puisse réellement avoir de l'importance.
L'abus de contexte entre agents est un modèle de menace émergent qui n'est pas encore bien défini. À mesure que les déploiements multi-MCP se généralisent — un agent appelant des outils provenant de plusieurs serveurs et partageant du contexte entre eux — la surface d'interaction propice à l'empoisonnement du contexte et à l'escalade de privilèges se développe d'une manière que les modèles de sécurité à serveur unique ne traitent pas. Qui est responsable de l'audit d'une chaîne de contexte qui traverse trois serveurs appartenant à trois équipes ? Cette question n'a pas de réponse claire aujourd'hui, et je pense qu'elle provoquera la première vague d'incidents IA agentique majeurs lorsque quelqu'un le découvrira à ses dépens.
