Sécuriser l'entreprise agentique : Concevoir des proxies MCP pour la gouvernance autonome des outils

Lorsqu’un agent IA décide comment exécuter un outil local, les pare-feu réseau classiques sont totalement aveugles quant à son intention. Plongez dans l’architecture des proxies Model Context Protocol — les points d’entrée spécialisés conçus pour auditer et sandboxer l’exécution autonome des agents.

---

Le point d’inflexion agentique

L’architecture d’entreprise traverse une période de discontinuité rapide. Les grands modèles de langage ne génèrent plus du texte à la demande ; ils orchestrent de manière autonome des flux de travail, interrogent des bases de données de production, modifient des systèmes de fichiers et déclenchent des pipelines CI/CD. La liaison permettant ce changement est le Model Context Protocol (MCP) d’Anthropic, une norme open-source introduite en novembre 2024, qualifiée par Ars Technica de “USB-C pour l’IA”.

Le MCP répond à ce que les praticiens appelaient depuis longtemps le problème d’intégration N×M : avant l’existence du protocole, connecter dix agents à vingt outils internes nécessitait deux cents points d’intégration personnalisés, chacun maintenu indépendamment. MCP a remplacé cette dispersion par un protocole standardisé basé sur JSON-RPC 2.0.

Depuis son lancement, l’écosystème a connu une croissance remarquable. Anthropic a rapporté plus de 10 000 serveurs MCP publics actifs lors du don du protocole à la Linux Foundation’s Agentic AI Foundation (AAIF) en décembre 2025. Au deuxième trimestre 2026, le nombre de serveurs suivis dans les quatre principaux registres publics — PulseMCP, le registre MCP officiel, Smithery, et mcp.so — a dépassé environ 9 400 entrées, avec une croissance soutenue de 58 % trimestre après trimestre. Le dépôt GitHub modelcontextprotocol/servers avait accumulé plus de 86 000 étoiles et 10 000 forks en mai 2026. Les SDK Python et TypeScript avaient ensemble atteint 97 millions de téléchargements mensuels.

Cette trajectoire d’adoption a également révélé une nouvelle classe d’exposition à la sécurité, que ni les concepteurs du protocole ni les équipes d’entreprise ne prévoyaient pleinement.

---

L’architecture de sécurité du protocole — et ce qu’il omet

Le MCP fonctionne selon un modèle client-serveur avec trois rôles de participants :

Hôtes/Clients MCP sont les environnements d’application hébergeant le modèle IA — un moteur d’orchestration d’entreprise, Claude Desktop, ou un IDE alimenté par IA comme Cursor ou Windsurf.

Serveurs MCP sont des wrappers légers autour de systèmes externes — GitHub, Slack, systèmes de fichiers locaux, bases SQL — qui exposent des capacités standardisées.

La couche de protocole transporte des messages JSON-RPC 2.0 entre clients et serveurs via deux principaux moyens de transport : stdio pour la communication locale entre processus, et HTTP streamable (qui a remplacé l’ancien transport Server-Sent Events) pour les connexions distantes.

Grâce au MCP, un agent interagit avec trois primitives fondamentales :

• Ressources (contrôlées par l’application) : sources de données contextuelles en lecture seule, comme des fichiers journaux ou des schémas de bases de données. Ces sources sont sans effet de bord.
• Prompts (contrôlés par l’utilisateur) : modèles réutilisables guidant l’interaction du LLM avec les outils.
• Outils (contrôlés par le modèle) : fonctions exécutables que l’agent peut invoquer pour réaliser des actions dans le monde réel — execute_sql, push_code, restart_server.

La primitive Outils est le point où l’exposition à la sécurité est la plus critique. Un serveur MCP exécuté sur une machine locale ou dans un sous-réseau de production peut exécuter du code arbitraire basé sur la sortie non déterministe d’un LLM. La sécurité réseau standard détecte une connexion HTTP légitime transportant des données JSON ; elle ne peut pas distinguer une requête d’un agent pour un rapport d’une commande pour supprimer une table suite à une instruction hallucination.

