Cloudflare Adds MCP Traffic Detection and Control to Cloudflare One

Most companies built their permission models around a human user. A senior engineer might deploy to production or query a sensitive database, but that power was bounded by human judgment and human speed. AI agents break both assumptions: their decisions are nondeterministic, and they can invoke the same tool thousands of times before anyone notices a mistake.

Cloudflare is addressing this with new Cloudflare One capabilities that detect Model Context Protocol (MCP) traffic at the network layer. The feature identifies inspected MCP requests, shows which users and servers are generating them, and lets admins control direct connections on managed paths. Combined with MCP Server Portals, it helps answer a key question: are agents using the approved path, or are they bypassing it?

Why MCP traffic is hard to spot

MCP servers give agents a standard way to discover and invoke tools backed by SaaS products, internal apps, and APIs. Connecting an agent to one of these tools can be a single line of config. An employee can point Claude Code, Codex, Cursor, or any AI harness at an MCP server without checking if it's approved. The traffic has no obvious shape — MCP doesn't require a specific hostname or a /mcp path, so a direct connection can look like any other HTTPS API call.

Cloudflare's first detection approach searched Gateway HTTP logs for hostnames containing mcp and common paths like /mcp or /sse. That works for older clients but misses servers at ordinary URLs like https://tools.example.com/api. The new protocol-level detection is more reliable.

Three places to control an MCP request

An MCP tool call can be observed or controlled at three points:

• Inside the MCP client: Client hooks can see the destination, tool name, and arguments before the request is serialized — no TLS decryption needed. But controls must be replicated across every client, and local stdio servers never touch the network.
• At the network boundary: A secure web gateway with TLS decryption can associate requests with users and devices, inspect protocol headers, and block direct connections to non-approved servers. It can't see local stdio calls or off-network traffic.
• At the MCP server: The server has the richest context — it has authenticated the caller, parsed the message, and validated arguments. Server-side middleware can authorize per-tool, rate-limit, and block before the handler runs. Cloudflare's WriteGuard uses this pattern internally.

The network layer has the widest lens, but it first has to distinguish MCP from ordinary HTTPS. Cloudflare One now does that by classifying requests at the protocol layer, using headers like MCP-Protocol-Version, Mcp-Method, and Mcp-Name, plus the JSON-RPC envelope.

What this means for security teams

With these controls, admins can report on or block connections that don't follow the approved path. The detection works on managed devices running the Cloudflare One Client, and the MCP Server (or Portal) can verify that the proxy was used. It's a defense-in-depth approach: client hooks for depth, network for breadth, and server-side checks for enforcement that can't be bypassed by switching clients.

The underlying permissions haven't changed — what's changed is who makes each decision and how fast a bad decision can spread. Cloudflare's new capabilities give teams a way to see and stop that spread.