Cloudflare a annoncé de nouvelles capacités dans Cloudflare One pour aider les équipes de sécurité à détecter et contrôler le trafic du Model Context Protocol (MCP), alors que les agents d’intelligence artificielle sont désormais capables d’appeler des outils et d’exécuter des actions rapidement et à une échelle telle qu’une seule erreur peut se répéter des milliers de fois avant d’être remarquée.
Les nouvelles mises à jour permettent à Cloudflare Gateway d’identifier les requêtes MCP grâce à des indicateurs au niveau du protocole, d’afficher les utilisateurs et les serveurs qui génèrent ce trafic, puis d’appliquer des politiques autorisant ou bloquant les connexions. En association avec les MCP Server Portals, les administrateurs peuvent vérifier si les agents utilisent le chemin approuvé ou s’ils se connectent directement à un serveur en contournant les contrôles mis en place.
Détecter le trafic MCP sans dépendre d’adresses distinctives
MCP n’impose ni nom d’hôte précis ni chemin fixe tel que /mcp. Les connexions directes peuvent donc ressembler à n’importe quelle requête HTTPS vers une API. Cloudflare s’appuyait auparavant sur la recherche de noms d’hôte ou de chemins contenant des indicateurs courants, mais cette méthode pouvait manquer des serveurs utilisant des adresses ordinaires ou intercepter des services sans rapport avec MCP.
Gateway s’appuie désormais sur des indicateurs protocolaires, notamment l’en-tête MCP-Protocol-Version dans les requêtes qui passent par un déchiffrement TLS. Les versions récentes du protocole peuvent également utiliser les en-têtes Mcp-Method et Mcp-Name pour déterminer l’opération et l’outil demandés, sans devoir analyser entièrement le corps de la requête.
À la date de l’annonce, tous les clients Cloudflare Zero Trust voient les indicateurs du trafic MCP dans les journaux Gateway HTTP et peuvent utiliser le sélecteur experimental.is_mcp == true dans les politiques d’autorisation ou de blocage. Cette détection ne couvre pas le trafic chiffré qui n’a pas fait l’objet d’un déchiffrement, les serveurs MCP locaux utilisant stdio, les connexions en dehors du réseau géré ni les requêtes qui ne passent pas par Gateway.
Un tableau de suivi des connexions et des destinations
Cloudflare propose un tableau de bord dédié au trafic MCP qui affiche, sur une période configurable :
- Le nombre total de requêtes MCP ainsi que le nombre d’utilisateurs et de serveurs uniques.
- Les serveurs fournissant du trafic MCP et le nombre de requêtes pour chaque serveur.
- La répartition du trafic selon le point de connexion, en distinguant le trafic MCP Portal des connexions directes depuis les appareils des utilisateurs.
- Les serveurs MCP les plus fréquemment observés en dehors des portails approuvés, ce qui représente du trafic MCP non géré.
- Les utilisateurs générant le plus grand volume de requêtes MCP.
Les administrateurs peuvent filtrer les résultats par serveur, utilisateur ou type de point de connexion, puis accéder aux journaux Gateway HTTP associés pour mener une enquête plus approfondie.
Distinguer les serveurs non approuvés du contournement du portail
Cloudflare distingue deux problèmes différents. Le premier est le Shadow MCP, lorsqu’un employé ajoute à un client MCP un serveur qui n’a pas été approuvé par l’organisation. Le second est le contournement du portail, lorsqu’un employé se connecte directement à l’adresse d’un serveur approuvé au lieu d’utiliser le MCP Portal, contournant ainsi les politiques Access, le catalogue d’outils organisé, la prévention des pertes de données et le journal d’audit.
Après la découverte d’un serveur inconnu, l’organisation peut l’évaluer et le placer derrière un MCP Portal. Le portail fournit un point d’accès géré, une identité Access, un catalogue organisé d’outils et l’enregistrement de l’activité. Les connexions conformes peuvent également être acheminées via Gateway afin d’appliquer des politiques HTTP et de prévenir les pertes de données, avec export de l’activité des outils via Logpush.
Pour imposer l’utilisation exclusive des portails, Cloudflare a ajouté des sélecteurs Traffic Source aux politiques Gateway Network et HTTP. Le trafic provenant d’un MCP Portal affiche la source mcp_portal, ce qui permet de bloquer les requêtes MCP qui ne proviennent pas du portail tout en conservant les requêtes passant par le chemin approuvé.
Élargir la compatibilité avec OAuth et les serveurs privés
Les MCP Portals prennent désormais en charge les clients OAuth préenregistrés. L’administrateur peut saisir manuellement les identifiants, enregistrer l’adresse de rappel auprès du fournisseur de services et définir les points de terminaison d’autorisation, de jetons, de révocation et d’émetteur lorsqu’ils ne peuvent pas être détectés automatiquement. Chaque utilisateur reste responsable de l’autorisation de l’accès à ses propres sources de données, tandis que le secret stocké sert uniquement à récupérer les listes d’outils et les invites mises à jour.
Cloudflare travaille également à permettre aux portails d’accéder à des serveurs MCP situés sur des réseaux privés via le routage Cloudflare Gateway, mais cette fonctionnalité est encore en développement actif. Agents SDK, dans sa version v0.20.0, prend également en charge la spécification MCP datée du 2026-07-28 en tant que client et serveur, avec la possibilité de revenir à l’ancien mécanisme d’initialisation lorsque le serveur ne prend pas en charge le nouveau modèle sans état.
Cloudflare recommande de commencer par la visibilité : examiner le trafic qui passe par Gateway, comparer les destinations aux serveurs approuvés et déplacer les serveurs acceptés vers les MCP Portals. Il est ensuite possible d’imposer des politiques bloquant les connexions directes depuis les appareils et les sites gérés, étant précisé que l’entreprise prévoit d’ajouter un contrôle plus détaillé de l’utilisation d’outils spécifiques ainsi que des rapports sur l’utilisation des outils au travers de serveurs MCP connus et inconnus.