Cloudflare : comment la détection MCP transforme le trafic d’agents fantômes en décision de sécurité

Cloudflare a étendu la détection du trafic MCP au-delà des noms de serveurs évidents, mettant au jour un angle mort que les équipes de sécurité pouvaient auparavant manquer. La question du « comment » chez Cloudflare commence désormais par des preuves issues du protocole, et non par une liste de domaines connus. Gateway peut inspecter le trafic HTTP géré à la recherche de chemins spécifiques à MCP et de méthodes JSON-RPC, puis distinguer le trafic Portal approuvé des connexions directes.

Cette distinction est importante, car le Model Context Protocol, ou MCP, permet aux agents IA d’appeler des outils externes et de récupérer des données privées. Une seule connexion peut accéder au code source, aux dossiers clients, aux contrôles cloud ou aux systèmes de messagerie. Lorsque des employés configurent des serveurs distants sans validation, l’activité MCP fantôme qui en résulte s’apparente au shadow IT, avec un agent capable d’exécuter des actions.

La réponse de Cloudflare combine découverte et mécanisme d’application des règles. Gateway fournit le signal réseau, tandis que les portails de serveurs MCP centralisent les serveurs approuvés derrière un point de terminaison unique. Les politiques Access régissent les conditions d’identité et d’appareil, et la prévention des pertes de données, ou DLP, peut inspecter les requêtes et réponses des outils. La question non résolue est de savoir si les organisations peuvent faire transiter suffisamment de trafic par ces contrôles pour rendre le modèle fiable.

Comment la détection MCP de Cloudflare interprète le protocole

Le changement important apporté par Cloudflare consiste à passer de la supposition des destinations à la reconnaissance du comportement MCP au sein du trafic HTTP inspecté.

La méthode de détection la plus simple examine le nom d’hôte de destination. Un administrateur peut rechercher dans les journaux Gateway des points de terminaison MCP connus ou des noms d’hôte contenant mcp. Cette approche détecte les services qui indiquent leur fonction par des noms tels que mcp.example.com.

Un second signal provient de l’URI de requête. Les serveurs distants exposent couramment des chemins tels que /mcp, /sse ou /mcp/sse. Gateway peut rechercher ces modèles dans les requêtes enregistrées, même lorsque le nom d’hôte paraît générique.

Ces deux méthodes sont utiles pour un inventaire initial, mais aucune ne prouve qu’une requête transporte du MCP. Une application classique peut utiliser le même chemin. Un serveur MCP peut également se cacher derrière un nom d’hôte ordinaire et une route API banale.

Cloudflare oriente donc les administrateurs vers l’inspection du corps des requêtes. MCP encode les messages à l’aide de JSON-RPC, un format de requête structuré comprenant des champs tels que jsonrpc, method et params. Les noms de méthodes standard créent des preuves reconnaissables au niveau du protocole.

Parmi les exemples figurent initialize, tools/list, tools/call, resources/read et prompts/get. Un profil DLP peut rechercher ces chaînes dans les corps POST, même lorsque le domaine et le chemin ne révèlent rien. Cloudflare a publié des exemples d’expressions régulières dans son architecture MCP couvrant plusieurs méthodes courantes et champs de version du protocole.

La méthode initialize est particulièrement utile, car elle établit la relation entre un client MCP et un serveur. Un client déclare sa version de protocole, ses capacités, son nom et sa version. Le serveur répond avec ses propres capacités et peut créer une session.

Les appels d’outils produisent un signal opérationnel plus fort. Une requête contenant tools/call indique que l’agent tente d’invoquer une capacité, et non simplement de vérifier l’existence d’un point de terminaison. Les arguments peuvent également révéler quelles données ou quelles actions l’outil traitera.

Le modèle de fonctionnement de Cloudflare est donc à plusieurs niveaux :

• Les modèles de noms d’hôte identifient les serveurs MCP connus ou explicitement nommés.

• Les modèles d’URI identifient les points de terminaison MCP distants conventionnels.

• Les méthodes JSON-RPC identifient le comportement MCP sur des points de terminaison moins évidents.

• Les champs utilisateur et appareil relient ce comportement à une personne ou à un système géré.