Cet écart n’est pas une préoccupation théorique. Comme l’a indiqué le Centre de sécurité de l’intelligence artificielle de la NSA dans sa fiche d’information sur la cybersécurité de mai 2026 concernant le MCP (U/OO/6030316-26) : la prolifération rapide du MCP a dépassé le développement de son modèle de sécurité, à l’image des premiers protocoles web. La CSI a identifié un problème structurel au cœur de la conception du MCP : le protocole inverse le schéma d’interaction habituel où les clients demandent des données aux serveurs — le MCP s’attend souvent à ce que les serveurs interrogent et exécutent parfois des actions pour les clients connectés. Cette inversion crée des voies d’attaque qui étaient difficilement traçables lors des premières déploiements.

La constatation spécifique de la NSA sur les contrôles de base est importante : le MCP ne définit pas comment une session est liée à une identité vérifiable, l’authentification est optionnelle plutôt que requise dans la spécification de base, et le contrôle d’accès basé sur les rôles n’est pas intégré au protocole au niveau du transport. Comme le résume la spécification, le MCP elle-même reconnaît que “le MCP ne peut pas faire respecter ces principes de sécurité au niveau du protocole”.

---

Le paysage des menaces réel

Comprendre ce contre quoi un proxy MCP doit se défendre nécessite une taxonomie concrète des vulnérabilités démontrées, exploitées ou classifiées dans la nature.

Injection de prompts et poisoning d’outils

OWASP classe l’injection de prompts en tête de son Top 10 pour les applications LLM (édition 2025), et l’architecture MCP amplifie ce risque. Le poisoning d’outils est une variante spécialisée : plutôt que d’injecter du contenu malveillant dans les entrées utilisateur, les attaquants intègrent des instructions cachées directement dans les définitions d’outils — les métadonnées qui indiquent à un agent IA ce que chaque outil fait et comment l’invoquer. Lorsqu’un agent se connecte à un serveur MCP et demande la liste des outils via tools/list, le serveur répond avec des noms et descriptions qui entrent dans le contexte du modèle. Un attaquant contrôlant ces métadonnées peut influencer le comportement du modèle dans chaque session où cet outil est chargé, sans interaction utilisateur directe.

Le blog des développeurs de Microsoft décrit précisément ce mécanisme : des instructions malveillantes dans les métadonnées d’outil sont invisibles pour l’utilisateur mais peuvent être interprétées par le modèle IA, ce qui rend cette attaque particulièrement dangereuse dans des scénarios d’hébergement où les définitions d’outils peuvent être modifiées en silence après approbation initiale.

Le benchmark MCPTox, qui a évalué 20 agents LLM majeurs contre 45 serveurs MCP réels utilisant 353 outils authentiques, a révélé des résultats alarmants. Le modèle o1-mini a montré un taux de réussite d’attaque de 72,8 % contre les tentatives de poisoning d’outils. Les modèles plus performants étaient souvent plus vulnérables car ces attaques exploitent leurs capacités supérieures à suivre des instructions. Claude 3.7-Sonnet a affiché le taux de refus le plus élevé parmi tous les modèles testés — moins de 3 %.

Rug pulls

Un rug pull amplifie la menace du poisoning d’outils. Un serveur MCP se comporte légitimement lors de l’installation, passe une revue initiale, et obtient des permissions. Ensuite, sans notification au client, ses définitions d’outils sont silencieusement mises à jour pour inclure des instructions malveillantes. L’incident Postmark MCP de septembre 2025 illustre ce schéma : un acteur malveillant a cloné le dépôt légitime de Postmark MCP, publié un paquet npm presque identique, maintenu un comportement légitime à travers quinze versions pour instaurer la confiance, puis a introduit une ligne de code cachée qui a silencieusement copié tous les emails sortants vers une adresse contrôlée par l’attaquant. Les utilisateurs n’ont eu aucune indication que quelque chose avait changé.

CVE-2025-54136 (CurXecute), découvert par Check Point, a montré le même schéma appliqué aux fichiers de configuration : une configuration MCP bénigne a été validée une fois, puis remplacée silencieusement par une charge utile. Cursor faisait confiance au nom de la clé approuvée plutôt qu’au contenu de la commande, ce qui a permis à la version malveillante de s’exécuter silencieusement à chaque ouverture de projet.

Attaques de type Confused Deputy

