Construire une architecture MCP sécurisée et évolutive : durcissement du Model Context Protocol du dépôt à l'exécution

La sécurité et l’évolutivité ne se réalisent pas en production ; elles se conçoivent dès le premier commit.

Pourquoi un MCP « sécurisé et évolutif » est une discipline à part entière

Le Model Context Protocol (MCP) change la nature du risque applicatif. Les applications traditionnelles gèrent déjà l’identité, les secrets et l’accès aux données — mais le MCP ajoute une couche : l’orchestration du contexte. Le système n’est plus seulement du code appelant des API. C’est une chaîne d’outils, de prompts, de sources de récupération et d’appels de fonctions qui peut être amenée à se comporter différemment sous des entrées adverses ou simplement mal formées.

Une architecture MCP robuste considère le contexte comme un actif gouverné. Cela signifie qu’il faut sécuriser :

• Comment le contexte est sélectionné (ce qui est inclus ou exclu)
• Comment le contexte est transporté (entre client, serveur et outils)
• Comment le contexte est exécuté (appels d’outils, effets de bord et opérations d’écriture)
• Comment le contexte est audité (qui a demandé, qu’est-ce qui a été utilisé, ce qui s’est passé)

Et il faut faire cela tout en évoluant horizontalement, à travers des repositories et des équipes — sans transformer vos serveurs MCP en « boîtes magiques » que personne ne peut comprendre.

Cet article se concentre concrètement sur les repositories MCP et l’architecture de niveau production autour d’eux : identité, frontières des outils, secrets, politique, observabilité et contrôles de la chaîne d’approvisionnement.

Commencez par le modèle de menace : ce qui peut mal tourner dans les systèmes MCP

Un design MCP sécurisé commence par nommer les modes de défaillance en langage clair. En pratique, la plupart des incidents se regroupent en quelques catégories :

Abus liés aux prompts et au contexte

• Injection de contexte via des documents non fiables, pages web, commentaires d’issues ou messages de chat qui modifient le comportement des outils.
• Coercition d’outil lorsque le modèle est amené à appeler un outil privilégié (« delete », « refund », « rotate keys ») ou à exfiltrer des données sensibles.
• Fuite inter-locataires lorsque des index de récupération, des caches ou des logs mélangent accidentellement des locataires.

Dérive d’identité et d’accès

• Tokens trop permissifs dans les adaptateurs d’outils.
• Un « compte de service » partagé sans traçabilité par utilisateur.
• Absence de contrôles d’autorisation parce que le modèle « décide » quoi appeler.

Compromission de la chaîne d’approvisionnement

• Mises à jour malveillantes des dépendances dans les repos du serveur MCP.
• Images de conteneur ou images de base non sûres.
• Définitions d’outils non revues qui élargissent secrètement les capacités.

Risque opérationnel à l’échelle

• Absence de limitation de débit, entraînant des explosions de coûts et des dénis de portefeuille.
• Mauvaise observabilité rendant impossible la reconstruction des chaînes d’appels d’outils.
• Pas de rollback sûr des versions d’outils, des prompts ou des règles de récupération.

Votre posture de sécurité s’améliore rapidement lorsque vous considérez le MCP comme un système distribué avec des frontières de confiance explicites, et non comme une simple couche d’intégration astucieuse.

Base architecturale : séparer le plan de contrôle du plan de données

Une architecture MCP évolutive profite d’une séparation :

• Plan de contrôle : politique, mapping d’identité, registre d’outils, versioning, approbations et distribution de configuration.
• Plan de données : serveurs MCP d’exécution et exécutants d’outils qui gèrent le trafic utilisateur et le traitement du contexte.

C’est un modèle connu des API gateways et des service meshes. L’important est d’éviter la « politique dispersée dans le code ». Au contraire, vous souhaitez une politique définie de manière centralisée et appliquée au runtime via des hooks cohérents.

Disposition de référence minimale pour les repositories MCP

Une topologie de repo commune pour les projets MCP qui veulent monter en charge à travers de nombreux outils ressemble à ceci :

• mcp-server/
  • transport (stdio/http), middleware d’auth, validation des requêtes
  • dispatcher d’outils et couche de sandbox des outils