• Les actions Gateway indiquent si la requête a été autorisée, bloquée ou traitée d’une autre manière.

Le flux de travail documenté par Cloudflare utilise le jeu de données gatewayHttpRequestsAdaptiveGroups dans son API GraphQL Analytics. Les administrateurs peuvent regrouper les résultats par hôte, URI, utilisateur, action et profils DLP correspondants. Selon le tutoriel de détection de l’entreprise, le jeu de données prend en charge jusqu’à 30 jours de requêtes historiques.

Il ne s’agit pas de détection des menaces consciente du contenu au sens le plus large. Une correspondance sur tools/call indique qu’un outil MCP a été invoqué. Elle ne permet pas de déterminer si l’outil est digne de confiance, si ses instructions sont malveillantes ou si l’action correspond à l’intention de l’utilisateur.

La reconnaissance du protocole comble néanmoins une lacune importante en matière de visibilité. Une équipe de sécurité n’a plus besoin de connaître chaque fournisseur ou point de terminaison MCP avant d’ouvrir une enquête. Elle peut rechercher les propriétés du protocole lui-même.

Cela crée la tension centrale de l’article. La détection peut révéler du trafic MCP direct, mais un signal seul ne permet pas d’établir quelles connexions doivent rester disponibles. Cloudflare a besoin d’une alternative gouvernée avant qu’un administrateur puisse bloquer le chemin non géré sans interrompre un travail légitime.

Le MCP fantôme place les équipes de sécurité entre accès et adoption

La pression immédiate repose sur les équipes de sécurité, qui doivent distinguer les connexions d’agents utiles des accès non examinés à des systèmes sensibles.

MCP standardise la manière dont une application IA découvre des outils, lit des ressources, récupère des prompts et invoque des actions. Le protocole réduit le travail d’intégration sur mesure, ce qui facilite également l’ajout de serveurs par les employés et les développeurs sans projet de déploiement centralisé.

Cette rapidité crée un problème de gouvernance familier. Un utilisateur peut configurer un client MCP avec l’URL d’un serveur distant et accorder l’accès au moyen d’OAuth ou d’un autre identifiant. L’équipe de sécurité pourrait ne jamais voir cette configuration dans son catalogue de logiciels approuvés.

Le risque dépasse celui d’une visite non autorisée d’une application web. Un serveur MCP expose des outils à un agent, et ces outils peuvent disposer d’autorisations importantes. Selon l’intégration, ils peuvent rechercher des documents, lire des dépôts, ouvrir des dossiers d’assistance, modifier une infrastructure ou envoyer des messages.

Un outil légitime peut tout de même recevoir des données inappropriées. Un employé peut demander à un agent d’analyser un problème client, puis envoyer sans le savoir des informations réglementées à un serveur externe. Un serveur compromis ou trompeur pourrait également renvoyer des instructions conçues pour manipuler ultérieurement le comportement de l’agent.

C’est pourquoi Cloudflare décrit les connexions non gérées comme du MCP fantôme. Le problème déterminant n’est pas de savoir si chaque serveur inconnu est hostile. C’est que l’organisation n’a pas examiné le serveur, son opérateur, les autorisations demandées ni les données qui y transitent.

Les journaux Gateway peuvent transformer cette activité inconnue en inventaire. Les administrateurs peuvent identifier les utilisateurs, les hôtes de destination, les volumes de requêtes, les actions de politique et les méthodes de protocole détectées. Ils peuvent ensuite déterminer quel client a créé le trafic et à quel besoin métier il répond.

Cet inventaire permet également une application plus mesurée des règles. Une équipe peut enregistrer les premières correspondances, examiner les destinations actives et classer chaque serveur avant de bloquer quoi que ce soit. Les cas à forte confiance, tels qu’un trafic direct vers un outil distant non approuvé, peuvent faire l’objet d’une politique plus stricte.

Toutefois, la couverture réseau gérée définit la frontière. Gateway doit activement proxyfier le trafic HTTP concerné. Si un employé utilise un appareil non géré, un chemin réseau distinct ou un client hors des contrôles de l’organisation, ces requêtes n’apparaîtront pas dans les mêmes journaux.