Le serveur MCP exécute des actions déclenchées par l’agent mais avec les permissions accordées au serveur lui-même, et non nécessairement à l’utilisateur final ou à l’agent spécifique qui l’invoque. Sans proxy pour faire correspondre l’identité de l’agent à des politiques d’accès fines, le principe du moindre privilège est structurellement impossible à faire respecter. Un serveur MCP compromis peut abuser de ses privilèges élevés pour accéder à des systèmes que l’agent initial n’était pas censé atteindre. OAuth 2.1 y répond partiellement en liant les tokens à des audiences et scopes spécifiques — un token délivré pour un serveur MCP est cryptographiquement rejeté par un autre — mais cela nécessite une mise en œuvre correcte, ce qui est souvent absent dans de nombreux déploiements.

CVEs critiques : Exploitation de la chaîne d’approvisionnement en situation réelle

Deux CVEs de 2025 ont concrétisé la vulnérabilité théorique.

CVE-2025-6514 (CVSS 9.6), découvert par JFrog Security Research en juillet 2025, concernait mcp-remote, un outil proxy permettant aux hôtes LLM comme Claude Desktop de communiquer avec des serveurs MCP distants. mcp-remote était référencé dans des guides d’intégration de Cloudflare, Hugging Face, et Auth0, avec plus de 437 000 téléchargements. La faille était une injection de commande OS : lorsqu’il se connectait à un serveur malveillant, celui-ci pouvait renvoyer une URL authorization_endpoint conçue pour être passée directement au shell du système sans validation. Sur Windows, cela permettait l’exécution arbitraire de commandes PowerShell. Sur macOS et Linux, des exécutables arbitraires pouvaient être lancés. C’était le premier cas documenté d’exécution de code à distance complète contre un client MCP dans un scénario réel. La vulnérabilité concernait les versions 0.0.5 à 0.1.15, corrigée en 0.1.16.

CVE-2025-49596 (CVSS 9.4), touchait l’outil MCP Inspector. L’interface interactive lancée par MCP Inspector via localhost manquait d’authentification, permettant à un attaquant en réseau d’injecter des commandes malveillantes via une attaque CSRF — une technique nommée NeighborJacking par les chercheurs. La faille a été corrigée en version 0.14.1.

Les serveurs MCP Filesystem d’Anthropic comportaient deux CVEs supplémentaires : CVE-2025-53110 (CVSS 8.4), une contournement de lien symbolique permettant des lectures et écritures vers des chemins arbitraires ; et CVE-2025-53109 (CVSS 7.3), une contournement de la containment de répertoire permettant de sortir du périmètre autorisé.

Un audit de sécurité de 2026, cité dans la documentation OAuth du MCP, a révélé que 25 % des serveurs MCP publics n’avaient aucune authentification, et 53 % utilisaient encore des clés API statiques à longue durée de vie ou des jetons d’accès personnels — des identifiants qui, une fois divulgués, donnent un accès indéfini. La CSI de la NSA a confirmé cette situation, notant que l’authentification optionnelle signifie que des serveurs MCP en production existent dès maintenant, accessibles depuis les environnements agent, sans vérification des identités.

La boîte noire du transport stdio

Pour les environnements de développement locaux, le MCP repose fortement sur le transport stdio. Cela crée un canal non journalisé entre le modèle IA et la machine locale. Une attaque de chaîne d’approvisionnement compromettant un serveur MCP open-source ne permet pas de voir ce que l’agent IA est instruit de faire sur l’hôte. Le ver Shai-Hulud, un malware auto-reproducteur intégré dans des packages npm et analysé en profondeur par JFrog Security Research, a montré le potentiel d’amplification : une fois intégré, il a volé des tokens développeurs et réinfecté automatiquement d’autres packages, se propageant dans la chaîne d’approvisionnement sans intervention supplémentaire.

---

Pourquoi les contrôles de sécurité standards échouent

Les passerelles API classiques valident les tokens d’authentification, appliquent des limites de débit de base, et vérifient les chemins de routage. Elles échouent face aux vecteurs d’attaque spécifiques à l’IA car toute la surface d’attaque est intégrée dans la charge sémantique de l’appel d’outil — pas dans ses en-têtes HTTP, tokens d’authentification ou structure de routage.

Considérez une requête interceptée d’un agent tentant d’exécuter une opération sur une base de données :

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "execute_sql",
    "arguments": {
      "query": "DROP TABLE production_users CASCADE",
      "database": "primary_db"
    }
  },
  "id": 84
}

Un WAF laisse passer cette requête sans inspection car les en-têtes HTTP et tokens OAuth sont valides. La menace réside entièrement dans arguments.query. Un pare-feu traditionnel n’a aucun mécanisme pour évaluer le contenu sémantique de ce champ.

