Model Context Protocol en production : quels outils votre serveur MCP expose, à quel agent, avec quelle authentification

Le serveur qui marchait sur un poste devient un service partagé : la question n'est plus s'il fonctionne, mais ce qu'il laisse invoquer. Dès que plusieurs agents ou plusieurs équipes s'y connectent, la surface de contrôle change de nature. Ce qui suit décrit les mécanismes disponibles aujourd'hui pour sécuriser un serveur MCP en production, les traces qu'ils produisent, et les limites qu'il faut nommer avant de signer.

Qu'est-ce qu'un serveur MCP expose exactement ?

Trois types de capacités : les outils (tools), les prompts et les ressources. Les outils sont ceux qui exécutent.

Un serveur MCP, au sens du Model Context Protocol (MCP), est un processus qui répond à des requêtes structurées d'un client : il annonce ses capacités, puis les exécute à la demande. La liste des trois vient de la spécification, révision du 28 juillet 2026.

Ce que la spécification dit sans détour sur les outils :

Et sur la confiance accordée à leurs descriptions :

La surface exposée n'est donc pas de la donnée au repos : c'est de l'exécution à la demande, déclenchée par un agent sur la base d'une description que le protocole lui-même déclare non fiable par défaut.

┌─────────────┐     ┌──────────────────┐     ┌──────────────────────┐     ┌──────────────────────┐
│  Client MCP │────▶│  Serveur MCP     │────▶│  Outils / Prompts /  │────▶│  Systèmes en aval    │
│  (agent)    │     │  (endpoint HTTP) │     │  Ressources exposés  │     │  (API, BDD, SaaS)    │
└─────────────┘     └──────────────────┘     └──────────────────────┘     └──────────────────────┘
                                                        ↑
                                    Ce qui est exposé n'est pas de la donnée,
                                              c'est de l'exécution.

Comment savoir ce qui est déjà en place ?

Avant tout contrôle, un inventaire en lecture seule : sans lui, toute politique s'applique à une surface inconnue.

Quatre questions structurent cet inventaire :

1. Quels serveurs MCP sont accessibles dans l'organisation, et sur quels endpoints ?
2. Quels outils chaque serveur expose-t-il, et avec quelle description ?
3. Quels clients s'y connectent : agents automatisés, postes de développeurs, chaînes d'intégration continue ?
4. Où vivent les identifiants d'administration utilisés pour synchroniser les capacités ?

Appliquer une politique d'accès sur un serveur dont on ignore la liste d'outils revient à fermer une porte sans savoir ce qu'elle protège. Un audit de configuration Cloudflare établit cet état des lieux avant d'engager la moindre modification.

Comment placer un serveur MCP derrière une authentification ?

Deux montages sont disponibles, et le critère qui les sépare est celui de la documentation : qui gère le code du serveur, et qui gère son nom d'hôte.

Tableau 1 · Deux montages d'authentification (source : Cloudflare, page du 9 juillet 2026)

Ce piège mérite d'être détaillé, parce qu'il ne se manifeste pas comme une erreur. Managed OAuth ne doit être activé que pour un serveur MCP qui valide effectivement le JWT Access que Cloudflare lui transmet. Sur un code tiers que vous ne pouvez pas modifier, garder le flux OAuth natif du serveur est la seule option tenable.

Double autorisation par token de service

Pour les accès automatisés, le portail de serveurs MCP accepte les tokens de service Access. Deux contrôles sont requis simultanément :

1. Une politique Service Auth sur l'application Access du portail lui-même.
2. Une politique Service Auth sur chaque serveur MCP amont atteint par ce portail.

Deux conséquences directes :

• Un serveur sans politique Service Auth correspondante est masqué de la liste d'outils présentée au robot : il n'apparaît pas, il ne peut pas être appelé.
• Un serveur configuré avec on_behalf: true est exclu des sessions par token de service, parce que ce mode exige une autorisation OAuth par utilisateur réel.

