Cloudflare Gateway has a new beta selector, experimental.is_mcp, that flags detected Model Context Protocol traffic, alongside a report showing MCP request volumes, unique users and unique servers. The limit is in Cloudflare’s own text, stated more plainly than most vendors manage: the presence of the header is a strong positive indicator of MCP, and its absence does not prove that a request is not MCP.

The network has a label it did not have before

MCP traffic has been awkward to distinguish from ordinary HTTPS API calls. The protocol does not require a fixed hostname, a conventional path, or /mcp in the route. A connection to https://tools.example.com/api is indistinguishable from any other JSON API if your network control only knows domains and paths.

Cloudflare’s earlier approach was the obvious one: search Gateway logs for hostnames containing mcp, plus familiar paths like /mcp and /sse. That finds some traffic. It also misses ordinary-looking endpoints and flags unrelated services whose hostname happens to contain the same three letters. Cloudflare says it has seen both failure modes, which is a more useful thing to publish than a clean success story.

The new route is protocol identification. On a TLS-inspected request, Gateway looks for MCP-Protocol-Version. Cloudflare’s example of a remote MCP request shows what else the newer flow puts on the wire:

POST /mcp HTTP/1.1
Host: tools.example.com
Authorization: Bearer <access-token>
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

The operation and the tool name sit at the HTTP header layer, readable without parsing the JSON-RPC body. That is a real improvement on guessing from URLs, and Cloudflare says a detected request can be allowed, blocked or isolated on the boolean selector.

A header is evidence, not coverage

Cloudflare calls this a detection heuristic, and it is unusually direct about where the heuristic stops.

For older session-based Streamable HTTP connections, the initial initialize request may not carry the header — Gateway can classify subsequent calls once client and server have finished initialising, but the first connection to an unknown destination does not carry the same signal. Protocol revisions before 2025-06-18 did not define the header at all. Custom transports and nonconforming implementations may never send it.

And a great deal of MCP use never becomes network traffic. A local stdio server runs as a process on the user’s device and does not traverse Gateway. Neither do off-network requests, traffic exempted by a Do Not Inspect rule, or connections that are never decrypted. Cloudflare lists all four exclusions in the announcement rather than a footnote.

So the accurate description of what shipped is narrower than “shadow agent traffic is now visible.” Cloudflare has made one class of remote MCP traffic visible: from managed devices, through Gateway, decrypted for inspection, in a recognisable protocol form. In an organisation with a deployed secure web gateway that is a substantial slice, and probably enough to find people connecting to unapproved servers, investigate heavy usage, and establish a sanctioned route for common tools.

What it will not give you is a full account of agent activity. An employee can run a local server. A client can route around the managed network. A server can use a transport or version that carries no identifier. A user can skip MCP and call the underlying API directly. Every one of those leaves an agent able to act on real data or systems, and none of them is settled by a negative is_mcp result.

That is not a disappointing feature. It is a network inventory signal, and it should be deployed as one.

The new spec makes the protocol easier to inspect

The timing is not coincidental. MCP’s 2026-07-28 revision defines the protocol as stateless: all the information needed to process a request is contained in the request itself, and servers MUST NOT rely on prior requests over the same connection to establish context such as capabilities, protocol version or client identity. Every request supplies that metadata in its _meta field.

The HTTP-facing consequence is what Cloudflare is trading on. Per-request protocol version, method and tool name mean an intermediary can identify a request and its broad operation without parsing a JSON-RPC body just to tell tools/list from tools/call. Load balancers can route on it, rate limiters can treat discovery differently from execution, security products get request-level metadata.

A protocol becoming easier to inspect is not a security improvement by itself. It makes certain controls possible, and whether that trade is worth it depends on what the controls cost.

Here they cost TLS decryption. Gateway needs it to read the headers and payloads of direct HTTPS requests; without it there are no headers, no JSON-RPC methods, no tool arguments and no responses. Its TLS decryption documentation describes the mechanism directly: decrypt, evaluate policy, re-encrypt, forward.

That inspection sees considerably more than a tool name. Arguments can carry source code, customer data, search terms, ticket text, infrastructure changes, or a prompt directing a write. Responses carry the same on the way back. The control is useful because it can see that content, and every privacy and data-handling consequence arrives for the same reason.

There is one exception, via the Portal. Traffic routed through an MCP Portal is terminated and re-originated by the Portal, which allows Gateway inspection without account-wide TLS decryption. Direct device-to-server connections still need ordinary TLS inspection to be classified.

