Most companies designed their resource permissions with a human user in mind. A senior engineer may be able to deploy to production, query a sensitive database, or revoke another user's access. Those privileges come with risk, but that risk has traditionally been bounded by two assumptions: the engineer will use human judgment, and the engineer can only act at human speed.
An engineer who sees an unexpected result will stop and reconsider. A human can only click, type, and review so much in a single day. AI agents change both thresholds. Their decisions are nondeterministic, and they can take the same action indefinitely, without getting tired. A plausible but incorrect decision can become thousands of incorrect actions before a human notices.
Today, we're announcing new capabilities to identify inspected MCP traffic, show which users and servers are generating it, and control direct connections on managed network paths.
The challenge of MCP
Model Context Protocol (MCP) servers give agents a common way to discover and invoke tools backed by third-party SaaS products, internal applications, and APIs. The underlying permissions are familiar; what changes is who makes each decision and how quickly a bad decision can spread.
Connecting an agent to one of these tools can take a single line of configuration. An employee can point Claude Code, Codex, Cursor, or any AI harness at an MCP server without checking whether it's approved. The resulting traffic has no obvious shape. MCP doesn't use a guaranteed hostname or require /mcp in the path, so a direct connection can look like any other HTTPS API call.
The anatomy of a tool call
The same MCP tool call has three forms as it moves through a system. Inside the client, it's a decision to invoke a tool with a set of arguments. On the network, it's an HTTP transaction carrying a message. At the server, it becomes a call to a tool handler that may read data, change state, or complete some other action.
Consider an agent that wants to know the weather in Austin. A remote MCP request looks like this:
Several signals are packed into this request: the hostname and path identify the destination, the authorization header carries the credential, and the Mcp-Protocol-Version and Mcp-Operation headers expose the protocol and operation. The arguments are the most sensitive part—they can contain search queries, source code, customer data, or instructions for critical actions.
Three control points
Security teams can act at three places:
Inside the client: A hook can run after the model selects a tool but before the client serializes the request. The client can deny a server not on an allowlist, ask the user to confirm a sensitive operation, or remove data from arguments before they leave the device. This works best when the organization manages both the client and the device, but telemetry from one client is never a complete inventory of MCP use.
On the network: A proxy can observe the HTTP request after it leaves the client. With TLS inspection, 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. It can identify direct connections to servers outside an approved portal and block them before the request reaches the destination.
At the MCP server: The server has the richest execution context. It has authenticated the caller, parsed the MCP message, resolved to a handler, and validated arguments against the tool's input schema. This is the last point where the request can be denied before the tool runs. Cloudflare uses this pattern across internal MCP servers with WriteGuard: each tool has a risk tier and an enabled/disabled state, and the guard can pass a read through, add agent attribution to an allowed write, or block a critical action before its handler runs.
Cloudflare's solution
Cloudflare One provides the networking pieces. The WARP client sends traffic from managed devices through Gateway. Gateway can classify MCP requests at the protocol layer and distinguish whether traffic is initiated from an MCP Portal or going outside approved controls.
For customers who have already adopted Cloudflare Gateway with TLS inspection, we're adding a detection heuristic that answers a simple question for every inspected request: is this MCP traffic?
For session-based Streamable HTTP connections, MCP clients send an Mcp-Protocol-Version header after initialization. Gateway inspects that header on every TLS-inspected request and classifies the traffic accordingly. 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 Gateway selector.
We're also introducing a dedicated MCP traffic dashboard that shows:
- Which hosts are serving MCP traffic within your network
- Which users are generating that traffic
- Whether requests are going through your Cloudflare MCP Portals or bypassing them entirely
Shadow MCP and portal bypass
Shadow MCP is a connection to a server the organization has not approved. An employee finds the server in a repository or a 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.
We're adding Traffic Source selectors to give administrators the fidelity to write rules that control MCP traffic based on whether it originated from your MCP Portals. A baseline enforcement rule: any detected MCP traffic that did not arrive through a Portal gets blocked; traffic that came through the Portal is unaffected.
Private connectivity and OAuth support
We're 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 the public upstream servers.
MCP Portals now also support pre-registered OAuth clients. An administrator can register the callback URL with the upstream provider and enter the client credentials. Each user still authorizes access to their own upstream data sources, and the stored client secret is used only to fetch updated tool and prompt lists.
Getting started
A workable MCP security program starts with understanding your users' traffic profiles and aligning on an approved set of tools. First, inspect the MCP traffic that traverses Gateway and compare its destinations with the servers your organization has approved. Move more approved servers behind MCP Portals. Then, enforce the boundary you can control: compose Gateway policies that use the MCP detection conditions together with Traffic Source and Destination conditions to block direct MCP connections from managed devices and sites.
We will soon be adding more granular functionality for visibility and control of MCP traffic, including control over specific tool use and new reporting on tool usage across all MCP servers within your environment.