• tools/
  • implémentations d’outils groupées par domaine (crm/, billing/, infra/)
  • déclarations de capacité des outils (schema, scopes, effets de bord)
• policies/
  • règles d’accès par locataire, rôle, environnement, classification des données
  • allowlists/denylists pour l’invocation d’outils
• prompts/
  • system prompts, instructions d’outil, contraintes de sécurité
  • versionnés, revus en code review, testés comme du code
• infra/
  • IaC pour le déploiement, les secrets, la politique réseau, le logging, les métriques
• tests/
  • tests unitaires pour les outils
  • tests de contrat pour le schema des outils
  • tests adversariaux pour injection et fuite de données

Cette structure crée de la friction aux bons endroits : les définitions d’outils ne peuvent pas glisser en production sans revue, et la politique n’est pas enterrée dans l’implémentation.

Identité d’abord : authentifier le client, puis lier les appels d’outils à un acteur

Le MCP se situe souvent entre un client (IDE, agent desktop, portail interne) et des systèmes privilégiés (hébergement Git, consoles cloud, systèmes de ticketing). Si vous ne liez pas les appels à une identité réelle, vous perdez la possibilité d’appliquer le principe du moindre privilège.

Modèle d’identité recommandé

1. Authentification du client : le client MCP s’authentifie auprès de votre serveur MCP en utilisant OIDC (préféré), mTLS ou des tokens signés à courte durée.
2. Binding de l’acteur : chaque requête est associée à :
   • identité utilisateur (humaine) ou identité de charge de travail (service)
   • frontière locataire/organisation
   • id de session et id de corrélation
3. Autorisation déléguée : les appels d’outils :
   • s’exécutent avec un token délégué contraint pour l’utilisateur, ou
   • s’exécutent avec un token de service mais avec une autorisation stricte par utilisateur appliquée côté serveur.

La première approche (délégation) est généralement plus sûre. La seconde peut être nécessaire pour des systèmes legacy, mais elle exige des contrôles côté serveur et des logs infaillibles.

Ne faites pas confiance au modèle pour l’autorisation

L’autorisation doit être appliquée dans le dispatcher d’outils du serveur MCP, pas à l’intérieur du texte des prompts. Les règles de prompt sont utiles, mais elles ne constituent pas une mesure coercitive. Vous voulez une porte dure :

• Valider que l’outil est autorisé pour l’acteur, le locataire et l’environnement.
• Valider les paramètres (types, plages, enums autorisés).
• Exiger une approbation supplémentaire pour les effets de bord à haut risque.

Frontières des outils : définir des « capacités », pas seulement des fonctions

Dans le MCP, les « outils » sont les bords tranchants. C’est là que le modèle peut provoquer des effets de bord, lire des données sensibles ou déclencher des workflows. Une architecture évolutive considère chaque outil comme une capacité avec :

• Périmètre : ce à quoi il peut accéder (systèmes, objets, champs)
• Niveau d’effet de bord : lecture seule, écriture, destructif, financier, administration privilégiée
• Classification des données : public, interne, confidentiel, régulé
• Classe de débit et de quota : bon marché, coûteux, en rafale, lent
• Mode d’approbation : auto, confirmation utilisateur, revue à deux personnes, fenêtre de changement

Un repository MCP mature code ceci dans un format lisible par machine à côté du schema de l’outil. Le schema seul ne suffit pas — vous avez besoin de métadonnées pour piloter la politique.

Une taxonomie pratique des risques des outils

• Tier 0 (safe) : formatage, calculs, parsing local, pas de réseau
• Tier 1 (read-only) : recherche, récupération de docs non sensibles, APIs publiques
• Tier 2 (sensitive read) : tickets internes, infos clients, recherche de code dans des repos privés
• Tier 3 (write) : création de tickets, ouverture de PR, modification d’enregistrements
• Tier 4 (destructive/privileged) : suppression, désactivation, rotation de credentials, changements en production

Chaque niveau correspond à des contrôles renforcés : validation, confirmation, approbations et sandboxing au runtime.

Gestion sécurisée du contexte : considérer la récupération comme un canal d’entrée non fiable

Les flux augmentés par récupération peuvent devenir silencieusement votre plus grande surface d’attaque. Les documents peuvent contenir des instructions, des secrets intégrés ou du contenu conçu pour provoquer un mauvais usage des outils.