Le trafic chiffré ajoute une autre condition. Gateway a besoin du déchiffrement TLS pour inspecter le corps HTTP d’une connexion MCP directe. Sans cela, les administrateurs pourraient voir le nom d’hôte de destination, mais manquer les méthodes JSON-RPC et les arguments des outils.

Cloudflare traite le trafic Portal différemment. Le Portal termine la connexion client et crée une nouvelle connexion vers le serveur en amont. Cette architecture permet à Gateway d’inspecter le trafic Portal routé sans dépendre du paramètre de déchiffrement TLS applicable à l’ensemble du compte.

Le trafic direct ne bénéficie pas de ce traitement automatique. La documentation Portal de Cloudflare indique qu’un agent se connectant directement via un appareil géré par WARP requiert la configuration habituelle de déchiffrement TLS pour l’inspection du corps.

Il existe également des raisons légitimes d’exempter du trafic de l’inspection. Les exigences de confidentialité, les applications utilisant le certificate pinning ou des contraintes opérationnelles peuvent conduire les équipes à créer des politiques Do Not Inspect. Ces politiques prévalent et peuvent laisser une activité MCP correspondante hors de l’analyse DLP.

Ces limites ne rendent pas la détection inutile. Elles définissent ce que le tableau de bord obtenu signifie réellement. Un rapport montre une activité de type MCP visible sur des chemins gérés et inspectés. Il ne constitue pas un recensement complet de toutes les connexions d’agents dans l’entreprise.

Cette distinction devrait guider la réponse aux incidents. Une connexion détectée mérite une enquête, mais un rapport vide ne prouve pas l’absence de MCP fantôme. Les équipes de sécurité ont besoin d’une couverture des terminaux, de données d’identité et de contrôles de configuration des clients en complément de la détection réseau.

Le véritable enjeu oppose l’accès Portal aux connexions directes

Le modèle de sécurité de Cloudflare ne devient applicable que lorsque l’accès Portal approuvé remplace les URL de serveurs directs sur les chemins gérés.

Un portail de serveurs MCP regroupe plusieurs serveurs approuvés derrière un point de terminaison HTTP unique. Les utilisateurs configurent ce point de terminaison dans leur client MCP, s’authentifient via Cloudflare Access et ne reçoivent que les serveurs et outils autorisés par la politique.

Le Portal remplit plusieurs rôles que les connexions directes répartissent entre les intégrations individuelles. Il identifie l’utilisateur, évalue les règles Access, gère l’authentification en amont, expose les outils approuvés et consigne les requêtes. Les administrateurs peuvent organiser les serveurs sans demander à chaque employé de gérer une liste distincte de points de terminaison.

Les politiques Access peuvent utiliser les groupes d’identité, la localisation et l’état de sécurité de l’appareil. Un portail financier peut exposer certains outils en lecture seule aux employés de la finance. Un portail d’ingénierie pourrait n’autoriser des actions supplémentaires que depuis des appareils d’entreprise gérés.

Les administrateurs peuvent également masquer des outils ou prompts individuels. C’est important, car approuver un serveur n’oblige pas à approuver toutes les capacités qu’il publie. Un serveur ayant accès à un dépôt peut exposer des opérations de recherche et de lecture, tandis que son opération d’écriture reste indisponible.

La conception Portal de Cloudflare prend en charge les serveurs en amont non authentifiés et les serveurs protégés par OAuth. Les utilisateurs peuvent s’authentifier séparément auprès d’un service en amont, ou certains flux de travail de machine à machine peuvent utiliser des jetons de service Access. Le Portal joint ensuite les identifiants appropriés lorsqu’il proxyfie un appel d’outil.

Lorsque le routage Gateway est activé, les appels en temps réel passent du Portal par Gateway avant d’atteindre le serveur en amont. Gateway consigne les requêtes et peut appliquer des politiques HTTP et DLP. Les contrôles de sortie peuvent également attribuer à ces requêtes des adresses source prévisibles.

Cela crée un modèle pratique d’autorisation et de blocage. Les équipes de sécurité fournissent aux employés un point de terminaison Portal approuvé, puis créent des règles Gateway qui arrêtent les connexions directes aux serveurs MCP en amont. Le chemin Portal reste disponible tandis que les alternatives non gouvernées sont restreintes.