Le token de service ne vaut d'ailleurs que pour un serveur placé derrière Access. Si le serveur porte son propre OAuth, c'est ce flux qui fait autorité et le token n'intervient pas. Au-delà du montage, l'identité de l'agent et son rayon d'action relèvent de la gouvernance des identités non humaines.

Comment réduire ce qu'un agent peut invoquer ?

Avec un portail de serveurs MCP : l'administrateur y choisit outil par outil ce qui reste appelable.

Le portail centralise plusieurs serveurs sur un endpoint HTTP unique (https://<sous-domaine>.<domaine>/mcp), et la politique s'attache au portail plutôt qu'à chaque serveur.

Curation des outils

Par défaut, tous les outils d'un serveur ajouté au portail sont disponibles. L'administrateur peut les désactiver individuellement : un outil désactivé n'apparaît pas dans la liste présentée à l'agent et ne peut pas être invoqué.

Pour inverser la logique et passer en liste d'autorisation explicite, l'API accepte default_disabled: true sur l'association serveur-portail, puis l'énumération des seuls outils autorisés dans updated_tools :

{
  "servers": [
    {
      "id": "example-server",
      "default_disabled": true,
      "updated_tools": [
        { "name": "search_documents", "enabled": true },
        { "name": "list_projects", "enabled": true }
      ]
    }
  ]
}

Ce fragment est fourni à titre illustratif. Adaptez les identifiants à votre configuration et testez en préproduction avant tout déploiement.

C'est le moindre privilège appliqué au niveau où le protocole travaille : l'agent ne voit que ce que l'administrateur a explicitement autorisé.

Alias

Les outils et les prompts peuvent être renommés au niveau du portail sans toucher au serveur amont. Un alias fait 1 à 40 caractères et suit le motif ^[a-zA-Z0-9]+([_-][a-zA-Z0-9]+)*$. La précédence est portal_alias > server_alias > alias > nom d'origine. C'est aussi le moyen de réécrire une description fournie par un tiers, ce que la spécification invite justement à ne pas prendre pour argent comptant.

Code Mode

Code Mode remplace les définitions d'outils amont par deux outils : un outil de recherche et un outil d'exécution de code, dans un environnement Dynamic Worker isolé. Les identifiants restent hors du contexte du modèle. Quatre politiques sont disponibles : off, opt_in (défaut), default_on, enforced.

Un portail accepte jusqu'à 40 serveurs MCP, avec un avertissement affiché à l'approche de la limite.

Avant et après le portail

AVANT (sans portail)
─────────────────────────────────────────────────────────
Client A ──▶ Serveur 1   Client B ──▶ Serveur 2   Client C ──▶ Serveur 3
Client A ──▶ Serveur 2   Client B ──▶ Serveur 3
Client A ──▶ Serveur 3
→ chemins directs, aucune politique commune

APRÈS (avec portail)
─────────────────────────────────────────────────────────
Client A ─┐
Client B ─┼──▶ Endpoint portail ──▶ Politique par portail ──▶ Outils curés ──▶ Serveur 1
Client C ─┘         /mcp                                                   ──▶ Serveur 2
                                                                           ──▶ Serveur 3
→ 1 endpoint, politique centralisée, surface réduite

Quelles traces reste-t-il après un appel d'outil ?

Le portail journalise chaque appel. Le niveau de détail dépend du mode d'accès aux journaux.

Tableau 2 · Ce que les journaux du portail MCP contiennent

L'export Logpush du jeu mcp_portal_logs est disponible sur les plans Enterprise uniquement. C'est lui, et lui seul, qui répond à la question « qui a appelé quel outil, quand ». La vue du tableau de bord suffit à diagnostiquer une panne, pas à conduire une revue d'accès. Ces journaux contiennent des données personnelles, leur durée de conservation est donc un sujet RGPD à trancher avant de brancher l'export.

AI Gateway et l'identité dans les journaux

AI Gateway ajoute l'identité de l'utilisateur nativement dans un seul cas : quand la requête l'atteint par un domaine personnalisé protégé par Cloudflare Access. Le champ cf.user_id contient alors la valeur du claim sub du JWT Access vérifié, et non l'adresse électronique.

Les requêtes par token de service, et celles sans sujet utilisateur, ne reçoivent pas cf.user_id. Pour un agent qui s'authentifie par token de service, l'attribution passe donc par les métadonnées personnalisées, plafonnées à cinq entrées par requête, les suivantes étant ignorées. Les clés commençant par cf. sont réservées et retirées si le client les envoie. La visibilité sur chaque appel de modèle se construit à la conception, elle ne s'hérite pas.

Par où passe le trafic, et par où il ne passe pas

Le routage du trafic de portail par Cloudflare Gateway est optionnel, et c'est lui qui décide de ce que vous verrez.

Quand le routage Gateway est activé :

• Les appels vers les serveurs amont passent par Gateway, apparaissent dans les journaux HTTP et sont soumis aux politiques de prévention de perte de données, ce qui permet de détecter les données sensibles avant qu'elles ne sortent.
• Les requêtes sortantes peuvent utiliser des IP de sortie dédiées ou les plages Gateway, ce qui rend le portail acceptable pour un serveur amont qui filtre par IP source.
• Le portail termine la connexion du client MCP et réémet la requête : Gateway déchiffre et inspecte automatiquement ce trafic, sans qu'il soit nécessaire d'activer le déchiffrement TLS au niveau du compte.

Restriction explicite : le routage ne s'applique qu'aux appels d'outils en temps réel passés par les utilisateurs à travers le portail. Les opérations d'arrière-plan, dont la synchronisation des identifiants d'administration, ne passent pas par Gateway et n'utilisent pas les IP de sortie.

Hors portail, par exemple un agent sur un poste qui joint directement un serveur amont, Gateway ne voit rien par défaut. Il faut activer le déchiffrement TLS comme pour n'importe quel autre trafic HTTP.

API Shield gouverne les API que vous exposez, en périmètre entrant : découverte d'endpoints, validation de schéma, mTLS, JWT, abus volumétrique. Il ne gouverne pas les appels d'un agent vers des tiers.

Agent dans Workers : un Worker ne sort pas par Gateway par défaut. L'on-ramp se configure explicitement, sinon le trafic n'est simplement pas vu.

CE QUE GATEWAY INSPECTE RÉELLEMENT

✓ Appel d'outil par le portail, routage Gateway activé
  Client MCP ──▶ Portail ──▶ [Gateway : DLP, journaux HTTP] ──▶ Serveur amont
  → inspecté

✗ Opération d'arrière-plan du portail (synchronisation d'administration)
  Portail ──▶ Serveur amont (direct, hors Gateway)
  → non inspecté