Contrôles d’hygiène du contexte qui montent en charge

• Provenance des documents : stocker la source, l’auteur, l’horodatage et un score de confiance dans les métadonnées.
• Partitionnement des index : isoler les locataires et les environnements ; ne jamais mélanger staging et prod.
• Filtrage du contenu :
  • supprimer les extraits exécutables quand ils ne sont pas nécessaires
  • rediger les secrets évidents avant l’indexation
  • ignorer les sections « instructionnelles » provenant de sources non fiables
• Budgets de contexte : limiter la quantité de contenu récupéré pouvant être incluse et préférer des résumés de sources de confiance.
• Récupération basée sur la politique : les résultats de récupération doivent être filtrés par le même modèle d’accès que les outils.

Un pattern subtil mais important : faire de la récupération un outil avec une autorisation explicite. « Search the knowledge base » n’est pas neutre si la base de connaissances contient des runbooks confidentiels.

Secrets : les retirer des repos, puis les retirer de la mémoire des outils

Les repositories MCP sont souvent compromis à l’ancienne : identifiants dans des fichiers d’environnement, tokens fuités dans les logs CI, ou clés API codées en dur laissées « temporairement » dans le code.

Posture de base pour les secrets dans les repos MCP

• Utiliser un vrai gestionnaire de secrets (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).
• Appliquer des credentials à courte durée (OIDC vers le cloud, creds DB dynamiques).
• Ne jamais permettre aux outils de renvoyer des secrets en clair à moins que l’acteur soit explicitement autorisé et que l’événement soit audité.
• Configurer le logging pour rédiger les credentials et champs sensibles à l’ingestion.

Une erreur fréquente : un outil récupère un secret pour appeler une API, et le modèle voit le secret dans la sortie de l’outil ou dans des logs verbeux. Les outils ne doivent jamais retourner des credentials bruts ; ils doivent retourner uniquement un statut.

Isolement réseau et runtime : supposer que chaque outil sera éventuellement abusé

Un runtime MCP évolutif est généralement conteneurisé. C’est bien, mais seulement si vous utilisez l’isolation pour laquelle vous payez déjà.

Contrôles runtime importants

• Politique d’egress : les outils ne doivent contacter que des hôtes connus ; deny-by-default pour le trafic sortant.
• Politiques réseau par outil : les outils de facturation ne devraient pas accéder aux endpoints d’infrastructure.
• Contraintes système de fichiers : root FS en lecture seule ; montages écrits explicites.
• Sandboxing pour les outils à haut risque : pools de workers séparés pour les outils Tier 3/4.
• Limites de ressources : plafonds CPU/mémoire pour éviter l’exécution incontrôlée.

L’objectif est de rendre l’abus survivable. Lorsqu’un outil est contraint de faire quelque chose de stupide, le rayon d’impact doit être faible.

Moteur de politique : centraliser l’autorisation et les verrous de sécurité

Pour monter en charge, vous avez besoin d’une couche de politique qui soit :

• cohérente (mêmes règles partout),
• auditable (qui a modifié quoi, quand),
• testable (tests unitaires pour la politique),
• déployable (versionnée, avec rollbacks).

Beaucoup d’équipes adoptent une approche policy-as-code (ex. OPA/Rego ou Cedar). Le moteur exact importe moins que ces propriétés :

• Les outils déclarent des capacités et les scopes requis.
• Les requêtes arrivent avec l’identité de l’acteur et le contexte (locataire, env, sensibilité).
• La politique décide : allow/deny/allow-with-conditions.

Approbations conditionnelles et contrôles de step-up

Les opérations à haut risque ne devraient pas être bloquées indéfiniment, mais elles doivent être filtrées :

• Confirmation utilisateur : présenter un diff lisible par un humain ou un résumé de l’action.
• Step-up auth : exiger une ré-authentification pour les actions destructrices.
• Règle à deux personnes : pour les changements en production, exiger un second approbateur.
• Fenêtres de changement : autoriser les outils Tier 4 uniquement pendant des périodes planifiées.

Ces contrôles sont normaux sur les plateformes d’infrastructure ; le MCP a juste besoin qu’ils existent dans le dispatcher d’outils.