La politique doit cibler la bonne destination. Cloudflare indique que les règles DLP pour le trafic Portal doivent correspondre au nom d’hôte du serveur MCP en amont, et non simplement au domaine Portal. Le Portal est le point d’entrée côté client, mais Gateway évalue la requête réémise qui se dirige vers le serveur réel.

L’organisation ressemble davantage à une passerelle applicative qu’à un simple répertoire. Elle offre un point de contrôle où convergent l’identité, la sélection des outils, la journalisation et les contrôles des données. C’est ce point de contrôle qui transforme la découverte en gouvernance.

Pourtant, l’URL directe reste une faiblesse centrale. Cloudflare avertit que masquer un serveur depuis un Portal n’empêche pas un utilisateur de se connecter à son adresse d’origine. Si le serveur en amont demeure accessible publiquement, la seule politique du Portal ne peut pas empêcher le contournement.

Les organisations ont donc besoin d’un contrôle d’application en dehors de l’interface du Portal. Elles peuvent protéger un serveur avec Access lorsqu’elles contrôlent son nom d’hôte, limiter le trafic entrant à des adresses de sortie connues, ou bloquer les destinations directes via Gateway. Les services tiers nécessiteront les contrôles compatibles avec leur modèle de déploiement.

Le choix n’oppose pas Cloudflare à un autre fournisseur de sécurité. Le principal adversaire est l’accès au Portal gouverné face aux connexions directes configurées par les utilisateurs. Chaque fonctionnalité majeure sert cette confrontation.

Les journaux du Portal identifient l’activité approuvée. La découverte via Gateway recherche le trafic en dehors de l’itinéraire approuvé. Access établit qui peut utiliser le Portal. DLP évalue les données traversant le chemin géré. La politique réseau tente de fermer l’itinéraire direct.

Ce modèle offre également aux développeurs une destination utilisable une fois l’application des règles commencée. Une interdiction générale de MCP pousserait l’expérimentation hors des canaux officiels. Un Portal sélectionné permet aux équipes de conserver les outils approuvés tout en laissant la sécurité examiner des serveurs supplémentaires.

Le résultat dépend de la discipline opérationnelle. Quelqu’un doit être responsable du catalogue de serveurs approuvés, examiner les autorisations des outils, maintenir les politiques Access et répondre aux nouvelles destinations détectées. La centralisation réduit la dispersion des contrôles, mais elle n’élimine pas ces décisions.

Les heuristiques de protocole apportent une couverture, pas une certitude

Cloudflare peut identifier de solides indicateurs MCP, mais ces indicateurs ne prouvent pas qu’une connexion est sûre, malveillante ou correctement gouvernée.

Les schémas de détection sont des heuristiques. Un corps contenant "method":"tools/call" ressemble fortement à MCP, mais une autre application JSON-RPC pourrait utiliser le même nom de méthode. Une implémentation MCP personnalisée pourrait également produire un formatage qui sort du cadre d’une expression régulière définie de manière restrictive.

Les tolérances d’espacement illustrent le problème. Les expressions d’exemple autorisent une quantité limitée d’espaces autour des champs JSON. Les champs réordonnés devraient rester détectables lorsque chaque schéma cible un champ, mais une sérialisation et un échappement alternatifs peuvent compliquer la correspondance.

Le trafic chiffré ou non pris en charge crée des lacunes plus importantes. DLP ne peut pas inspecter le corps d’une requête HTTPS directe à moins que Gateway ne la déchiffre. Les serveurs MCP locaux qui communiquent via l’entrée et la sortie standard ne traversent pas du tout une passerelle HTTP.

Streamable HTTP est le transport distant le plus important dans la conception actuelle de Cloudflare. La spécification de transport MCP définit des requêtes HTTP transportant des messages JSON-RPC et des identifiants de session facultatifs. Ces structures régulières aident Gateway à reconnaître le protocole.

Le chemin routé du Portal de Cloudflare prend en charge Streamable HTTP. Si un serveur en amont ne prend en charge que l’ancien transport Server-Sent Events, le routage Gateway échouera pour ce serveur. Le Portal tente d’utiliser Streamable HTTP lorsque le routage est activé, mais le service en amont doit le prendre en charge.

