Detecting Shadow MCP Traffic: How Cloudflare Brings Agent Tool Calls Under Governance

Summary: Cloudflare added MCP traffic detection and governance to Cloudflare One, using protocol headers rather than URL patterns to identify inspected remote MCP traffic. Every Zero Trust customer can see MCP markings in Gateway HTTP logs and use experimental.is_mcp in Allow or Block policies. The recommended rollout is visibility first, then onboarding approved servers into MCP Portals, then blocking direct bypasses.

When companies draw up resource permissions, the design target is a person. A senior engineer is trusted to deploy to production, query sensitive databases, or revoke someone else’s access. Two assumptions justify handing over that trust: the engineer exercises judgment, and the engineer moves no faster than a human can. AI agents invalidate both at once. Their decisions are nondeterministic, and they can invoke the same tool over and over without ever tiring. A decision that looks reasonable but is wrong can multiply into thousands of incorrect actions before a single person notices.

One line of configuration is all it takes to attach an agent to an MCP server. Without asking anyone for sign-off, an employee can aim Claude Code, Codex, Cursor, OpenCode, VS Code, or any other AI harness at an MCP server the security team never approved. MCP’s contribution is a shared way for agents to discover and invoke the tools behind SaaS products, internal applications, and APIs. The permissions themselves are nothing new; what shifts is who makes each individual decision, and how fast a bad one propagates.

What MCP Traffic Looks Like on the Network

There is no obvious shape to MCP traffic. The protocol guarantees no hostname convention, and it does not require /mcp to appear in the path. On the wire, a direct connection is indistinguishable from any ordinary HTTPS API call. The protocol itself, though, does leave fingerprints behind. The MCP specification lays out several identifying headers that travel with every request. A remote MCP request, for instance, can look like this:

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

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "Austin"
    }
  }
}

Destination is identified by the hostname and path. Protocol version comes from the MCP-Protocol-Version header, while Mcp-Method and Mcp-Name reveal which operation and which tool are involved under the new stateless protocol. Inside the JSON-RPC envelope, the method appears again, the request gets an ID, and the tool arguments ride along. Those arguments are where the sensitivity concentrates—they may carry search queries, source code, customer data, or instructions for actions such as creating tickets or changing infrastructure.

Three Control Points, and Why the Network Layer Wins

An MCP call can be observed or controlled from three places:

Inside the MCP client: A hook in the client can fire once the model has picked a tool but before the request is serialized. Destination, tool name, and arguments are all visible there without touching network decryption. It is the earliest point of control, yet it demands that the same controls be reproduced in every client employees happen to use. Telemetry from any single client will never amount to a complete inventory.
At the device’s network boundary: Once the HTTP request leaves the client, a secure web gateway can see it. Given TLS decryption, the gateway can tie the request to a user and a device, examine destination and protocol headers, and apply policy without caring which MCP client is in play. For remote MCP traffic on managed paths, the network layer offers the widest view—though local stdio calls and off-network traffic stay invisible to it.
Before the MCP server invokes the tool: Execution context is richest here. The server has already authenticated the caller, parsed the message, and validated the arguments. This is the final moment at which a request can be denied before the tool runs. Server-side controls protect only the servers that implement them—but no one can slip past them by switching to another client.

Coverage is broadest at the network control point, but before it can help, it must separate MCP from ordinary HTTPS traffic. Nothing in a URL announces that a request speaks MCP. Hunting for hostnames that contain “mcp” or for paths like /mcp will overlook servers sitting at unremarkable URLs and can just as easily match services with no relation to MCP. The protocol header is the sharper signal. Per the MCP 2025-11-25 specification, clients must send MCP-Protocol-Version on every HTTP request after initialization; the MCP 2026-07-28 specification goes further and requires it on every POST request. Even so, the header cannot be the whole detector: legacy clients may omit it, and local stdio or nonconforming traffic may never carry it at all.

Cloudflare’s Approach to Detecting and Governing MCP Traffic

Cloudflare One now ships capabilities that identify inspected MCP traffic, surface which users and which servers produce it, and bring direct connections on managed network paths under control. For customers running Cloudflare Gateway with TLS inspection, a detection heuristic settles one plain question about every inspected request: is this MCP traffic?

Starting today, every Cloudflare Zero Trust customer can spot MCP traffic markings in Gateway HTTP logs and explicitly block or allow that traffic through a new selector:

experimental.is_mcp == true

