Le 14 août 2026, Cloudflare a déployé de nouvelles capacités de sécurité dans Cloudflare Gateway pour détecter et gouverner le trafic Model Context Protocol (MCP) — le protocole ouvert devenu standard de communication entre agents IA et outils tiers depuis début 2025.
L'enjeu est concret : à mesure que les équipes adoptent des agents IA connectés (Claude, Cursor, GitHub Copilot, assistants internes), les entreprises font face à une nouvelle forme de Shadow IT. Les développeurs et salariés connectent des agents locaux à des serveurs MCP externes — pas forcément approuvés par la DSI — depuis l'intérieur du réseau d'entreprise.
Cloudflare propose désormais aux administrateurs réseau un mécanisme pour identifier ce trafic, cartographier les serveurs MCP accédés, et imposer un passage obligatoire par des portails approuvés. Voici ce qui a changé et ce que cela implique pour vos équipes.
Qu'est-ce que le Shadow MCP ?
Le Shadow MCP désigne toute connexion MCP non approuvée par l'organisation. C'est l'équivalent IA du Shadow IT classique — des outils utilisés sans validation de la DSI — mais appliqué aux agents IA et à leurs connexions à des outils externes.
Concrètement, le scénario type ressemble à ceci :
- Un développeur installe un client MCP local (par exemple un agent de coding comme Cursor ou un plugin Claude).
- Le client se connecte à un serveur MCP externe — un outil tiers, un service SaaS, ou même un serveur public non audité — pour exécuter des tâches ou lire des données.
- Cette connexion sort par l'infrastructure réseau de l'entreprise, en TLS, sans que la DSI n'en ait connaissance.
Les risques associés sont multiples : exfiltration non intentionnelle de données vers des serveurs MCP non sécurisés, exécution de code non audité sur des machines d'entreprise, accès à des systèmes internes depuis des agents dont la portée n'est pas délimitée. Une étude d'Anaconda et Enkrypt AI publiée début août 2026 avait chiffré à 143 000 le nombre de failles détectées dans 73 % des serveurs MCP scannés publiquement.
Pour les projets d'automatisation métier qui s'appuient sur des agents MCP connectés à des données internes, la cartographie de ces flux est désormais une exigence de conformité, notamment au regard de l'AI Act et des obligations de sécurité des systèmes IA à usage professionnel.
Ce que Cloudflare a déployé le 14 août
Cloudflare a enrichi Cloudflare One — sa suite SASE / Zero Trust — de trois nouvelles capacités dédiées au trafic MCP, disponibles depuis le 14 août 2026 :
1. Détection protocole-niveau du trafic MCP
Gateway inspecte désormais les sessions TLS à la recherche de l'en-tête MCP-Protocol-Version, ce qui lui permet de classifier le trafic MCP avec un sélecteur booléen experimental.is_mcp utilisable dans les politiques réseau et HTTP. La détection fonctionne même pour le trafic chiffré, sous réserve que l'inspection TLS soit activée dans Gateway.
2. Tableau de bord dédié
Un nouveau dashboard rapporte en temps réel : le volume total de requêtes MCP, le nombre d'utilisateurs distincts, le nombre de serveurs MCP distincts accédés, les décomptes par serveur, les serveurs hors portails approuvés (indicateur principal du Shadow MCP), et les utilisateurs les plus actifs.
3. Politique « Portal-only » (accès restreint aux portails approuvés)
Les administrateurs peuvent définir des règles Gateway qui bloquent tout trafic MCP qui ne transite pas par un MCP Server Portal Cloudflare — une interface de gestion qui permet de contrôler quels serveurs sont accessibles et d'authentifier les connexions via Access et OAuth. Le sélecteur Traffic Source = mcp_portal permet d'autoriser uniquement ce flux et de bloquer le reste.
Cette capacité est particulièrement utile pour les entreprises qui veulent autoriser l'usage d'agents IA tout en garantissant que les connexions MCP passent uniquement par des serveurs validés, documentés et auditables.
L'architecture de référence pour le MCP enterprise
Cloudflare a publié simultanément une architecture de référence pour les déploiements MCP à l'échelle enterprise. Elle assemble six composants pour une posture de sécurité complète :
- Remote MCP Servers : les serveurs MCP hébergés et gérés par l'entreprise, exposés via Cloudflare Workers.
- Access : authentification des connexions via SSO, identité vérifiée avant tout accès au serveur MCP.
- MCP Server Portals : point d'entrée centralisé pour les clients MCP approuvés, avec pré-inscription des clients OAuth (suite à la dépréciation du Dynamic Client Registration dans la spec MCP du 28 juillet 2026).
- AI Gateway : observabilité des appels vers les modèles IA (logs, latence, coût), mise en cache intelligente pour réduire les tokens consommés.
- Gateway : contrôle du trafic réseau, détection et blocage du Shadow MCP.
- WAF (Web Application Firewall) : protection contre les injections de prompts et autres attaques ciblant les endpoints IA exposés.
Cette architecture est cohérente avec l'approche Zero Trust : chaque composant valide l'identité et le périmètre d'action avant de laisser passer une requête, que celle-ci vienne d'un humain ou d'un agent automatisé.
Pour les entreprises qui construisent des outils internes sur mesure avec des agents IA, cette architecture offre un cadre de référence documenté pour satisfaire aux exigences de traçabilité et de contrôle d'accès demandées par les auditeurs de sécurité.
Comment mettre en œuvre la gouvernance MCP
Si vous utilisez déjà Cloudflare One (Zero Trust / SASE), voici les trois étapes pour activer la gouvernance MCP :
Étape 1 : Activer l'inspection TLS et détecter l'existant
Activez l'inspection TLS dans Cloudflare Gateway si ce n'est pas déjà fait. Le dashboard MCP commencera à rapporter les connexions détectées sous 24 heures. Commencez en mode observe-only pour cartographier les serveurs MCP déjà accédés par vos équipes avant de bloquer quoi que ce soit.
Étape 2 : Valider et enregistrer les serveurs approuvés dans un Portal
Pour chaque serveur MCP identifié comme légitime — un serveur interne, un outil SaaS approuvé — créez une entrée dans un MCP Server Portal Cloudflare et associez-lui une politique Access. Documentez dans votre registre de traitements AI Act l'identité du serveur, le type de données qu'il peut lire ou modifier, et les équipes autorisées.
Étape 3 : Activer la politique Portal-only
Créez une règle Gateway qui bloque tout trafic MCP dont la source n'est pas mcp_portal. Communiquez à l'avance avec les équipes concernées pour éviter de bloquer des usages légitimes non encore déclarés. Prévoyez un délai de déclaration de 2 à 4 semaines avant d'activer le blocage.
Contactez-nous si vous souhaitez être accompagné dans l'audit et la sécurisation de vos flux agents IA.
Limites et points de vigilance
Le dispositif Cloudflare résout une partie du problème, mais laisse des angles morts à connaître :
- Périmètre réseau uniquement : Cloudflare détecte le trafic MCP qui passe par son réseau. Les connexions depuis des postes de travail non managés, des VPN privés ou des réseaux mobiles hors du périmètre Cloudflare One ne sont pas visibles.
- Nécessite l'inspection TLS : la détection du trafic MCP requiert que les connexions TLS soient inspectées. Dans des contextes où cela pose des contraintes légales ou des objections des équipes (données sensibles, cabinets d'avocats, médical), l'activation de l'inspection TLS doit faire l'objet d'une procédure spécifique.
- Les agents locaux peuvent contourner : un agent qui tourne entièrement en local et se connecte directement via un tunnel ou un port non standard peut éviter la détection si l'infrastructure réseau n'est pas exhaustivement couverte par Cloudflare One.
- Sélecteur encore expérimental : le sélecteur
experimental.is_mcpest annoté comme expérimental dans la documentation Cloudflare au 14 août 2026, ce qui signifie que son comportement et sa disponibilité pourraient évoluer.
Pour les entreprises qui s'appuient sur des développements sur mesure intégrant des agents IA, une approche complémentaire — audit de code, revue d'architecture, politiques réseau au niveau endpoint — reste nécessaire en plus de la couche Cloudflare.
FAQ — Cloudflare détecte et bloque le « Shadow MCP » depuis le 14 août : ce que signifie la gouvernance du trafic agent pour votre DSI
Qu'est-ce que le « Shadow MCP » et pourquoi est-ce un risque pour l'entreprise ?
Le Shadow MCP désigne toute connexion MCP (Model Context Protocol) établie par un agent IA depuis le réseau d'entreprise vers un serveur externe non approuvé par la DSI. Ces connexions peuvent accéder à des systèmes internes, exfiltrer des données ou exécuter du code non audité — exactement comme le Shadow IT classique, mais avec les permissions étendues que les agents IA peuvent détenir sur les systèmes qu'ils pilotent.
Faut-il utiliser Cloudflare pour sécuriser ses agents MCP ?
Cloudflare est une bonne solution si vous utilisez déjà Cloudflare One (Zero Trust / SASE). La détection MCP est alors disponible sans outillage supplémentaire. Si vous êtes sur une autre architecture Zero Trust (Zscaler, Palo Alto SASE, etc.), des mécanismes équivalents de détection de trafic applicatif peuvent être configurés, mais la fonctionnalité native MCP est spécifique à Cloudflare pour l'instant. Pour les petites structures, LiteLLM en auto-hébergé couplé à un proxy réseau reste une alternative plus légère.
La détection MCP de Cloudflare est-elle compatible avec l'AI Act ?
Elle contribue à la conformité AI Act, mais ne suffit pas seule. L'AI Act exige une documentation des systèmes IA à risque, une traçabilité des décisions automatisées et des mesures de sécurité appropriées. La détection et la gouvernance du trafic MCP par Cloudflare adresse la partie contrôle d'accès et observabilité — mais la documentation des systèmes IA, l'analyse des risques et la tenue à jour du registre de traitements restent à charge de l'organisation.
Quels types de serveurs MCP faut-il déclarer en priorité dans un Portal Cloudflare ?
En priorité : tout serveur MCP qui accède à des données métier sensibles (CRM, ERP, bases documentaires confidentielles), tout serveur qui peut exécuter des actions sur des systèmes de production (déploiements, modifications de bases de données), et tout serveur tiers dont le code n'est pas audité ou hébergé hors de votre périmètre. Les serveurs purement en lecture sur des données publiques peuvent être traités en second niveau.