L’analyse de sécurité d’identité de SC Media pour 2026 a précisément identifié ce problème : les programmes zero-trust vérifient l’identité de l’agent, mais pas ce qu’on lui dit. Chaque description d’outil, chaque réponse API, chaque prompt utilisateur entrant dans la fenêtre de contexte de l’agent est implicitement digne de confiance une fois passé le périmètre. Ce n’est pas du zero trust. C’est un modèle de périmètre avec un trou en forme d’IA.

---

Architecturer le proxy MCP

Un proxy MCP fonctionne comme un intermédiaire spécialisé entre le MCP Client et le MCP Server. En terminant la connexion JSON-RPC, en inspectant les charges utiles sémantiquement, et en appliquant une gouvernance basée sur des politiques, il étend les principes de zero-trust aux interactions agent-outil autonomes.

Plusieurs approches architecturales ont convergé. Le cadre ZT-MCP d’un article de 2026 introduit un modèle de contrôle d’accès basé sur des capacités (CapBAC) avec quatre composants de mise en œuvre. MCP-Guard propose un cadre de défense en profondeur à plusieurs étapes avec une analyse statique légère en premier lieu et une évaluation sémantique en second. Des plateformes de production comme TrueFoundry MCP Gateway, Portkey, et Peta ont implémenté des variantes du modèle proxy commercialement.

Une architecture de proxy MCP de niveau production comprend cinq composants clés.

1. Couche d’analyse et d’interception du protocole

Le proxy intercepte le transport sous-jacent — convertissant les flux locaux stdio non observables en trafic HTTP structuré pour l’observabilité, ou agissant comme un reverse proxy pour les connexions HTTP streamable. Il parse en temps réel les charges JSON-RPC 2.0, extrayant la méthode demandée (ex. tools/call) et ses paramètres spécifiques. C’est à ce niveau que le champ arguments.query ci-dessus devient visible et inspectable.

Un avantage pratique de cette couche : elle fournit une traduction centralisée du protocole entre stdio, SSE, et HTTP, rendant auditable des connexions locales auparavant invisibles sans modifier le client ou le serveur MCP.

2. Moteur d’audit sémantique

Une fois la charge utile analysée, le proxy route les arguments vers un moteur d’audit sémantique. Les implémentations de production combinent heuristiques déterministes (analyse AST, correspondance de motifs SQL, détection de métacaractères shell) avec des modèles de classification légers pour l’évaluation de l’intention. Le moteur évalue les charges d’appel d’outil selon les garde-fous d’entreprise.

Dans l’exemple DROP TABLE, une couche de correspondance de motifs signalerait la déclaration DDL destructrice avant qu’un modèle sémantique ne soit invoqué. Pour des cas plus ambigus — un agent tentant un force_override sur un paramètre de configuration réseau — la couche sémantique évalue la combinaison du nom de l’outil, des valeurs d’arguments, et de l’historique récent des appels pour produire une classification de risque.

Le moteur d’audit renvoie une erreur JSON-RPC à l’agent avant que le serveur MCP ne voie la requête, et enregistre l’événement d’interception dans le SIEM.

Il est important de noter une contrainte de conception : la version actuelle de la spécification MCP (2025-11-25) impose OAuth 2.1 pour les transports HTTP mais ne prévoit pas de mécanisme intégré pour signer les définitions d’outils. L’interface améliorée de définition d’outil (ETDI), proposée dans un article de Bhatt, Narajala, et Habler (2025), décrit une approche au niveau du protocole utilisant des définitions d’outils renforcées par OAuth et des vérifications cryptographiques pour prévenir le poisoning d’outils et les rug pulls. En date de mi-2026, l’ETDI reste une proposition de brouillon, non une norme ratifiée. Jusqu’à son adoption, l’intégrité des outils nécessite des contrôles spécifiques à l’implémentation au niveau du proxy.

3. Mapping d’identité et application des politiques (RBAC)

Le proxy mappe le token OAuth 2.1 du MCP Client à des outils spécifiques dans le MCP Server. La spécification MCP de novembre 2025 impose OAuth 2.1 avec PKCE (Proof Key for Code Exchange using S256) pour toutes les connexions distantes HTTP. Le proxy agit comme point d’application où ces tokens sont validés selon une politique d’accès centralisée.

