Cloudflare announced new Cloudflare One capabilities to identify Model Context Protocol (MCP) traffic, show which users and servers generate it, and block direct connections that do not go through approved paths. The announcement is not about a specific vulnerability or active attack. It addresses an operational problem that grows with AI agents: tools that used to be triggered by a person can now be invoked automatically, quickly and repeatedly.

What Cloudflare announced

In an official post dated August 14, Cloudflare says Gateway will classify inspected MCP requests using protocol-level signals rather than relying only on hostnames or paths such as “/mcp.” Administrators will see indications of MCP traffic in Gateway HTTP logs and can use a new boolean selector, `experimental.is_mcp == true`, to allow or block those connections when traffic passes through managed paths with TLS inspection.

MCP has become a common way to connect AI agents to external tools: repositories, internal systems, SaaS products, databases and APIs. That ease of connection is the risk. An employee can configure Claude Code, Codex, Cursor, VS Code or another client to connect to an MCP server with little friction. If the organization cannot see that connection, it also does not know which tools are exposed or what data is being sent in the arguments passed to the server.

The “shadow MCP” problem

Cloudflare separates two cases. The first is shadow MCP: connections to servers that the organization has not approved. The second is portal bypass: a server has been approved, but a user connects directly to the original endpoint instead of going through the managed portal, skipping access policies, a curated tool catalog, audit logging and data-loss controls.

The new approach uses signals such as the `MCP-Protocol-Version` header and, in the MCP 2026-07-28 specification, headers such as `Mcp-Method` and `Mcp-Name`, which make an operation easier to identify without parsing the full request body. Cloudflare notes an important limit: the absence of those headers does not prove a request is not MCP. Older clients, local `stdio` traffic, off-network connections and “Do Not Inspect” paths can remain outside this visibility.

What changes for enterprises

For security and platform teams, the update is more than another dashboard. It is a way to turn unknown agent traffic into an investigable list: which servers appear, which users connect to them, how many requests they generate and whether they use an MCP Portal or a direct connection. From there, an organization can approve servers, move them behind a portal, apply identity through Cloudflare Access, log activity and block detected connections that do not arrive through the approved path.

Cloudflare also says MCP Portals now support pre-registered OAuth clients, a compatibility improvement for providers that do not use dynamic registration. The company is also working on letting portals reach private MCP servers through Cloudflare Gateway routes, which matters because many enterprise tools are not publicly exposed.

Editorial read

The broader signal is that AI-agent security is starting to look less like “protecting a chatbot” and more like governing automated application traffic. If an agent can invoke tools that modify infrastructure, query customer data or create tickets, the critical questions become: who approved that server, which tool was called, with what arguments and through which network path?

Confirmed facts include Cloudflare’s announcement, its public MCP traffic detection documentation and its MCP Portals documentation. What those sources do not independently prove is performance across heterogeneous environments, coverage for nonconforming clients or protection for local servers. The right framing is therefore bounded: this is a practical step for visibility and governance, not a complete solution for every agent-security risk.

Sources: Cloudflare Blog and official Cloudflare One documentation.

Written by Lía Torres — Social and strategic perspective.