✗ Agent dans Workers sans on-ramp Gateway
  Worker ──▶ Serveur amont (direct)
  → non inspecté

✗ Agent sur un poste, client en direct
  Client local ──▶ Serveur amont (direct)
  → non inspecté sans déchiffrement TLS activé

Gateway ne filtre que ce qui passe par lui.

Et les clients MCP installés sur les postes de développeur ?

Trois questions, et trois réponses de nature différente.

Ce que le serveur expose au poste. Un serveur en transport stdio seul n'expose pas d'endpoint HTTP distant : il ne peut pas entrer dans un portail. Pour le placer sous contrôle centralisé, il faut l'héberger derrière un endpoint HTTP. C'est un prérequis d'architecture, pas une option de configuration.

Quels identifiants vivent dans la configuration locale. Les fichiers de configuration des clients MCP contiennent fréquemment des tokens, des clés d'API ou des URL de serveurs internes. Ces identifiants ne passent par aucun coffre-fort centralisé : ils vivent dans des fichiers texte, souvent en clair, sur des machines qui voyagent.

Qui révoque, et par quel chemin. La révocation passe par la politique Access si le serveur est derrière un endpoint HTTP protégé. Pour un serveur stdio local, il n'existe pas de chemin de révocation centralisé : retirer le token du fichier de configuration reste une opération manuelle, poste par poste.

