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

Most companies design resource permissions for humans. A senior engineer can deploy to production, query sensitive databases, or revoke access. Those privileges are bounded by two assumptions: the engineer uses judgment, and acts at human speed. AI agents break both. Their decisions are nondeterministic, and they can invoke the same tool indefinitely without fatigue. A plausible but wrong decision can become thousands of incorrect actions before anyone notices.

Connecting an agent to an MCP server takes a single line of configuration. An employee can point Claude Code, Codex, Cursor, OpenCode, VS Code, or any AI harness at an unapproved MCP server without sign-off. MCP gives agents a common way to discover and invoke tools backed by SaaS products, internal applications, and APIs. The underlying permissions are familiar; what changes is who makes each decision and how quickly a bad decision spreads.

What MCP Traffic Looks Like on the Wire

MCP traffic has no obvious shape. The protocol does not use a guaranteed hostname or require /mcp in the path. A direct connection can look like any other HTTPS API call. However, the protocol itself leaves fingerprints. The MCP specification defines identifying headers sent with each request. For example, a remote MCP request might 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"
    }
  }
}

The hostname and path identify the destination. The MCP-Protocol-Version header identifies the protocol version, while Mcp-Method and Mcp-Name expose the operation and tool in the new stateless protocol. The JSON-RPC envelope repeats the method, gives the request an ID, and carries the tool arguments. The arguments are the most sensitive part—they can contain search queries, source code, customer data, or instructions for actions like creating tickets or changing infrastructure.

Three Control Points, and Why the Network Matters

Security teams have three places to observe or control an MCP call:

1. Inside the MCP client: A client hook can run after the model selects a tool but before the request is serialized. It can see the destination, tool name, and arguments without decrypting network traffic. This is the earliest control point, but it requires reproducing controls across every client employees use. Telemetry from one client is never a complete inventory.

2. At the device’s network boundary: A secure web gateway can observe the HTTP request after it leaves the client. With TLS decryption, it can associate the request with a user and device, inspect destination and protocol headers, and apply policy without depending on a particular MCP client. The network layer has the widest lens to detect remote MCP traffic on managed paths, but it cannot see local stdio calls or off-network traffic.

3. Before the MCP server invokes the tool: The server has the richest execution context. It has authenticated the caller, parsed the message, and validated arguments. This is the last point where the request can be denied before the tool runs. Server-side controls only protect servers that implement them, but they cannot be bypassed by switching clients.

The network control point has the broadest coverage, but it first has to distinguish MCP from ordinary HTTPS traffic. A URL does not tell you that a request uses MCP. Searching for hostnames containing “mcp” or paths like /mcp misses servers at ordinary URLs and can match unrelated services. The protocol header is a more specific signal. The MCP 2025-11-25 specification says clients must include MCP-Protocol-Version on every HTTP request after initialization. The MCP 2026-07-28 specification goes further and requires it on every POST request. However, the header is not a complete detector: legacy clients may not send it, and local stdio or nonconforming traffic may never carry it.

How Cloudflare Detects and Governs MCP Traffic

Cloudflare One now provides capabilities to identify inspected MCP traffic, show which users and servers are generating it, and control direct connections on managed network paths. For customers using Cloudflare Gateway with TLS inspection, a detection heuristic answers a simple question for every inspected request: Is this MCP traffic?

Starting today, all Cloudflare Zero Trust customers see indications of MCP traffic in their Gateway HTTP logs and can explicitly block or allow that traffic with a new selector:

experimental.is_mcp == true

The selector is a boolean. If Gateway detects the MCP-Protocol-Version header on a TLS-inspected request, the value is true, and an administrator can use it in an Allow or Block policy without maintaining a list of MCP-looking domains. Direct encrypted traffic must pass through TLS decryption before Gateway can inspect these headers. Local stdio servers, off-network connections, Do Not Inspect traffic, and requests that never traverse Gateway remain outside this view.

A dedicated MCP traffic dashboard shows which hosts are serving MCP traffic, which users are generating it, and whether requests go through Cloudflare MCP Portals or bypass them. Administrators can filter by server, user, or on-ramp type, and navigate directly to Gateway HTTP logs for deeper investigation.

MCP discovery turns unknown traffic into a list an administrator can investigate. When an organization approves a server, it can place it behind a Cloudflare MCP Server Portal. The Portal gives employees one managed endpoint with Access identity, a curated tool catalog, and logging. Administrators can route compatible upstream calls through Gateway for HTTP policy, predictable egress, and data loss prevention. Tool activity can be exported through Logpush. The discovery dashboard can then distinguish requests that use the Portal from direct connections to the same server.

To enforce Portal-only access, Cloudflare is adding Traffic Source selectors to Gateway Network and HTTP policies. When MCP Portal traffic routes through Gateway, it carries an mcp_portal Traffic Source, which lets policy distinguish Portal-proxied requests from direct employee connections. A baseline enforcement rule looks like this:

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

Any detected MCP traffic that did not arrive through a Portal gets blocked; traffic that came through the Portal is unaffected. For organizations that want to observe before enforcing, Traffic Source and MCP detection now exist in HTTP logs for decrypted traffic, so you can monitor behavior without a policy.

Shadow MCP vs. Portal Bypass: Two Different Problems

Shadow MCP is a connection to a server the organization has not approved. An employee finds the server in a repository, product guide, or message from a colleague and adds it directly to their MCP client. The security team has no idea which tools it exposes or what data employees send to it.

Portal bypass is different: it starts with an approved server that the organization has placed in an MCP Portal, but an employee connects to its upstream URL directly and skips the Portal’s Access policy, curated tool catalog, data loss prevention, and tool-level audit trail.

Gateway is the primary control for shadow MCP on managed network paths. Portal bypass needs that network control plus an origin that can reject direct requests, whether that means an Access policy, a source IP restriction, or an enterprise authorization mechanism initiated by the MCP server itself.

Practical Deployment: Visibility First, Then Onboarding, Then Enforcement

Cloudflare recommends a phased approach. First, enable visibility: use Gateway logs and the MCP dashboard to see what MCP traffic exists on your network, who is using it, and where it goes. Run this for a week or two to build an inventory.

Second, onboard legitimate servers: move high-frequency, approved servers into MCP Portals. This gives users a governed path and reduces the incentive to bypass. 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, enforce Portal-only access: once selectors are available, block direct connections that bypass the Portal. Reversing the order—blocking before a legitimate path exists—will only push agent users to find more hidden exits, and you lose the visibility you just gained.

Cloudflare is also working to let MCP Portals connect to private servers through Cloudflare Gateway routing and the same Cloudflare One network used for other private applications. The private server keeps its private hostname; the Portal reaches it through Cloudflare’s private routing and presents its tools beside public upstream servers, with the same Access policy, Portal logging, and audit trail.

Key Takeaways for Product Builders

• MCP traffic is hard to identify by URL alone. Protocol headers like MCP-Protocol-Version, Mcp-Method, and Mcp-Name are more reliable signals, but they are not complete detectors.
• The network layer offers the broadest coverage for detecting remote MCP traffic, but it requires TLS decryption and a managed path.
• Shadow MCP and portal bypass are separate problems requiring different responses: onboarding for the former, enforcement for the latter.
• A phased approach—visibility, onboarding, enforcement—prevents users from seeking workarounds and preserves your ability to see what is happening.
• Cloudflare’s new selectors and dashboard make it practical to detect and govern MCP traffic without maintaining custom URL lists.

Sources

• Original source

AI-assisted summary compiled from the sources above, reviewed by a human before publishing.