Grâce à un RBAC fin, le proxy garantit qu’un agent avec des privilèges en lecture seule peut appeler list_files mais se voit refuser write_file ou execute_command sur le même serveur. Un agent de documentation dédié peut accéder à read_file et git_commit ; un agent de déploiement séparé et contrôlé détient execute_pipeline.

Un détail critique : la révision de la spécification MCP de juin 2025 interdit explicitement aux serveurs MCP de transmettre le token d’accès reçu du client aux API en amont, pour éviter les vulnérabilités de type confused deputy. Le proxy doit émettre des tokens limités en aval, ciblés sur le saut spécifique, plutôt que de propager le token d’entrée à travers les services.

4. Disjoncteur humain (HITL)

Certaines opérations sont trop sensibles pour être gouvernées uniquement par des politiques automatisées. La spécification MCP le reconnaît explicitement : “Pour la confiance, la sécurité, et la sûreté, il SHOULD toujours y avoir un humain dans la boucle capable de refuser les invocations d’outil.” Le Top 10 OWASP pour les applications LLM (2025) renforce cela sous LLM06 (Excessive Agency) : les actions à fort impact ne doivent pas se poursuivre sans approbation humaine.

Le proxy MCP implémente cela en agissant comme un disjoncteur pour les opérations de niveau 1. La requête JSON-RPC est suspendue plutôt que transmise ou rejetée. Une alerte est envoyée à une file de revue — tableau de bord, Slack, ou pager — avec le nom précis de l’outil, ses arguments, et l’identité de l’agent pour revue humaine. Si approuvé, le proxy transmet la charge utile ; si rejeté, il renvoie une erreur en langage naturel à l’agent, permettant au LLM de réévaluer sa stratégie.

Le mécanisme d’échantillonnage de la spécification MCP offre un crochet natif pour ce pattern, permettant aux serveurs de demander une intervention côté client. Le proxy centralise cette capacité pour tous les serveurs connectés plutôt que de la laisser à chaque implémentation.

5. Limitation de débit agentique et détection de boucle

Les agents autonomes peuvent entrer dans des boucles de raisonnement, appelant en boucle la même API lorsqu’ils échouent à analyser une erreur inattendue. Sans gouvernance, cela peut entraîner un déni de service accidentel contre des outils internes et des dépassements de coûts auprès des fournisseurs d’API cloud. Le Top 10 OWASP pour les applications LLM classe cela comme LLM10 (Unbounded Consumption), avec des mitigations recommandées : limites de débit strictes et disjoncteurs automatiques.

Le proxy MCP applique des limites de débit token-bucket sur des outils spécifiques et détecte les motifs de boucle en analysant la fréquence des appels, les séquences de réponses d’erreur, et la variance des arguments entre les invocations successives. Lorsqu’une boucle est détectée, le proxy interrompt l’exécution de l’agent avec une erreur structurée que le LLM peut traiter, plutôt que de laisser la boucle continuer jusqu’à un timeout externe.

---

La couche d’autorisation : ce que OAuth 2.1 résout et ce qu’il ne résout pas

La spécification d’autorisation MCP a évolué en trois révisions majeures en neuf mois. La révision de mars 2025 a introduit OAuth 2.1 comme norme de base pour l’authentification des serveurs distants. La révision de juin 2025 a formalisé les serveurs MCP comme des Resource Servers OAuth (RFC 8707) et rendu obligatoire le Metadata des ressources protégées (RFC 9728), séparant complètement le rôle du serveur MCP de celui du serveur d’autorisation. La révision de novembre 2025 a rendu le PKCE obligatoire pour tous les clients publics, interdit la méthode PKCE en clair au profit de S256, et formalisé les Documents de métadonnées d’identification client comme mécanisme de registre client préféré.

Malgré cette maturation, un audit de sécurité de 2026 a révélé que 53 % des serveurs MCP déployés utilisaient encore des clés API longues et statiques plutôt qu’OAuth 2.1. La contribution d’OAuth se limite à l’identité au niveau du transport : un token OAuth valide prouve qui prétend être la partie connectée et quels scopes elle possède. Il ne prouve pas que l’outil que l’agent s’apprête à invoquer est le même que celui autorisé par l’humain, ni ne détecte qu’une définition d’outil a été silencieusement modifiée depuis cette autorisation. Combler ces lacunes nécessite des contrôles au niveau de l’application au proxy — versioning du schéma d’outil, hachage de définition au début de session, détection d’anomalies lors des modifications de description.

