Cloudflare can now spot MCP traffic with a single header!

Hi, it's Shii! Today Cloudflare rolled out a set of features for spotting and controlling the MCP traffic that AI agents use, so let's dig into this slightly technical one together!

Cloudflare Blog blog.cloudflare.com

What was announced?

Cloudflare Blog announced a set of new features on Cloudflare One for identifying MCP (Model Context Protocol) traffic and helping prevent AI agents from being misused. The rollout includes a visibility dashboard and new selectors you can use in policies.

The story so far

Until now, identifying MCP traffic typically meant checking whether a hostname or path contained the string "mcp." According to the post, that approach is "easy to implement but low in precision."

Things get trickier once AI agents are involved, too. Traditional permission models assumed a human was making the decision, at human speed. AI agents, on the other hand, make non-deterministic decisions and can repeat the same action indefinitely without getting tired. The post points out the risk that nobody notices a bad decision until it has ballooned into thousands of bad actions.

What changes

There are three main additions:

• MCP detection selector: a boolean selector, experimental.is_mcp == true, is now available to every Cloudflare Zero Trust user. It lets you apply allow/block policies to TLS-inspected requests where an MCP-Protocol-Version header is detected
• A dedicated MCP dashboard: showing total MCP requests, unique users, and unique servers over a period, per-server request trends, the breakdown between Portal and direct connections, and a ranking of "shadow MCP servers" that bypass the Portal
• A traffic source selector: traffic routed through the MCP Portal now carries a traffic source of mcp_portal, which you can reference in policies

For example, a rule like this blocks all MCP traffic that doesn't go through the Portal:

experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")
Action: Block

That lets teams target two distinct risks separately: "shadow MCP," where employees connect directly to servers the organization doesn't know about, and "Portal bypass," where an approved server is reached directly, skirting the Portal's Access policies, tool curation, DLP, and audit logging.

Dive Deep

Detection centers on the MCP-Protocol-Version HTTP header. The MCP 2025-11-25 spec requires it on every HTTP request, and the 2026-07-28 spec requires it on every POST request, so Cloudflare leans on it as the main signal. The Mcp-Method header (which operation is being run) and Mcp-Name header (which tool is being called) are used as supporting signals.

The post breaks MCP control points into three layers, each with its own tradeoffs:

• Inside the client: stops things earliest and can cover local stdio MCP, but is hard to standardize across multiple clients and doesn't give the organization a full inventory
• The network boundary (Secure Web Gateway): catches the widest range of MCP traffic, including traffic leaving the network, but can't see local stdio calls
• Right before the MCP server executes: has the richest execution context and is the last chance to block a tool before it runs, but requires the server itself to implement it

The limitations are spelled out clearly, too: detection requires TLS decryption, so local stdio servers, off-network connections, and traffic marked "do not inspect" fall outside its reach; and some legacy clients don't send an MCP-Protocol-Version header on their initialization request, so detection isn't guaranteed on the very first request.

The MCP Portal itself has grown as well. Alongside the existing Dynamic Client Registration, it now supports manually registering an OAuth client ID, secret, callback URL, and the various endpoints. Support for connecting to private-network servers through the Portal is also in development.

Alongside this, the Cloudflare Agents SDK was updated to v0.20.0, adding support for the MCP 2026-07-28 spec's stateless model. Clients probe for the new protocol via server/discover and fall back to the legacy initialize handshake when it isn't supported.

For rollout, the post recommends three stages: first get visibility into MCP traffic passing through the Gateway and compare it against approved servers, then move approved servers behind the Portal, and finally use Gateway policies to block direct connections.

Wrap-up

• The MCP-Protocol-Version header lets Cloudflare detect MCP traffic more precisely than hostname matching alone
• The experimental.is_mcp == true selector and a dedicated dashboard give you visibility and policy control over MCP traffic
• The mcp_portal traffic source lets you distinguish and control "shadow MCP" from "Portal bypass"
• Control points are organized into three layers: inside the client, the network boundary, and right before server execution
• Traffic without TLS decryption and local stdio servers remain outside detection's reach

If your security or platform team is watching AI agents connect to more and more MCP servers, this gives you a concrete way to surface the traffic you couldn't see before!