So the question to settle before admiring the dashboard is an old and ordinary one: which users, devices, routes and categories of content are we willing to decrypt to get this inventory? “All of them” is an answer with more consequences than the configuration screen implies.

Seeing a request is not authorising it

Cloudflare frames detection as one layer of three: client-side hooks, Gateway inspection, and server-side enforcement. The division holds up.

A client control sees the model’s chosen tool and arguments before anything leaves the machine, and it covers local stdio servers where the network cannot help at all. Its weakness is operational — every client has to implement and keep the same control, and Claude Code, Cursor, VS Code, Codex and whatever ships next do not add up to a coherent enforcement surface on their own. Cloudflare names this standardisation problem itself.

Gateway sees a wider range of remote use from managed devices, ties traffic to a user and a device, and builds an inventory without needing every client to cooperate. Its coverage stops at the managed network boundary, and its ability to inspect direct HTTPS depends on decryption.

The MCP server sees the richest context of the three. It has authenticated the caller, parsed the message, resolved the tool and validated the arguments, and it is the last place that can stop a destructive invocation before the handler runs. Cloudflare offers its internal WriteGuard as an example of the pattern: each tool carries a risk tier and an enabled state, allowed writes gain agent attribution and an audit event, and critical actions can be blocked before execution. Worth reading as a pattern rather than a feature to enable — WriteGuard is in private beta and Cloudflare describes it as running across its own internal MCP servers.

This matters because a conforming, fully visible MCP client can still do something stupid. The model can pick the wrong tool, pass bad arguments, repeat the mistake quickly, or hold access that was already too broad before an agent came near it. Seeing the connection in Gateway tells you nothing about whether the resulting action was sensible, permitted or reversible.

Cloudflare’s baseline policy makes the governance point better than a generic “block shadow AI” would:

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

Action: Block

Block detected MCP traffic that did not arrive through an approved Portal; Portal-proxied requests carry an mcp_portal traffic source and follow the managed route. That is a real governance boundary, and it will reduce casual bypass. It cannot prevent direct access unless the upstream service itself rejects requests that did not come through that route, which Cloudflare says needs an origin-side control as well — an Access policy, a source-IP restriction, or a server-initiated authorisation mechanism.

A proxy block without origin enforcement is a rule for the clients you currently control. It guarantees nothing architecturally.

Useful now, but measure your own traffic

Cloudflare says all Zero Trust customers can see indications of MCP traffic in Gateway HTTP logs and use the beta selector. Its public material does not give a clean feature-by-feature entitlement table across Gateway inspection, Portal operation, DLP, and logging retention, and Cloudflare One’s overview notes that individual capabilities vary by plan. Filing this as Enterprise-only without checking a specific account would be wrong, and so would calling it a universally available practitioner feature. Useful deployment assumes managed-device routing, Gateway, a trusted root for decryption where direct traffic must be inspected, and the policy and logging capacity to act on what turns up.

Cloudflare is not alone. Netskope documents MCP visibility in SkopeIT from the initial exchange through tool activity, including server and client information, protocol versions, tools and prompts, behind an Agentic Broker licence with DLP as a further entitlement. Palo Alto Networks positions Prisma AIRS and its AI Gateway around MCP interaction visibility and runtime security. Zscaler’s 2026 release notes add MCP transactions to Web Insights logs, while its MCP decoys do something different — detecting interaction with deliberately deceptive MCP services. These are not equivalent controls and should not be collapsed into one.

The market has converged on the same fact: when agent tools travel over recognisable, inspected paths, security vendors can turn them into a policy object. The harder question is whether your clients, transports and device routes let that policy object cover enough of the actual work to mean anything.

My next step here would be a test rather than a rollout. Run a current remote Streamable HTTP client through Gateway with TLS inspection on. Compare an older client if you have one. Try a local stdio server. Try the same remote destination with inspection off, and again under a Do Not Inspect exception. Route a compatible server through a Portal and compare the logs and source labels against a direct connection. Write it up as a coverage table: what Gateway saw, what it missed, which configuration produced each result, and whether the Portal policy actually stopped direct access at the origin.

Until someone has that table for their own estate, treat experimental.is_mcp as a practical way to find and govern a visible subset of remote MCP activity inside an existing Cloudflare One deployment. Do not read the absence of the signal as evidence that a device, a user, or an agent is not using MCP.

mcpai-agentstoolingcloudflare