That selector is a boolean. Whenever Gateway detects the MCP-Protocol-Version header on a TLS-inspected request, the value reads true, and an administrator can drop it straight into an Allow or Block policy rather than maintaining a list of MCP-looking domains. Encrypted traffic must first pass through TLS decryption before Gateway is able to inspect these headers. Anything outside that path—local stdio servers, off-network connections, Do Not Inspect traffic, and requests that never traverse Gateway—stays out of this view.

A dedicated MCP traffic dashboard lays out which hosts serve MCP traffic, which users generate it, and whether requests go through Cloudflare MCP Portals or skip them. Filters by server, user, or on-ramp type let administrators narrow the view, and from there they can navigate straight into Gateway HTTP logs for a closer look.

Discovery converts unknown traffic into a list an administrator can investigate. Once an organization approves a server, it can put that server behind a Cloudflare MCP Server Portal. Employees then get a single managed endpoint that carries Access identity, a curated tool catalog, and logging. Compatible upstream calls can be routed through Gateway by administrators, which buys HTTP policy, predictable egress, and data loss prevention. Logpush can export tool activity. With that in place, the discovery dashboard can tell requests that use the Portal apart from direct connections to the very same server.

To enforce Portal-only access, Cloudflare is introducing Traffic Source selectors into Gateway Network and HTTP policies. Traffic that routes through Gateway from an MCP Portal carries an mcp_portal Traffic Source, and policy can use that marker to separate Portal-proxied requests from employees connecting directly. A baseline enforcement rule reads like this:

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

Detected MCP traffic that never arrived through a Portal is blocked; traffic that came through the Portal passes untouched. Organizations that prefer to observe before enforcing can do so: for decrypted traffic, Traffic Source and MCP detection now show up in HTTP logs, so behavior can be monitored with no policy in place.

Shadow MCP and Portal Bypass Are Two Separate Problems

A shadow MCP connection goes to a server the organization never approved. Someone comes across that server in a repository, a product guide, or a note from a colleague, then adds it straight into their own MCP client. The security team has no idea which tools it exposes, nor what data employees send to it.

Portal bypass looks different: the starting point is a server the organization has already approved and placed in an MCP Portal, yet an employee connects to its upstream URL directly, sidestepping the Portal’s Access policy, curated tool catalog, data loss prevention, and tool-level audit trail.

For shadow MCP on managed network paths, Gateway is the primary control. Portal bypass calls for that same network control and, on top of it, an origin capable of rejecting direct requests—whether that means an Access policy, a source IP restriction, or an enterprise authorization mechanism that the MCP server itself initiates.

A Practical Rollout Order: Visibility, Then Onboarding, Then Enforcement

Cloudflare’s recommendation is a phased approach. First comes visibility: turn on Gateway logs and the MCP dashboard to see which MCP traffic exists on your network, who is using it, and where it heads. Let that run for a week or two until an inventory takes shape.

Second comes onboarding: move the approved, high-frequency servers into MCP Portals. Users gain a governed path, and the incentive to bypass shrinks. MCP Portals now support pre-registered OAuth clients, which helps cover providers that require an administrator to register an application with a fixed client ID, secret, callback URL, and scopes. Administrators can configure manual OAuth credentials, register the callback URL with the upstream provider, and enter the client credentials. Each user still authorizes access to their own upstream data sources.

Third comes enforcement: once selectors are available, block the direct connections that bypass the Portal. Flip the order around—blocking while no legitimate path exists yet—and agent users will only hunt for more hidden exits, costing you the visibility you just obtained.

Cloudflare is also working on letting MCP Portals reach private servers through Cloudflare Gateway routing and the same Cloudflare One network used for other private applications. The private server retains its private hostname; via Cloudflare’s private routing, the Portal reaches it and presents its tools beside public upstream servers, under the same Access policy, Portal logging, and audit trail.

Takeaways for Product Builders

URLs alone will not identify MCP traffic. Protocol headers such as MCP-Protocol-Version, Mcp-Method, and Mcp-Name are the more reliable signals, though even they fall short of a complete detector.
For detecting remote MCP traffic, the network layer gives the broadest coverage, at the price of TLS decryption and a managed path.
Shadow MCP and portal bypass are distinct problems with distinct answers: onboarding for the first, enforcement for the second.
Rolling out in phases—visibility, onboarding, enforcement—keeps users from seeking workarounds and preserves your ability to see what is happening.
With Cloudflare’s new selectors and dashboard, detecting and governing MCP traffic no longer requires maintaining custom URL lists.

Sources

Original source