---

Renforcement de la chaîne d’approvisionnement : le troisième périmètre

Le proxy régule le comportement en runtime. Un ensemble parallèle de contrôles doit réguler ce qui entre dans la chaîne d’approvisionnement avant l’exécution.

L’écosystème de packages MCP comporte les mêmes risques structurels que tout écosystème open-source, amplifiés par le fait que les serveurs MCP exécutent du code pour le compte d’agents IA avec un accès potentiellement étendu au système. L’incident Postmark MCP de septembre 2025 — où un paquet cloné a silencieusement exfiltré du trafic email à travers quinze versions de comportement légitime — a établi le schéma de rug pull comme une classe d’attaque documentée. La compromission de LiteLLM par le groupe TeamPCP a montré des attaques en cascade : LiteLLM, une passerelle universelle utilisée par environ 3,4 millions de téléchargements par jour et présente dans 36 % des environnements cloud, a été ciblée par le même groupe qui avait précédemment compromis le scanner Trivy d’Aqua Security et l’action GitHub KICS de Checkmarx en exploitant des versions non pinées de CI/CD.

Les contrôles pratiques pour la sécurité de la chaîne d’approvisionnement MCP incluent :

Vérification cryptographique du serveur : le proxy doit valider les signatures cryptographiques des packages MCP via un registre interne d’outils approuvés avant d’autoriser une connexion d’agent. La proposition ETDI offre une architecture au niveau du protocole pour cela ; jusqu’à sa standardisation, des contrôles spécifiques à l’implémentation utilisant le hachage des définitions d’outils remplissent la même fonction.

Pinning de version et re-validation du schéma : les schémas d’outils doivent être épinglés lors de l’installation et re-validés à chaque nouvelle session. Un mismatch doit déclencher une revue humaine, pas une acceptation silencieuse.

Déploiements privés de serveurs MCP pour charges sensibles : la NSA CSI recommande explicitement de faire fonctionner les serveurs MCP localement plutôt que de s’appuyer sur des services externes pour traiter des données privées ou sensibles, afin de réduire le risque d’exposition via des serveurs hébergés compromis ou non fiables.

Contrôles de namespace : la typosquatting des noms de packages MCP a été documentée comme vecteur d’attaque actif. La liste OWASP Top 10 MCP (2025) mentionne les faux et typosquattés serveurs officiels comme une menace distincte. Les configurations proxy doivent maintenir une liste blanche d’identifiants de serveurs approuvés plutôt que de se fier à la résolution de namespace en temps réel.

---

Journalisation centralisée d’audit : rendre le comportement de l’agent lisible pour SIEM

La spécification MCP inclut des recommandations de base pour la journalisation mais laisse la mise en œuvre complète de l’audit à chaque implémentateur. La CSI de la NSA a identifié une journalisation insuffisante ou absente comme l’une des lacunes les plus fréquentes dans les déploiements MCP réels.

Chaque interaction proxy — handshake initialize, exécutions tools/call, requêtes resources/read, appels rejetés, appels en suspension HITL, événements de limite de débit — doit être structurée comme télémétrie et transmise au SIEM de l’organisation. Le défi est que le trafic JSON-RPC 2.0 ne correspond pas aux modèles d’ingestion SIEM traditionnels conçus pour les logs d’accès HTTP ou syslog. Le Top 10 OWASP MCP liste une journalisation insuffisante comme le neuvième risque MCP le plus critique, notant que la majorité des équipes ne peuvent actuellement pas reconstituer une chronologie d’attaque MCP à partir de leur infrastructure de logs existante.

Les équipes SOC déployant la télémétrie MCP doivent développer des règles de détection spécifiques au comportement de l’agent : échecs rapides en série sur plusieurs outils disjoints (signal d’un agent halluciné ou compromis), changements soudains dans les motifs d’arguments d’outils, appels à des outils à privilèges élevés depuis des agents ayant uniquement invoqué des opérations à faible privilège.

La CSI de la NSA recommande d’intégrer les logs d’audit MCP avec les systèmes d’identité d’entreprise existants pour que chaque action d’agent soit traçable jusqu’à une identité authentifiée spécifique — pas seulement à un credential d’application.