La nuance qui change le diagnostic : un serveur stdio appelle très bien des services distants, API et bases de données, depuis le poste local, sans exposer le moindre endpoint entrant. Le risque n'est pas l'absence d'endpoint entrant, c'est l'absence de visibilité sur les appels sortants. Le seul chemin d'inspection est le client sur le poste, avec déchiffrement TLS activé.

Ce que ce montage ne couvre pas

Expiration silencieuse du token d'administration. Le token utilisé pour synchroniser les capacités d'un serveur expire selon la politique de l'éditeur. Quand il expire, le serveur passe en statut Error ou Sync Required et disparaît du portail pour les utilisateurs. Aucune notification n'est envoyée aux administrateurs, donc la vérification du statut se place dans les revues plutôt que dans les alertes.

Serveurs qui refusent un client mandataire. Certains serveurs MCP rejettent les requêtes venant d'un client de type portail et renvoient une erreur 403 sur l'endpoint d'enregistrement. Le portail ne peut pas contourner ce comportement côté serveur : ces serveurs restent incompatibles jusqu'à ce que leur éditeur accepte Cloudflare comme client.

Capacités figées à la première autorisation en OAuth manuel. Quand les identifiants OAuth sont configurés manuellement, Cloudflare stocke les outils et les prompts renvoyés lors de la première autorisation par un utilisateur. Les synchronisations d'arrière-plan et manuelles ne les rafraîchissent pas : un serveur qui ajoute des outils après cette date ne les expose pas pour autant.

MFA indépendant et justification d'usage : non pris en charge, pas à configurer. Les serveurs MCP utilisent un type d'application Access dédié qui ne prend pas en charge ces deux contrôles quand le serveur est autorisé par un portail. L'utilisateur n'est pas invité à réaliser le MFA, y compris si l'application globale du MFA est activée et si une politique MFA est assignée au serveur. Ce n'est pas un réglage oublié, c'est une limite du type d'application : il n'y a rien à configurer pour la lever.

Portail exposé sans politique Access. Un portail créé sans politique reste joignable. C'est le cas d'erreur le plus simple à commettre lors d'une mise en production rapide, et le plus rapide à vérifier.

Isolats Workers et Spectre. Les isolats V8 empêchent le code d'accéder à la mémoire hors de l'isolat, et le runtime supprime les chronomètres et la concurrence qui permettraient de reconstruire une mesure de temps. La documentation Cloudflare, page du 11 août 2026, consacre néanmoins une section entière à l'absence de correctif :

Un mouvement latéral entre isolats reste donc dans le périmètre des risques à considérer. L'architecture Workers le rend difficile, elle ne le rend pas impossible, et un montage sérieux compte sur la réduction de surface plutôt que sur une étanchéité.

Injection de prompt. Ce vecteur dépasse le contrôle d'accès au serveur : il porte sur le contenu échangé, pas sur le périmètre ouvert. Il se traite avec la sécurité de l'IA avec Cloudflare.

Comment Brixio met ce montage en production

Brixio n'exerce que sur Cloudflare : audit, déploiement, exploitation courante, intervention en cas d'incident, sans autre activité. Brixio est Authorized Cloudflare Service Delivery Partner (ASDP), certifié ISO 27001:2022, avec une couverture follow-the-sun depuis quatre hubs : Luxembourg, Paris, Dubaï, Singapour.

Sur un déploiement de serveurs MCP, cela se traduit par un inventaire des serveurs et des outils réellement déclarés, le choix du montage d'authentification serveur par serveur, la configuration des politiques Access et des portails, le paramétrage du routage Gateway, la mise en place des exports Logpush, et la vérification périodique des statuts de synchronisation.

Un serveur MCP ne se sécurise pas en le protégeant, mais en réduisant ce qu'il accepte d'exécuter.