Cloudflare Gateway peut désormais détecter et bloquer le trafic MCP

Cloudflare a livré la détection du Model Context Protocol dans son produit Gateway le August 14, 2026, donnant aux équipes réseau des entreprises un moyen de voir - et de bloquer - le trafic d'appels d'outils que les agents IA génèrent au sein de sessions chiffrées. Jusqu'ici, ce trafic était pratiquement invisible : "Le Model Context Protocol n'utilise pas de nom d'hôte garanti et n'exige pas /mcp dans le chemin, si bien qu'une connexion directe peut ressembler à n'importe quel autre appel d'API HTTPS", indique l'annonce de Cloudflare.

Le contrôle est un nouveau sélecteur booléen de Gateway, experimental.is_mcp == true, utilisable dans les politiques HTTP pour autoriser, bloquer ou isoler les requêtes correspondantes, selon le changelog de Cloudflare. Il sort en bêta et peut changer avant la disponibilité générale.

Comment fonctionne la détection

Gateway identifie les requêtes MCP en inspectant des en-têtes propres au protocole - MCP-Protocol-Version, plus Mcp-Method et Mcp-Name, selon l'analyse de Forkast - sur le trafic inspecté via TLS, si bien qu'aucune liste d'autorisation de domaines n'a besoin d'être maintenue. PPC Land rapporte que la détection a été construite à partir de motifs observés sur des millions de requêtes traversant chaque jour le réseau de Cloudflare.

C'est l'évolution du protocole lui-même qui a rendu cela possible. PPC Land fait remonter l'en-tête MCP-Protocol-Version à la version 2025-06-18 de la spécification, qui l'a introduit, et aux révisions 2025-11-25 et 2026-07-28, qui l'ont rendu obligatoire. Forkast ajoute que le passage de la spécification 2026-07-28 à un modèle sans état, par requête, est ce qui a rendu le trafic identifiable de manière fiable sur le réseau.

La raison déclarée de Cloudflare pour traiter le trafic des agents comme une catégorie à part est comportementale : "Leurs décisions sont non déterministes, et ils peuvent effectuer la même action (ou invoquer le même outil) indéfiniment, sans se fatiguer ni s'arrêter pour déjeuner", dit l'annonce à propos des agents IA.

Ce qu'il peut voir et ce qu'il ne peut pas voir

La visibilité a des limites nettes, et PPC Land les énonce clairement : "Le trafic chiffré doit passer par le déchiffrement TLS avant que Gateway puisse lire ces en-têtes. Les serveurs stdio locaux, les connexions hors réseau, le trafic marqué Do Not Inspect et toute requête qui ne traverse jamais Gateway restent entièrement hors du champ de vision." Un développeur exécutant un serveur MCP local via stdio n'est pas concerné ; un ordinateur portable hors du réseau d'entreprise non plus.

PPC Land note aussi une limitation actuelle côté application des politiques : les MCP Portals exigent des serveurs en amont joignables via l'internet public, la prise en charge du DNS privé étant encore en attente.

Les deux problèmes qu'il vise

PPC Land distingue les deux modes de défaillance visés par cette version : le Shadow MCP - des serveurs que personne n'a approuvés, fonctionnant hors de la gouvernance de sécurité - et le contournement de portail, où un serveur approuvé est atteint directement au lieu de passer par le chemin sanctionné. Les sélecteurs Traffic Source permettent à une politique de distinguer les requêtes routées par le Portal des connexions directes, de sorte qu'une organisation peut bloquer le trafic MCP direct tout en autorisant celui relayé par le Portal, selon l'annonce de Cloudflare. Un nouveau tableau de bord de sécurité IA rapporte le volume de requêtes MCP, les utilisateurs uniques et les serveurs MCP uniques, selon le changelog.

L'urgence derrière les postures de blocage par défaut se trouve dans les chiffres que Forkast cite d'une analyse de 19,000+ serveurs MCP présentée à la DEF CON 34 : 82% exposés au path traversal, 34% vulnérables à l'injection de commandes, et seulement 8.5% utilisant OAuth tout court. Le cadrage de Cloudflare sur l'ordre du déploiement : "Commencez par la visibilité, puis fermez les chemins qui ne devraient pas exister."

Ce que cela signifie pour les développeurs

Si vous exploitez des serveurs MCP auxquels se connectent des utilisateurs en entreprise, partez du principe que votre trafic est désormais classifiable à la périphérie du réseau et que certains clients passeront à des politiques portail uniquement - être joignable via un portail sanctionné, et parler correctement la spécification actuelle, devient une exigence de déploiement plutôt qu'un agrément. Vérifiez que votre serveur envoie correctement l'en-tête MCP-Protocol-Version : le même en-tête qui vous fait détecter est celui qui vous fait autoriser correctement.

Si vous êtes dans une équipe sécurité ou plateforme, la séquence pratique est celle que décrit Cloudflare : activer la détection, observer le tableau de bord pour apprendre combien de trafic MCP existe déjà dans votre organisation, puis écrire la politique. Et connaître les angles morts avant de faire confiance à la carte - les serveurs stdio et les machines hors réseau n'y apparaissent jamais.

Les chiffres de la DEF CON sont le contexte qui donne son importance à cette version : un écosystème où un tiers des serveurs publics est vulnérable à l'injection de commandes est un écosystème où "quels agents parlent à quels outils" cesse d'être une question d'observabilité pour devenir une question de contrôle d'accès. Le sélecteur est en bêta et son nom peut changer - construisez le processus de gouvernance dès maintenant, pas une dépendance dure au nom du champ.