---

Bonnes pratiques : un modèle de gouvernance en couches

Déployer un proxy MCP est le contrôle fondamental. Une gouvernance efficace nécessite qu’il s’insère dans un modèle en couches plus large.

Appliquer une validation stricte du schéma d’entrée à la frontière du proxy. Ne jamais faire confiance implicitement aux définitions de schéma d’outil fournies par un serveur MCP. Le proxy doit appliquer une validation centralisée via JSON Schema pour toutes les entrées d’outil, rejetant toute requête contenant des métacaractères shell (|, A6A6, ;) dans les champs de texte standard, des types d’arguments mismatches, ou des clés de paramètre inattendues. Il s’agit d’un filtre déterministe de première étape qui élimine une classe de tentatives d’injection avant qu’elles n’atteignent la couche d’audit sémantique.

Sandboxing des environnements d’exécution des serveurs MCP. Même avec un proxy en place, l’environnement d’exécution du serveur MCP doit être sécurisé. Les serveurs MCP locaux doivent fonctionner dans des pods Docker ou Kubernetes avec des limites strictes de mémoire et CPU, peu de montages de système de fichiers, et aucune autorité ambiante sur l’OS hôte. La limitation de débit du proxy empêche un serveur compromis d’épuiser les ressources, et l’isolation par conteneur empêche une escalade de privilèges vers l’hôte.

Adopter une architecture micro-agent avec des scopes d’outils par fonction. Éviter d’attribuer un accès large à un seul agent. Un agent de documentation ne doit avoir accès qu’à read_file et git_commit. Un agent de déploiement, séparément gouverné et journalisé, détient execute_pipeline. Cela limite la portée en cas de compromission ou hallucination d’un agent, et facilite l’audit du contrôle d’accès.

Aligner l’accès aux outils avec les zones de classification des données. La NSA CSI recommande de regrouper les outils par niveau de sensibilité : les outils publics peuvent traiter des données publiques, tandis que ceux manipulant des données sensibles ou réglementées — dossiers de santé, systèmes financiers, infrastructure de sécurité nationale — doivent être explicitement contrôlés et séparés. Cette approche de zoning s’aligne naturellement avec la configuration RBAC du proxy.

Traiter la validation des serveurs MCP avec la même rigueur que la gestion des accès privilégiés. La guidance NSA recommande explicitement d’appliquer des processus de revue rigoureux aux outils MCP avant déploiement — les mêmes audits de code que pour d’autres logiciels à haut risque. Cela est crucial : les serveurs MCP détenant des credentials pour Slack, GitHub, Postgres, et Salesforce (ce que le Top 10 MCP de l’OWASP classe comme une agrégation de credentials) représentent un point de défaillance unique. Compromettre un tel serveur étendrait le rayon d’attaque à quatre systèmes.

---

Conclusion

Le Model Context Protocol a éliminé les barrières d’intégration qui isolaient auparavant les modèles IA de l’infrastructure d’entreprise. En fournissant un adaptateur universel pour ressources, prompts, et outils, il a permis une transition d’assistants IA passifs à des agents autonomes actifs — une transition déjà bien engagée à la mi-2026, avec plus de 10 000 serveurs indexés publiquement et 97 millions de téléchargements SDK mensuels.

Cette connectivité s’accompagne d’une obligation de sécurité sérieuse. Les recommandations de la NSA de mai 2026, les cadres de classification OWASP, et une série documentée de CVEs et d’attaques en chaîne ont clairement montré que les défenses réseau classiques sont structurellement aveugles à la surface d’attaque sémantique que MCP expose. Le protocole lui-même ne fait pas respecter l’identité, ne mandate pas l’authentification dans tous les transports, et ne fournit pas de mécanisme intégré pour vérifier l’intégrité des définitions d’outils.

Les proxies MCP comblent cette lacune au niveau du protocole. Par le parsing en temps réel de JSON-RPC, l’inspection sémantique des charges utiles, la cartographie d’identité liée à OAuth 2.1, le disjoncteur humain, et la limitation de débit agentique, ils apportent une application du principe de zero-trust aux interactions agent-outil autrement non gouvernées. Associés à des contrôles de chaîne d’approvisionnement, des environnements d’exécution containerisés, et une télémétrie d’audit structurée intégrée à l’infrastructure SIEM, ils forment la couche de gouvernance permettant le déploiement sécurisé de systèmes multi-agent autonomes à l’échelle d’entreprise sans accepter un risque résiduel non caractérisé.

