Cloudflare Now Detects and Blocks Rogue MCP Traffic
Quick Reads
- Cloudflare Gateway can now identify MCP traffic using protocol-level signals, not just URLs.
- A new MCP traffic dashboard shows which servers and users are generating AI agent traffic.
- Security teams can block direct MCP connections and enforce Portal-only access via a single Gateway rule.
- Cloudflare Agents SDK v0.20.0 now supports the new stateless MCP 2026-07-28 specification.
- Private MCP servers will soon connect through Cloudflare’s internal routing, expanding enterprise coverage.
Cloudflare published a major security update on August 14, 2026, introducing new capabilities inside Cloudflare One to identify inspected MCP traffic, reveal which users and servers are generating it, and control direct connections across managed network paths.
The announcement matters because AI agents are not like human users. They do not stop to reconsider when something looks off. They can call the same tool thousands of times before any human notices. That speed creates a real gap in how most organisations think about access control.
Most companies designed their resource permissions with a human user in mind, someone who exercises judgment and can only act at human speed. AI agents change both thresholds: their decisions are nondeterministic, and a plausible but incorrect decision can become thousands of incorrect actions before anyone catches it.
That is precisely what makes Cloudflare MCP traffic security updates so timely.
The core problem is visibility. The Model Context Protocol lets AI agents discover and invoke tools backed by SaaS products, internal apps, and APIs. Connecting an agent to one of those 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 is approved. The resulting traffic blends in with ordinary HTTPS calls.
Until now, that traffic was nearly invisible to security teams.
Cloudflare’s answer is protocol-level detection. The MCP 2025-11-25 specification requires clients to include an MCP-Protocol-Version header on every HTTP request after initialization, and the MCP 2026-07-28 specification goes further by requiring it on every POST request. Cloudflare Gateway reads that header on every TLS-inspected request and classifies traffic accordingly, without relying on a known hostname or a list of MCP-looking URLs.
Starting today, all Cloudflare Zero Trust customers can see indications of MCP traffic in their Gateway HTTP logs and can explicitly block or allow that traffic using a new Gateway selector: experimental.is_mcp == true. That single boolean is enough to write a policy without maintaining your own domain list.
The new MCP traffic dashboard puts that detection to practical use. It shows total MCP requests, unique users, and unique servers over a configurable time window, a traffic breakdown by on-ramp separating Portal traffic from direct device connections, and the top MCP servers seen outside your Portals, which is the shadow MCP traffic that matters most.
For Nigerian enterprises and African businesses running developer teams on tools like GitHub Copilot or Cursor, this dashboard offers something genuinely new: proof of which AI tools your employees are connecting to, and whether any of them are bypassing your approved access controls.
Shadow MCP and Portal bypass are two different threats. Cloudflare draws that distinction clearly. Shadow MCP is a connection to a server the organisation has not approved. Portal bypass is different, it starts with an approved server, but an employee connects to its upstream URL directly and skips the Portal’s Access policy, curated tool catalog, data loss prevention, and audit trail. Both need separate responses.
To enforce the boundary, 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. A baseline enforcement rule, experimental.is_mcp == true and not traffic.onramp in ("mcp_portal") with action Block, stops any detected MCP traffic that did not arrive through a Portal, while Portal traffic continues unaffected.
OAuth support has also expanded. Earlier MCP specifications relied on Dynamic Client Registration, which many providers do not support. MCP Portals now support pre-registered OAuth clients. An administrator can configure manual OAuth credentials, register the callback URL with the upstream provider, and enter the client credentials. Each user still authorises access to their own upstream data sources individually.
On the protocol side, Cloudflare Agents SDK v0.20.0 supports MCP 2026-07-28 as both a client and a server. For each connection, the client first probes for the new stateless protocol; if the server does not support it, the client continues with the legacy initialize handshake on the same connection. That backward compatibility matters for teams managing mixed infrastructure.
Finally, private MCP server support is coming. Cloudflare is working to let MCP Portals connect to private servers through Cloudflare Gateway routing and the same Cloudflare One network already used for private applications. The private server keeps its private hostname, while the Portal reaches it through Cloudflare’s internal routing and presents its tools beside public upstream servers.
For teams managing sensitive business data, fintech platforms, e-commerce backends, or internal developer tools, that private connectivity layer closes the last major gap in MCP governance.
Cloudflare’s MCP traffic detection tutorial covers the hostname, path, and JSON-RPC heuristics available in Gateway logs today. More granular tool-level controls and usage reporting across all MCP servers are coming soon.