La synchronisation en arrière-plan constitue une autre exception. Les Portals récupèrent périodiquement les outils et les prompts auprès des serveurs en amont, mais Cloudflare indique que ces requêtes de synchronisation ne passent pas par Gateway. Seuls les appels d’outils utilisateur en temps réel bénéficient de l’inspection routée documentée.

La couverture DLP comporte également des limites propres au produit. Cloudflare indique que ses profils de prompts IA ne s’appliquent pas au trafic MCP Portal, car ces profils attendent des chemins et des formats d’API différents. Les administrateurs doivent utiliser des profils DLP standard.

Les règles Do Not Inspect restent efficaces pour le trafic Portal. Bien que le routage du Portal autorise le déchiffrement automatique, une exemption explicite empêche l’inspection de la charge utile. Une exception trop large pourrait donc supprimer la protection DLP d’un serveur en amont approuvé.

Les politiques d’identité comportent aussi des réserves. Cloudflare précise que l’authentification multifacteur indépendante, la justification de l’objectif et l’authentification temporaire ne sont pas appliquées aux serveurs autorisés via un Portal. Les sélecteurs d’e-mail, de groupe, de pays et de posture de l’appareil restent applicables.

Ces contraintes comptent, car un Portal peut paraître plus restrictif que son véritable chemin de politique. Un administrateur peut attribuer une exigence au niveau du serveur et supposer que les utilisateurs y seront confrontés lors de l’autorisation via le Portal. La documentation de Cloudflare indique que plusieurs contrôles renforcés ne fonctionneront pas ainsi.

Les équipes de sécurité devraient également distinguer la détection de protocole de la sécurité sémantique. Une requête peut passer par un Portal approuvé, ne correspondre à aucune règle DLP et néanmoins déclencher une action dangereuse. DLP recherche des modèles de données définis, et non si la suppression d’un projet correspond à l’intention de l’utilisateur.

L’injection via les outils pose un problème connexe. Un serveur en amont peut renvoyer un contenu qui influence la décision suivante d’un agent. L’inspection réseau peut enregistrer ou bloquer des chaînes sensibles, mais elle ne reconnaît pas nécessairement des instructions manipulatrices intégrées dans un contenu par ailleurs valide.

L’inverse est également vrai. Une connexion MCP fantôme n’est pas automatiquement un incident. Un développeur peut tester une source de données publique inoffensive. La connexion reste non gouvernée, mais son impact métier et sécuritaire exige du contexte.

Les faux positifs et les faux négatifs doivent donc faire partie du modèle opérationnel. Les équipes devraient considérer les correspondances de noms d’hôte et d’URI comme des pistes, puis utiliser les signaux du corps, l’attribution utilisateur, les données client et l’examen du serveur pour prendre une décision. Les règles de blocage à fort impact devraient reposer sur davantage qu’une correspondance générique de chemin.

Un déploiement progressif peut réduire les perturbations. Les administrateurs peuvent commencer par la journalisation, établir le trafic Portal attendu et identifier les destinations directes courantes. Ils peuvent ensuite bloquer les connexions fantômes à forte probabilité tout en créant un processus d’approbation pour les nouveaux serveurs.

La version la plus robuste combine les contrôles réseau et endpoint. Gateway voit le trafic distant traversant des chemins gérés. La gestion des endpoints peut contrôler les clients et configurations que les utilisateurs installent. Access et les restrictions en amont rendent le contournement plus difficile lorsqu’un itinéraire approuvé existe.

Cloudflare a fourni les éléments de cette architecture. Il n’a pas supprimé la nécessité de la concevoir.

Trois signaux montreront si le modèle MCP de Cloudflare tient la route

Le prochain test consiste à déterminer si les entreprises peuvent transformer la visibilité sur MCP en routage cohérent, blocage pertinent et gouvernance mesurable des outils.

Le premier signal est la part du trafic détecté qui transite par des domaines Portal approuvés. Les premières recherches dans Gateway révéleront probablement un mélange de services connus, d’expériences et de faux positifs. Le modèle gagne en crédibilité lorsque l’activité MCP directe diminue après la mise à disposition d’alternatives approuvées.