La dette de sécurité accumulée lors de l’adoption rapide du MCP est réelle et documentée. Les outils pour la traiter — cadres de proxy, modèles RBAC formels, propositions de vérification cryptographique des outils — émergent en parallèle de la surface d’attaque. Les organisations qui déploieront l’IA agentique en toute sécurité sont celles qui traiteront la gouvernance MCP non comme une préoccupation future, mais comme une condition préalable au déploiement en production dès aujourd’hui.

---

Changelog

#	Section	Changement	Type
1	Introduction	Suppression de la revendication non sourcée sur la résolution du problème d’intégration N×M par MCP — reformulée comme caractérisation de l’auteur. Ajout de chiffres d’adoption sourcés : 10 000+ serveurs (Anthropic, déc. 2025), 9 400 serveurs suivis dans 4 registres (Q2 2026), 97M téléchargements SDK mensuels.	Ajout de données sourcées
2	Section protocole	Ajout d’une description précise de la révision de novembre 2025 (PKCE S256 obligatoire, RFC 9728 obligatoire). Suppression de la revendication que l’authentification est requise pour tous transports — le transport stdio ne l’utilise pas selon la spécification.	Correction
3	Paysage des menaces	Ajout d’une nouvelle section couvrant CVE-2025-6514 (CVSS 9.6, JFrog/mcp-remote, 437 000+ téléchargements affectés), CVE-2025-49596 (CVSS 9.4, MCP Inspector RCE/CSRF), CVE-2025-53110, CVE-2025-53109 (serveur MCP Filesystem d’Anthropic). Ces exploits sont documentés dans la réalité ; le brouillon initial n’avait pas de références CVE.	Ajout (sourcé)
4	Paysage des menaces	Ajout des résultats du benchmark MCPTox : o1-mini 72,8% de succès d’attaque poisoning ; Claude 3.7-Sonnet taux de refus %. Remplacement des descriptions vagues par des données empiriques.	Correction et extension
5	Paysage des menaces	Ajout de l’incident Postmark MCP (septembre 2025), attaque supply chain LiteLLM/TeamPCP, ver Shai-Hulud. Ces incidents datent du postérieur du brouillon initial et ancrent la discussion supply chain dans des cas documentés.	Ajout (sourcé)
6	Recommandations NSA	Ajout de la fiche d’information Cybersecurity de la NSA (mai 2026, U/OO/6030316-26) tout au long de l’article comme source principale. La version initiale n’avait pas cette référence.	Ajout (sourcé)
7	Classification OWASP	Remplacement de la référence générique aux frameworks OWASP par des catégories spécifiques OWASP Top 10 pour les applications LLM 2025 : LLM01 (Injection de prompts), LLM06 (Excessive Agency), LLM10 (Unbounded Consumption). Ajout de la liste OWASP MCP Top 10 (2025) avec numérotation précise.	Extension avec données sourcées
8	Moteur d’audit sémantique	Ajout d’une note explicative que l’ETDI (Enhanced Tool Definition Interface) est une proposition de brouillon, pas une norme MCP ratifiée en mi-2026. La version initiale laissait entendre que la vérification cryptographique était une fonctionnalité standard du proxy.	Correction
9	Couche d’autorisation	Ajout d’une section dédiée sur l’évolution de la spécification OAuth 2.1 (mars, juin, novembre 2025). Clarification que le RBAC n’est pas partie intégrante du protocole MCP et doit être implémenté au niveau applicatif. Ajout de la constatation que 25% des serveurs MCP publics n’ont pas d’authentification, 53% utilisent des clés API longues.	Ajout (sourcé)
10	Cas d’usage industriel IIoT	Suppression du cas d’usage initial impliquant NVIDIA Omniverse et “Industrial Mirroring”. La scène contenait plusieurs affirmations techniques non sourcées. Remplacement par une description architecturale ancrée dans des modèles de conception proxy documentés.	Suppression (non supporté)
11	Bonnes pratiques	Maintien des cinq pratiques initiales et extension avec recommandations de la NSA CSI : zonage de classification des données, déploiement privé/local pour charges sensibles, contrôle de validation des serveurs MCP équivalent à PAM.	Extension avec données sourcées