Tester les repositories MCP comme du code critique pour la sécurité

Les repos MCP ne doivent pas se contenter d’un « ça a l’air correct dans le chat ». Vous voulez une couverture automatisée pour les modes de défaillance qui vous font réellement peur.

Ce qu’il faut tester (et comment)

• Tests de contrat de schema : les outils font respecter les types et rejettent les champs inattendus.
• Tests d’autorisation : deny-by-default ; vérifier le moindre privilège par rôle.
• Tests d’injection : fournir des documents récupérés contenant du contenu adversaire et vérifier que le système refuse d’élever les privilèges.
• Tests de rédaction : s’assurer que les champs sensibles n’apparaissent jamais dans la sortie des outils ou les logs.
• Tests de replay : enregistrer une session et vérifier les décisions de politique déterministes sur les appels d’outils.

Un pattern productif est de conserver un corpus de « mauvais documents » dans le repo : extraits conçus pour manipuler l’utilisation des outils, demander des secrets ou outrepasser le comportement système. Les tests doivent affirmer que le dispatcher d’outils applique la politique indépendamment du texte.

Versioning et discipline de release : monter en charge en rendant les changements sûrs

Les systèmes MCP évoluent vite : nouveaux outils, nouvelles instructions de prompt, nouvelles sources de récupération. Sans discipline de release, vous obtenez de la dérive et des régressions silencieuses.

Versionner tout ce qui peut changer le comportement

• Schemas d’outils et métadonnées de capacité
• Bundles de politique
• Templates de prompts et règles système
• Configuration de récupération (index, filtres, réglages de ranking)
• Seuils de sécurité et patterns de rédaction

Vous voulez aussi des garanties de compatibilité. Si un client se fixe sur v1 d’un schema d’outil, le serveur doit l’honorer ou négocier explicitement.

Pipeline de promotion par environnement

Une architecture sécurisée et évolutive promeut les changements :

1. dev (itération rapide, données synthétiques)
2. staging (vraies intégrations, portée restreinte)
3. prod (politique stricte, approbations, audit)

Chaque étape doit avoir des valeurs par défaut de politique différentes et des allowlists d’outils différentes. Il est normal que le staging permette plus d’introspection tandis que la prod est verrouillée.

Observabilité : reconstruire la chaîne sans logger des secrets

L’observabilité MCP n’est pas seulement latence et taux d’erreur. Vous devez pouvoir répondre à :

• Qui a invoqué quel outil ?
• Avec quels paramètres (rédigés) ?
• Quelles sources de données ont été récupérées ?
• Quelle décision de politique a été appliquée ?
• Quels effets secondaires ont eu lieu dans les systèmes externes ?

Cela nécessite des logs d’événements structurés avec des IDs cohérents.

Jeu minimal de télémétrie viable

• Request id, session id, actor id, tenant id
• Nom de l’outil, version de l’outil, tier de capacité
• Décision de politique (allow/deny/conditions)
• Hachages de paramètres ou carte de paramètres rédigée
• Métadonnées d’appels externes (hôte, classe d’endpoint, durée, statut)
• Sources de récupération et IDs de documents (pas le contenu brut)

Un bénéfice surprenant : une bonne télémétrie facilite grandement la gestion des coûts. Vous pouvez voir quels outils entraînent des appels modèles coûteux, quels locataires génèrent la charge, et où le caching est sûr.

_{Photo by Microsoft Copilot on Unsplash}

Stratégies de montée en charge : quand un serveur MCP devient plusieurs

Un seul serveur MCP peut suffire pour de petits outils internes, mais la montée en charge introduit de nouvelles contraintes : concurrence, voisins bruyants, quotas par locataire et propriété opérationnelle.

Mise à l’échelle horizontale sans perdre la gouvernance

Pour monter en charge les runtimes MCP, préférez des serveurs stateless :

• Stocker l’état de session dans un store partagé si nécessaire (mais le garder minimal).
• Mettre les politiques et registres d’outils dans un magasin de config distribué.
• Utiliser une file pour les tâches longues ou à haut risque.

Appliquez ensuite une séparation des charges de travail :