Les équipes de sécurité devraient mesurer cela comme un résultat de routage, et non seulement comme un nombre de blocages. Un nombre croissant de requêtes bloquées peut montrer que la politique fonctionne, mais il peut aussi indiquer que les utilisateurs continuent d’essayer de contourner l’itinéraire approuvé. Une migration réussie signifie que l’activité légitime continue via le Portal.

Le deuxième signal est la qualité des politiques aux niveaux des outils et des données. Un Portal qui expose toutes les capacités de chaque serveur approuvé centralise l’accès sans appliquer beaucoup de contraintes. Les déploiements plus robustes sélectionneront les outils, utiliseront des conditions d’identité et appliqueront des profils DLP aux requêtes comme aux réponses.

Gateway de Cloudflare peut bloquer une requête d’outil lorsque le contenu sortant correspond à un profil DLP standard. Il peut également bloquer la réponse lorsqu’un serveur en amont renvoie des données sensibles correspondantes. Le client MCP reçoit une erreur au lieu du contenu protégé.

Ces contrôles deviennent plus utiles lorsque les organisations les adaptent aux flux de travail réels. Les identifiants, les informations financières, les identifiants clients et les documents propriétaires présentent des risques différents. Une politique qui bloque tout frustrera les utilisateurs, tandis qu’une politique qui ne se déclenche jamais offre peu de protection.

Les équipes de sécurité devraient suivre les méthodes d’outils bloquées, les catégories de données correspondantes, les serveurs affectés et les résultats pour les utilisateurs. Elles devraient également examiner si les agents réessaient de manière répétée des requêtes bloquées. Des tentatives répétées peuvent révéler un mauvais comportement du client ou un flux de travail nécessitant une conception approuvée plus sûre.

Le troisième signal est la rapidité avec laquelle Cloudflare et l’écosystème MCP comblent les lacunes de couverture connues. L’adoption de Streamable HTTP devrait réduire le nombre de serveurs en amont qui ne peuvent pas utiliser le routage Gateway. De meilleurs contrôles endpoint pourraient améliorer la visibilité sur les configurations locales et non gérées.

Les évolutions du protocole compteront également. Les schémas de détection construits autour des méthodes JSON-RPC actuelles doivent suivre l’évolution de la spécification. Un en-tête stable ou un autre signal de transport normalisé pourrait faciliter la classification, mais les équipes de sécurité ne devraient pas supposer que tous les clients adopteront immédiatement de nouveaux champs.

Le comportement des concurrents apportera un autre indice sans modifier la confrontation centrale. Les fournisseurs de passerelles web sécurisées et de solutions endpoint ajouteront probablement leurs propres classifications MCP, inventaires de serveurs ou contrôles d’agents. Cette pression peut améliorer les méthodes de détection et révéler les limites des approches reposant uniquement sur le réseau.

L’avantage de Cloudflare réside dans l’intégration architecturale. Son Portal, Access, Gateway, DLP, ses contrôles de sortie et d’application peuvent participer à un même chemin de politique. Son défi consiste à prouver que les clients peuvent configurer ces composants sans laisser de possibilités de contournement significatives.

L’histoire du « comment » de Cloudflare porte donc moins sur un détecteur unique que sur une boucle de rétroaction. Trouver le trafic MCP direct, l’étudier, approuver les serveurs nécessaires, les router via un Portal et bloquer le chemin non géré. Puis recommencer à mesure que les utilisateurs adoptent de nouveaux outils.

Les organisations qui envisagent ce modèle devraient commencer par une question pratique : quels chemins réseau gérés et quels clients d’agents leur équipe de sécurité peut-elle réellement observer aujourd’hui ?

À partir de là, elles peuvent inventorier les signaux MCP, les comparer au trafic Portal approuvé et choisir les points où l’application des règles offre suffisamment de certitude. L’objectif n’est pas d’étiqueter chaque connexion MCP comme dangereuse. Il consiste à garantir que les agents atteignent les outils sensibles via un itinéraire que l’organisation peut authentifier, inspecter et auditer.