Alors que le Model Context Protocol (MCP), lancé par Anthropic fin 2024, devient le standard de facto de la connectivité pour les agents d’IA, une faille fondamentale apparaît. Ce n’est pas une question technique d’interfaces ou de JSON-RPC, mais bien d’identité. Dès qu’un agent agit, l’humain qui l’a déclenché disparaît souvent des logs et des contrôles, et la responsabilité se dilue.
Cette disparition transforme chaque outil connecté en surface d’attaque et chaque agent en super-utilisateur difficile à encadrer. Les droits s’élargissent, mais la traçabilité recule. Ce déséquilibre profite autant aux usages légitimes qu’aux attaquants.
À retenir
- Le MCP est le « USB-C de l’IA » : une interface universelle lancée par Anthropic fin 2024 qui permet aux agents de se connecter à des outils, bases de données et applications tierces.
- 38 % des serveurs MCP sont déployés sans aucune authentification ; 53 % reposent sur des secrets statiques plutôt que sur OAuth 2.1.
- Une fois connecté, l’identité humaine s’efface souvent au profit d’un Managed Identity Token, créant une « boîte noire » de privilèges.
- Principaux vecteurs d’attaque : Prompt Injection, Tool Poisoning, Confused Deputy et SSRF (Server-Side Request Forgery).
- La vulnérabilité CVE-2026-26118 a démontré qu’un attaquant pouvait voler un Managed Identity Token via une simple SSRF.
- Solutions prioritaires : traiter les agents comme des Non-Human Identities (NHI), déployer des MCP Gateways, appliquer la Zero Trust Architecture et imposer un Human-in-the-loop sur les actions critiques.
Le MCP, ce pont universel qui a tout simplifié… sauf la question de savoir qui agit
Lancé par Anthropic à la fin de l’année 2024, le Model Context Protocol repose sur trois composants : l’hôte (votre IDE ou application), le client (l’agent d’IA) et le serveur MCP qui expose les outils — Google Drive, Slack, bases SQL ou API internes. L’ensemble forme une interface unique pour relier rapidement agents et systèmes existants.
Cette standardisation a réglé un blocage majeur de l’Agentic AI : auparavant, chaque modèle devait intégrer ses propres connecteurs propriétaires. Avec le MCP, un agent peut utiliser n’importe quel outil compatible, comme un périphérique USB-C branché sur n’importe quel ordinateur. Ce parallèle explique la rapidité avec laquelle entreprises et développeurs ont adopté le protocole, souvent sans définir de cadre de contrôle solide.
Mais cette connectivité généralisée repose sur une hypothèse fragile : que l’identité de celui qui commande l’agent reste cohérente tout au long de la chaîne d’exécution. Dans la pratique, cette continuité est rarement assurée, et l’utilisateur disparaît dès que l’agent commence à agir.
L’identité humaine s’efface aux frontières du protocole
Dès qu’un agent d’IA appelle un serveur MCP, l’utilisateur final disparaît souvent des métadonnées. Le serveur ne voit qu’une requête authentifiée par une clé API statique ou un compte de service. L’agent devient alors un super-utilisateur technique qui hérite de tous les droits du compte auquel il est rattaché.
Cette situation porte un nom dans la littérature en cybersécurité : le problème du Confused Deputy. Un agent autorisé à agir au nom d’un utilisateur peut exécuter une action malveillante sans que le système distingue une intention légitime d’une manipulation. Le système d’information se contente d’un jeton valide et d’un outil disponible.
Le décalage entre connectivité et gouvernance est net. Le MCP a été conçu pour maximiser l’interopérabilité, pas pour garantir une traçabilité fine des Non-Human Identities (NHI). Résultat : nous déployons des agents dotés de droits étendus sans leur attribuer d’identité propre, séparée de celle de l’humain, ce qui complique toute analyse a posteriori.
38 % des serveurs MCP sans aucune authentification
Les chiffres publiés par Adversa AI et Knostic sont clairs : près de 38 % des serveurs MCP exposés publiquement n’ont aucune authentification activée par défaut. Plus de la moitié (53 %) reposent encore sur des secrets statiques plutôt que sur des mécanismes modernes comme OAuth 2.1, ce qui facilite la réutilisation de credentials en cas de compromission.
La vulnérabilité CVE-2026-26118 découverte dans Azure MCP Server illustre précisément ce risque. Un attaquant peut forcer le serveur à effectuer une requête sortante (SSRF) incluant son Managed Identity Token. Une fois ce jeton exfiltré, il hérite des privilèges associés à l’identité du serveur, souvent très élevés et rarement limités au strict nécessaire.
Ce scénario n’a rien de théorique. Des chercheurs ont montré qu’un simple message Slack ou un e-mail contenant une Prompt Injection peut suffire à pousser un agent à utiliser des outils MCP pour exfiltrer l’historique WhatsApp ou supprimer en masse des données. L’agent suit la consigne injectée, le serveur valide le jeton, et l’action se déroule sans validation humaine.
Le Tool Poisoning va plus loin : un serveur MCP malveillant peut modifier la description d’un outil de confiance pour y ajouter des instructions cachées. L’agent, confiant dans ce qu’il pense être un outil interne, exécute l’action demandée sans réaliser qu’il a été manipulé en amont.
Replacer l’identité au centre de l’architecture MCP
La réponse ne consiste pas à abandonner le MCP — son utilité opérationnelle est évidente — mais à l’entourer d’une couche de gouvernance adaptée à l’ère de l’Agentic AI. Il s’agit de reprendre le contrôle sur qui fait quoi, avec quels droits et pour combien de temps.
Première étape : traiter les agents comme des Non-Human Identities à part entière dans les systèmes IAM (Identity and Access Management). Chaque agent doit disposer de sa propre identité, de scopes dédiés, d’une durée de vie de credentials limitée et de logs d’audit distincts. Sans cette séparation, l’investigation d’incidents reste floue et les responsabilités introuvables.
Les MCP Gateways apparaissent comme l’outil le plus prometteur. Placées entre les agents et les serveurs MCP, elles centralisent le logging, inspectent le trafic, appliquent le principe de moindre privilège et propagent l’identité de l’utilisateur initial à chaque étape de l’exécution. Elles deviennent le point où se combinent droits de l’agent et contexte de la demande.
L’architecture Zero Trust doit également être étendue au niveau du contexte : à chaque appel d’outil, le système doit vérifier non seulement qui est l’agent, mais aussi dans quel contexte il agit et au nom de qui. Pour les actions à fort impact — suppression de données, envoi de messages, modification de permissions — cela implique souvent un Human-in-the-loop avec validation explicite.
Une course entre innovation et contrôle
Le MCP accélère fortement le déploiement d’agents autonomes. Cette vitesse rend la gouvernance urgente, car chaque nouvelle intégration sans contrôle d’identité élargit la surface d’attaque collective et complique la détection des abus.
Les organisations qui s’en sortiront le mieux seront celles qui comprendront qu’à l’ère des agents d’IA, la question centrale n’est plus seulement « que peut-il faire ? », mais surtout « qui le fait faire, et pourquoi ? ». Cette inversion de perspective conditionne la manière de concevoir droits, logs et mécanismes de validation.
Le protocole n’était qu’un moyen. Le véritable enjeu — et le vrai défi — reste la gestion mature des identités non humaines.
Sources principales : recherches Adversa AI et Knostic, analyse SC Media, documentation officielle Anthropic sur le MCP.
Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.