• Gateway MCP frontale : auth, routage, vérifications de politique, shaping des requêtes
• Pools d’exécution d’outils : séparés par tier de risque
• Services de récupération : isolés, partitionnés par locataire, avec ACL strictes

Cela vous permet d’échelonner le hot path (gateway) différemment du slow path (exécution). Cela permet aussi des contrôles plus stricts pour les outils Tier 3/4 sans pénaliser les appels Tier 1.

Limitation de débit et quotas comme contrôles de première classe

Le déni de portefeuille est réel dans le MCP. Vous avez besoin de :

• Limites de requêtes par locataire
• Quotas d’appels d’outils par utilisateur
• Limites de concurrence par outil
• Alarmes de budget et coupe-circuits

Les quotas doivent être appliqués avant les appels modèles coûteux quand c’est possible. Par exemple, rejeter un appel d’outil à haut risque tôt plutôt que de générer d’abord un long plan.

Gouvernance des données : classification, résidence et rétention

Le MCP touche souvent des données sensibles indirectement : documents récupérés, pièces jointes de tickets, code interne, dossiers clients. La gouvernance n’est pas optionnelle, surtout à l’échelle.

Appliquer la classification de bout en bout

• Étiqueter les sources et documents avec une classification.
• Étiqueter les outils avec ce qu’ils peuvent accéder et ce qu’ils peuvent produire.
• Faire respecter le « no downgrade » : des entrées confidentielles ne doivent pas produire des sorties publiques sans exception politique explicite.

Règles de rétention pour les logs et traces MCP

Les logs peuvent devenir un magasin d’ombre. Définir la rétention par environnement et par classe de données :

• Conserver les logs opérationnels minimaux pour la période la plus courte nécessaire.
• Stocker les traces sensibles seulement quand nécessaire, avec accès restreint.
• Supporter des workflows « supprimer mes données » quand applicable.

Cela exige de la discipline aussi dans les repositories : ne pas stocker des transcriptions de conversations comme fixtures de test si elles contiennent des données réelles.

Sécurité de la chaîne d’approvisionnement pour les repositories MCP

Les repos MCP sont des cibles attractives car ils se situent près des credentials, des intégrations et de l’automatisation. Une compromission de la chaîne d’approvisionnement peut transformer silencieusement des outils en portes dérobées.

Mesures pratiques de durcissement des repos

• Exiger des commits signés pour les branches critiques.
• Demander des revues de code owners pour :
  • métadonnées de capacité des outils
  • bundles de politique
  • middleware d’auth et de logging
• Verrouiller les dépendances et utiliser des lockfiles.
• Lancer SAST et scans de dépendances à chaque PR.
• Construire des conteneurs à partir d’images de base minimales ; scanner les images dans le CI.
• Conserver la provenance de build (métadonnées style SLSA) si votre org le supporte.

Traitez les définitions d’outils comme des changements d’infrastructure. Une mise à jour d’une ligne de schema peut élargir l’accès plus que cent lignes de code.

Composants produit qui apparaissent couramment dans les stacks MCP sécurisés

Différentes équipes assemblent des architectures MCP à partir d’un ensemble de blocs de construction. Voici des composants courants, décrits par leur rôle plutôt que par des promesses marketing.

1. Policy engine (OPA/Cedar)
   Décisions centralisées allow/deny basées sur l’identité de l’acteur, le tier d’outil, le locataire et l’environnement ; politiques versionnées et testables.

2. Secrets manager (Vault/Cloud secrets)
   Credentials à courte durée, logs d’audit pour l’accès aux secrets et rotation automatique ; réduit la prolifération de credentials dans les repos MCP.

3. API gateway/service mesh
   mTLS, shaping des requêtes, limites de débit et télémétrie cohérente à travers les serveurs MCP et les pools d’exécution d’outils.

4. Vector database with tenant partitioning
   Récupération avec frontières d’accès strictes, filtres de métadonnées et contrôles de rétention ; critique pour empêcher les fuites inter-locataires.

5. SIEM + structured logging pipeline
   Corrélation d’événements centrale pour les appels d’outils, décisions de politique et effets secondaires externes — sans stocker le contexte sensible brut.

6. Container runtime sandboxing (gVisor/Kata)
   Isolation renforcée pour les outils à haut risque ; réduit le rayon d’impact lorsqu’un outil est contraint de faire des actions nuisibles.

