This site does not allow itself to be embedded. You can still read it on the original site — the toolbar below keeps your place in the directory.
Cloudflare Gateway now classifies MCP traffic by protocol headers instead of hostname heuristics, ships a shadow-MCP dashboard, and lets admins block any MCP connection that does not arrive through an approved portal. The 2026-07-28 stateless spec is what made it possible.
On August 14, Cloudflare shipped the missing layer of its MCP governance stack: network-level MCP traffic detection. Until now, an employee could point Claude Code, Codex, Cursor, or any other harness at an MCP server with one line of configuration, and security teams had no reliable way to see it. Cloudflare Gateway now classifies MCP traffic from protocol headers, exposes a dedicated MCP dashboard, and lets administrators block any MCP connection that does not arrive through an approved MCP Portal.
The story is not just another Cloudflare control panel feature. It is the first real-world payoff of the [2026-07-28 stateless MCP spec](/blog/mcp-2026-07-28-breaking-changes): the protocol finally carries enough identifying information on every request that ordinary HTTP infrastructure can see it.
## What shipped
Four capabilities landed together.
**Protocol-level detection in Gateway.** Gateway previously needed hostname or path heuristics (`mcp` in a URL, `/mcp` in a path) to guess at MCP traffic, which missed servers at ordinary URLs and produced false positives. Now it inspects the `MCP-Protocol-Version` header on every TLS-inspected request. Any Cloudflare Zero Trust customer gets a new Gateway selector, `experimental.is_mcp == true`, usable in Allow or Block policies without maintaining a list of MCP-looking domains.
**An MCP traffic dashboard.** Total requests, unique users, unique servers, per-server request counts, and a breakdown by on-ramp: traffic through an MCP Portal versus direct device connections. The "top MCP servers seen outside your Portals" list is the shadow MCP inventory, which is the part security teams had no visibility into before.
**Portal-only enforcement.** Traffic routed through an MCP Portal now carries an `mcp_portal` Traffic Source, so Gateway policies can distinguish proxied requests from direct ones. The baseline rule is one line:
```
experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")
Action: Block
```
Any detected MCP traffic that did not come through a Portal gets blocked; Portal traffic passes through untouched.
**Pre-registered OAuth clients for Portals.** MCP Portals can now hold manually configured OAuth credentials (client ID, secret, callback URL) instead of relying on Dynamic Client Registration, which the 2026-07-28 spec deprecated. Each user still authorizes their own upstream data sources; the stored client secret is used to fetch tool and prompt lists.
The Agents SDK also moved: v0.20.0 supports the stateless 2026-07-28 protocol as both client and server, probing with `server/discover` first and falling back to the legacy `initialize` handshake, so one client can serve both eras.
## Why the 2026-07-28 spec made this possible
The interesting technical detail is what changed between the two protocol generations. Under the legacy flow, the first request does not carry a protocol version header; the signal only appears after an `initialize` handshake completes. Under the [2026-07-28 spec](/blog/stateless-mcp-2026-spec-bun-fleet), the core protocol is stateless: every POST must carry `MCP-Protocol-Version`, and new headers `Mcp-Method` and `Mcp-Name` name the operation and tool on the wire.
That is a security property, not just an API design change. A network gateway can now identify a `tools/call` without parsing a JSON-RPC body, route, rate-limit, and enforce policy on the headers alone. Load balancers and rate limiters can separate `tools/list` from `tools/call`. This is the same architecture our [Bun stateless MCP experiment](/blog/stateless-mcp-2026-spec-bun-fleet) demonstrated: the protocol finally behaves like the rest of the web, which means the rest of the web's infrastructure can see it.
The header is not a complete detector. Cloudflare is explicit about the gaps: legacy clients' first requests, pre-2025-06-18 protocol versions, `stdio` (local) servers, custom transports, and traffic that skips TLS inspection never carry the signal. Its presence is a strong positive indicator; its absence proves nothing.
## The three control points, and where each fails
Cloudflare frames MCP security as three places to act, and the framing is the most useful part of the announcement.
**Inside the client** (hooks, allowlists) has the deepest request context and can cover local `stdio` servers, but you must reproduce the controls in every harness every employee uses, and telemetry from one client is never a complete inventory.
**At the network boundary** (Gateway) sees the widest set of remote connections and works regardless of client, but requires TLS decryption and cannot see `stdio` or off-network traffic.
**At the MCP server** (WriteGuard-style middleware) has the richest execution context and cannot be bypassed by switching clients, but only protects servers that implement it.
Shadow MCP and Portal bypass are different problems, and the new tooling treats them that way. Shadow MCP is a connection to a server nobody approved; the dashboard surfaces it. Portal bypass is an employee connecting directly to an approved server's upstream URL, skipping the Portal's Access policy, tool catalog, and audit trail; the `mcp_portal` Traffic Source plus an origin-side rejection handles that.
## What this means for developers
If you run an agent harness at work, assume your org's managed network can now see your MCP traffic and differentiate Portal-approved calls from direct ones. The practical consequence: point your tools at the approved Portal endpoint, not the upstream URL. Organizations get a discovery-to-governance path they did not have a week ago: find the server in the dashboard, decide whether to approve it, move it behind a Portal, and investigate the traffic that keeps going around it.
If you build or host MCP servers, the bar for "approved" just got mechanical. A server that supports manual OAuth registration is substantially easier to put behind a Portal than one that only does dynamic registration, which the [2026-07-28 spec](/blog/mcp-2026-07-28-breaking-changes) formally deprecated. Cloudflare is also working on private-network MCP servers: Portals currently reach only public-Internet upstreams, with private routing on the roadmap.
The honest caveats: this is Gateway-only detection, meaning orgs without TLS inspection get nothing, and the strict version of the policy (block anything not Portal-arriving) will flag every rogue personal MCP server someone plugged in last quarter. That is the point of the dashboard: observe first, enforce after the inventory is real. It is the same "declare yourself or be detected" trajectory as Cloudflare's [agent behavioral trust work](/blog/cloudflare-agent-trust-behavioral-detection-2026) and the [Agent Access Model](/blog/cloudflare-agent-access-model-2026): the agentic internet is being given infrastructure that assumes agents are first-class, identifiable traffic. MCP finally has a wire-level identity to match.
## Continue Reading
- [The MCP 2026-07-28 Rewrite: What Breaks and How to Migrate](/blog/mcp-2026-07-28-breaking-changes) - the breaking-change list, including dynamic registration deprecation
- [MCP Goes Stateless: Our Bun Fleet Experiment](/blog/stateless-mcp-2026-spec-bun-fleet) - the header mechanics that make wire-level detection possible
- [Vercel MCP Ships the 2026-07-28 Spec](/blog/vercel-mcp-2026-07-28-spec-support) - the platform-side adoption checkpoint
- [Zero-Touch OAuth for MCP](/blog/zero-touch-oauth-mcp-enterprise) - the authorization model Portals now plug into
- [Cloudflare Ships Behavioral Trust for the Agentic Internet](/blog/cloudflare-agent-trust-behavioral-detection-2026) - the same detect-and-govern pattern applied to traffic
## Sources
- [Cloudflare: How Cloudflare detects MCP traffic and helps secure it](https://blog.cloudflare.com/mcp-security-updates/) (August 14, 2026)
- [MCP 2026-07-28 specification: Streamable HTTP transport](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) - the protocol-version header requirement
- [MCP Portal documentation](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/) - OAuth configuration and Gateway routing
- [Cloudflare Agents SDK](https://developers.cloudflare.com/agents/model-context-protocol/) - v0.20.0 stateless protocol supportRead on developersdigest.tech ↗
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.