Cloudflare Gateway can now detect and block MCP traffic

Cloudflare shipped Model Context Protocol detection in its Gateway product on August 14, 2026, giving enterprise network teams a way to see

• and block - the tool-calling traffic AI agents generate inside encrypted sessions. Until now that traffic was effectively invisible: "The Model Context Protocol does not use a guaranteed hostname or require /mcp in the path, so a direct connection can look like any other HTTPS API call," Cloudflare's announcement says.

The control is a new boolean Gateway selector, experimental.is_mcp == true, usable in HTTP policies to allow, block, or isolate matching requests, per Cloudflare's changelog. It ships in beta and may change before general availability.

How the detection works

Gateway identifies MCP requests by inspecting protocol-specific headers - MCP-Protocol-Version, plus Mcp-Method and Mcp-Name, per Forkast's analysis - on TLS-inspected traffic, so no domain allowlist has to be maintained. PPC Land reports the detection was built from patterns observed across millions of requests crossing Cloudflare's network daily.

The protocol's own evolution is what made this possible. PPC Land traces the MCP-Protocol-Version header to specification version 2025-06-18, which introduced it, and to the 2025-11-25 and 2026-07-28 revisions, which made it mandatory. Forkast adds that the 2026-07-28 specification's shift to a stateless per-request model is what made the traffic reliably identifiable on the wire.

Cloudflare's stated reason for treating agent traffic as its own category is behavioral: "Their decisions are nondeterministic, and they can take the same action (or invoke the same tool) indefinitely, without getting tired or stopping for lunch," the announcement says of AI agents.

What it can and cannot see

The visibility has hard edges, and PPC Land states them plainly: "Encrypted traffic has to pass through TLS decryption before Gateway can read these headers. Local stdio servers, off-network connections, traffic marked Do Not Inspect, and any request that never traverses Gateway remain outside the view entirely." A developer running a local MCP server over stdio is not in scope; a laptop off the corporate network is not either.

PPC Land also notes a current limitation on the enforcement side: MCP Portals require upstream servers reachable over the public internet, with private DNS support still pending.

The two problems it is aimed at

PPC Land distinguishes the two failure modes the release targets: Shadow MCP - servers nobody approved, running outside security governance - and portal bypass, where an approved server is reached directly instead of through the sanctioned path. Traffic Source selectors let a policy tell Portal-routed requests apart from direct connections, so an organization can block direct MCP traffic while permitting the Portal-proxied kind, per Cloudflare's announcement. A new AI security dashboard reports MCP request volume, unique users, and unique MCP servers, per the changelog.

The urgency behind block-by-default postures is in the numbers Forkast cites from an analysis of 19,000+ MCP servers presented at DEF CON 34: 82% exposed to path traversal, 34% vulnerable to command injection, and just 8.5% using OAuth at all. Cloudflare's framing of the rollout order: "Start with visibility, then close the paths that should not exist."

What this means for developers

If you run MCP servers that enterprise users connect to, assume your traffic is now classifiable at the network edge and that some customers will move to portal-only policies - being reachable through a sanctioned portal, and speaking the current specification correctly, is becoming a deployment requirement rather than a nicety. Check that your server sends the MCP-Protocol-Version header properly: the same header that gets you detected is the one that gets you correctly allowed.

If you are on a security or platform team, the practical sequence is the one Cloudflare describes: turn on detection, watch the dashboard to learn how much MCP traffic already exists in your organization, then write policy. And know the blind spots before trusting the map - stdio servers and off-network machines never appear in it.

The DEF CON figures are the context that makes this release matter: an ecosystem where a third of public servers are vulnerable to command injection is one where "which agents talk to which tools" stops being an observability question and becomes an access-control one. The selector is beta and its name may change - build the governance process now, not a hard dependency on the field name.