Playbooks opérationnels : réponse aux incidents pour les systèmes pilotés par des outils

Quand quelque chose tourne mal dans le MCP, cela ressemble souvent à « l’assistant a fait une chose ». Une architecture évolutive rend cette « chose » traçable et réversible.

Ce dont vous avez besoin prêt avant l’incident

• Un kill switch pour désactiver un outil globalement ou par locataire.
• Un moyen de rollback rapide des versions d’outils et des bundles de politique.
• Une piste d’audit qui lie les appels d’outils aux acteurs et aux sessions.
• Un mode quarantaine pour les sources de récupération (arrêter l’indexation, arrêter la distribution).
• Backpressure et coupe-circuits pour arrêter les cascades.

Flux d’incident typiques

• Exfiltration suspectée : désactiver les outils de lecture sensibles (Tier 2), renforcer la rédaction, faire pivoter les credentials compromis, vérifier les logs pour des patterns de récupération anormaux.
• Écritures non autorisées : désactiver les pools Tier 3/4, activer les confirmations obligatoires, vérifier que les bundles de politique et les schemas d’outils n’ont pas été modifiés.
• Alerte chaîne d’approvisionnement : geler les déploiements, vérifier la provenance des builds, verrouiller les mises à jour de dépendances et reconstruire à partir de commits connus bons.

La différence entre une mauvaise journée et une crise est souvent de pouvoir désactiver un outil en quelques secondes sans redéployer tout le système.

Concevoir pour le contrôle humain sans briser la vélocité des développeurs

La tentation dans le MCP est soit tout verrouiller (et tuer l’utilité), soit tout autoriser (et accepter le chaos). Le compromis durable est le contrôle gradué.

Un modèle de gouvernance praticable

• Les développeurs peuvent ajouter des outils Tier 0/1 avec une revue standard.
• Les outils Tier 2 nécessitent une revue sécurité et des déclarations de périmètre explicites.
• Les outils Tier 3/4 exigent :
  • un workflow d’approbation
  • isolation au runtime
  • champs d’observabilité obligatoires
  • ownership on-call

Ce modèle monte en charge parce qu’il adapte les contrôles au risque. Il crée aussi un chemin clair : prototyper en Tier 1, puis promouvoir avec des garde-fous supplémentaires.

Faire du « sécurisé » le défaut dans les templates

Si vous fournissez des templates internes de repo MCP, intégrez :

• politiques deny-by-default
• logging structuré avec rédaction
• helpers de validation d’entrée
• scaffolding de métadonnées de capacité
• harness de tests pour injection et autorisation

Les équipes vont plus vite lorsque la voie sécurisée est aussi la voie la plus facile.

L’architecture qui tient sous pression

Une architecture MCP sécurisée et évolutive n’est pas un modèle unique, mais elle présente des traits récurrents :

• requêtes liées à une identité et autorisation déléguée
• outils traités comme des capacités avec contrôles de risque par niveau
• politique centralisée, versionnée et appliquée dans le dispatcher
• récupération traitée comme une entrée non fiable avec provenance et partitionnement
• secrets gérés par credentials à courte durée et rédaction stricte
• isolation runtime, contrôles d’egress réseau et limites de ressources
• observabilité conçue pour la reconstruction sans fuite de données
• contrôles de la chaîne d’approvisionnement appliqués aux définitions d’outils et aux politiques aussi sérieusement qu’au code

Lorsque vous bâtissez le MCP de cette manière, le système reste compréhensible même lorsque les repositories se multiplient, les outils prolifèrent et le trafic augmente. Voilà le vrai test de l’échelle : pas seulement gérer plus de requêtes, mais rester gouvernable quand le contexte, le code et l’organisation changent tous en même temps.

External Links

Build Secure and Scalable MCP Servers | Blogpost How to build secure and scalable remote MCP servers Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP Scaling MCP: A simpler, safer enterprise architecture - Cloudflare TV How to Design Secure MCP Deployments - Curity at Platform Summit 2025 | Videos

External References

• Policy engine OPA Cedar
• manager Vault Cloud secrets
• API gateway service mesh
• with tenant partitioning
• structured logging pipeline
• runtime sandboxing gVisor Kata