Cloudflare on August 14, 2026 gave network administrators a way to see Model Context Protocol traffic inside encrypted enterprise sessions and to block connections that skip an approved path, adding a boolean policy selector, a dedicated traffic dashboard and origin labels that separate portal-proxied requests from direct ones.

The announcement, published on the company blog by AJ Gerstenhaber and Kenny Johnson, covers three connected releases inside Cloudflare One: a detection heuristic that classifies inspected requests as MCP or not, a dashboard that lists which internal hosts and users generate that traffic, and a set of Traffic Source selectors that let a policy distinguish a request routed through a Cloudflare MCP Portal from an employee connecting straight to the upstream server.

The framing in the post is a permissions argument rather than a threat-actor one. Corporate access models, according to Cloudflare, were designed around a human operator, and the risk attached to a broad permission has historically been bounded by two assumptions: that the person exercising it applies judgment, and that the person can only work at human speed. A senior engineer able to deploy to production or query a sensitive database is constrained by both. Agents are constrained by neither. Their decisions are nondeterministic, and, in the words of the post, they can invoke the same tool indefinitely, "without getting tired or stopping for lunch." Cloudflare describes the consequence directly: a plausible but incorrect decision can become thousands of incorrect actions before a human notices.

A single line of configuration

The operational problem the release addresses is how little effort it takes to create the exposure. Connecting an agent to a tool server can take one line of configuration. An employee can point Claude Code, Codex, Cursor, OpenCode, VS Code or any other harness at an MCP server without checking whether it has been approved, and the traffic that results carries no distinguishing shape at the network layer.

That is a specification fact rather than an implementation quirk. Model Context Protocol does not mandate a hostname pattern and does not require the string /mcp in a request path. A direct connection to a tool server can look, from outside, like any other HTTPS API call.

The anatomy of a tool call

The post works through what a remote MCP request actually contains, using an agent asking for the weather in Austin as the example. A conforming request under the newest specification carries a POST to a path, a Host header, an Authorization bearer token where the server requires authentication, and three protocol headers: MCP-Protocol-Version identifying the specification version, Mcp-Method carrying the operation, and Mcp-Name carrying the tool being called. The body is a JSON-RPC envelope that repeats the method, assigns the request an id the client can match against a response, and packs the tool arguments into a params object.

Cloudflare identifies the arguments as the sensitive part. A tool name states what the agent intends to do. The arguments state what data leaves the device and what action the server is being asked to perform, and they can hold a search query, source code, customer records, or an instruction to create a ticket or change infrastructure. The response carries the same id and the tool result, which may itself contain sensitive data. Request inspection can stop an unsafe action before it executes; response inspection and logging establish what came back.

The same call takes three forms as it moves. Inside the client it is a decision to invoke a tool with a set of arguments. On the network it is an HTTP transaction carrying a JSON-RPC message. At the server it becomes a call into a tool handler that may read data or change state.

Three places to intervene, each with a gap

Each of those three forms is a control point, and the post is unusually candid about what each one cannot do.

A client hook runs after the model has selected a tool but before the client serializes the request. It sees the destination, the tool name and the arguments without any need to decrypt network traffic, and it can deny a server absent from an allowlist, prompt for confirmation on a sensitive operation, or strip data from arguments before they leave the device. It is also the only one of the three that covers local stdio servers, which never generate network traffic at all. The problem is standardization: a security team would have to reproduce its controls across every client its employees use, and telemetry from one client is never a complete inventory.

The network boundary offers the widest lens. A secure web gateway with TLS decryption can associate a request with a user and a device, read the destination and protocol headers, and apply policy without depending on which MCP client produced the request. Where data loss prevention scanning is supported, a proxy can also examine the JSON-RPC method and the arguments. Proxies cannot see local stdio calls or traffic that never touches the managed network.

The server holds the richest execution context. By the time a request reaches the handler the caller has been authenticated, the message parsed, the tool name resolved, and the arguments validated against the tool's input schema. It is the last point at which a request can be denied before the tool runs. Cloudflare describes its own internal implementation, WriteGuard, which assigns each tool a risk tier and an enabled or disabled state; it passes a read through unchanged, attaches agent attribution and an audit event to an allowed write, and blocks a critical action before its handler executes. Because that control lives at the server, an end user cannot get around it by switching clients or disabling a local hook. The limitation is scope: server-side controls only protect servers that implement them.

Why a URL is not a signal

Cloudflare's first approach to finding this traffic relied on the GraphQL Analytics API and searched Gateway HTTP logs for hostnames containing mcp along with common paths such as /mcp or /sse, supplemented by data loss prevention patterns matching JSON-RPC method names including initialize, tools/call and resources/read inside request bodies.

The post calls those signals "very basic." They remain useful for older clients and for historical visibility, but they miss a server hosted at an ordinary URL, and Cloudflare notes that a tool server sitting at something like https://tools.example.com/api is not uncommon. They can also produce false positives against unrelated services that happen to carry mcp in a hostname or path, which the company describes as unlikely but observed.

The protocol header is the more specific signal. The MCP 2025-11-25 specification requires clients to include MCP-Protocol-Version on every HTTP request after initialization. The 2026-07-28 specification goes further and requires it on every POST request.

That still does not make the header a complete detector, and Cloudflare says so. The first request from a legacy client may not carry it, since the legacy flow opens with an initialize request that predates the header. Protocol versions earlier than 2025-06-18 never defined it. Local stdio transports, custom transports and nonconforming implementations may never carry it at all. The company's own summary of the asymmetry is that the presence of the header is a strong positive indicator of MCP, while its absence does not prove that a request is not MCP.

The stateless rewrite changed the wire

Part of what makes network-layer detection viable now is a change in the protocol itself. The 2026-07-28 specification removes the initialize handshake and moves to a stateless per-request model, placing the protocol version and the operation on every request. PPC Land covered that rewrite and its infrastructure consequences for ad tech vendors when the specification landed.

The practical effect at the network layer is that Mcp-Method and Mcp-Name let ordinary HTTP infrastructure identify an operation without parsing a body. Load balancers can route on a header. Rate limiters can treat tools/list differently from tools/call. Security products get more information on every request rather than only at session setup. Detection that once required deep packet inspection becomes header inspection.

Shadow MCP and portal bypass are different problems

The post draws a distinction that matters for how any resulting policy is written. Shadow MCP is a connection to a server the organization has never approved: an employee finds it in a repository, a product guide or a message from a colleague and wires it into a client directly. The security team has no record of what tools it exposes or what data has been sent to it.

Portal bypass starts from an approved server. The organization has placed it behind a Cloudflare MCP Portal, but an employee connects to the upstream URL directly, skipping the Portal's Access policy, its curated tool catalog, its data loss prevention and its tool-level audit trail. The server is sanctioned; the path is not.

Gateway addresses the first case on managed network paths by identifying TLS-inspected MCP traffic, surfacing the destination and the user, and applying policy. The second case, Cloudflare states, requires the network control plus an origin capable of rejecting direct requests, whether through an Access policy, a source IP restriction, or an authorization mechanism the MCP server itself initiates. Detection alone does not close a bypass if the upstream server will still answer a direct call.

What shipped on August 14

For customers already running Gateway with TLS inspection, Cloudflare added a detection heuristic that resolves a single question on every inspected request: is this MCP traffic? Gateway reads the MCP-Protocol-Version header on each TLS-inspected request and classifies accordingly, using detection the company says was built from patterns observed across the millions of requests crossing its network daily. The classification identifies MCP negotiation and proxying to a hostname without requiring prior knowledge of the host or URL.

From that date, all Cloudflare Zero Trust customers see MCP indications in Gateway HTTP logs and can allow or block the traffic through a new selector, expressed as experimental.is_mcp == true. The selector is a boolean, which means an administrator can write an Allow or Block policy without maintaining a private list of MCP-looking domains.

The exclusions are stated plainly. Encrypted traffic has to pass through TLS decryption before Gateway can read these headers. Local stdio servers, off-network connections, traffic marked Do Not Inspect, and any request that never traverses Gateway remain outside the view entirely. The detection covers the managed path, not the whole estate.

A dedicated MCP traffic dashboard arrived the same day. It reports total MCP requests, unique users and unique servers across a configurable window; MCP servers over time with per-server request counts; a traffic breakdown by on-ramp that separates Portal traffic from direct device client connections; the top MCP servers observed outside Portals; and the top users by request volume. Administrators can filter by server, user or on-ramp type and jump into Gateway HTTP logs already filtered by host or user.

Enforcing portal-only access

Traffic Source selectors are the enforcement half. Added to both Gateway Network and HTTP policies, they let a rule turn on where a request originated. Portal traffic routed through Gateway carries an mcp_portal Traffic Source, which separates a Portal-proxied request from a direct employee connection.

The baseline rule Cloudflare publishes combines the two signals: experimental.is_mcp == true and not traffic.onramp in ("mcp_portal"), with a Block action. Detected MCP traffic that did not arrive through a Portal is blocked; Portal traffic passes untouched. For organizations that want to observe before enforcing, both the Traffic Source and the MCP detection now appear in HTTP logs for decrypted traffic, so behaviour can be monitored without a policy in place.

Behind an approved Portal, employees get one managed endpoint with Access identity, a curated tool catalog and logging sitting in front of the upstream server. Compatible upstream calls can be routed through Gateway for HTTP policy, predictable egress and data loss prevention, either across an entire Portal or for a single server, and tool activity can be exported through Logpush.

OAuth registration and the private-network gap

Two constraints on Portal coverage received attention, one closed and one still open.

Earlier MCP specifications recommended Dynamic Client Registration, in which a client registers itself with an authorization server without a pre-existing OAuth application. Many widely deployed OAuth providers work the other way, requiring an administrator to register an application with a fixed client ID, client secret, callback URL and scope set. The 2026-07-28 specification deprecated dynamic registration. MCP Portals now accept pre-registered OAuth clients: an administrator configures manual credentials, registers the callback URL shown in the dashboard with the upstream provider, and enters the client credentials. The Portal discovers standard OAuth metadata where that is available, and the administrator can supply authorization, token, revocation and issuer endpoints where it is not. Each user still authorizes access to their own upstream data sources, and the stored client secret is used only to refresh tool and prompt lists.

Cloudflare does not claim that closes the compatibility question. Providers that require custom headers, personal access tokens or an explicit client allowlist are named as separate problems, with expanded support promised over the coming months.

The open gap is private infrastructure. A Portal today must be able to resolve and reach an upstream server over the public internet, which means servers reachable only through private DNS or inside private IP space cannot be placed behind one. Most of the information enterprises actually guard sits in exactly those locations. Cloudflare says it is working to let Portals reach private servers through Gateway routing and the same Cloudflare One network already used for other private applications, keeping the private hostname while Access policy, Portal logging and tool controls continue to apply at the same front door. The feature is described as in active development, with the changelog named as the place updates will appear.

Agents SDK v0.20.0

The release also covers the developer side. Cloudflare Agents SDK v0.20.0 supports MCP 2026-07-28 as both client and server. On each connection, the client first probes for the stateless protocol using server/discover; if the server does not support it, the client continues with the legacy initialize handshake on the same connection. Existing addMcpServer calls require no separate protocol settings or separate clients. On the server side, createMcpHandler can serve stateless tools, prompts, resources and elicitation from a Worker without creating a transport session or a Durable Object.

The dual-path design reflects a migration reality: protocol transitions do not happen at once, a new client still has to reach an old server, and a new server still has to answer clients that have not moved.

Cloudflare closes with a sequence it describes for building an MCP security programme - inspect the traffic crossing Gateway, compare destinations against approved servers, move approved servers behind Portals, then compose policies combining the MCP detection condition with Traffic Source and Destination conditions - and flags further work on control over specific tool use and reporting on tool usage across known and unknown servers.

Why this matters for marketing technology

The relevance to advertising operations is not hypothetical, because the advertising stack has already standardized on this protocol. Google released an open-source MCP server for its Ads API on October 7, 2025, enabling natural-language querying of campaign data. Microsoft expanded its Advertising MCP server to open pilot in June 2026 with read-only access to live campaign data from inside Copilot, Claude and ChatGPT. Meta shipped a Developer Tools MCP server in July 2026, following ads connectors that launched with write access. Pacvue brought retail media data into the same assistants, Pinterest published a campaign-data server, AdRoll and PubMatic wired agents together to diagnose deal delivery, and Prebid.js merged a DevTools MCP module exposing live header bidding state to connected agents.

Every one of those endpoints is, from a network administrator's position, an HTTPS destination that an employee can add to a client without approval. The arguments travelling to a campaign-management server are not weather queries. They are account identifiers, audience definitions, budget figures and, where write access exists, instructions that change live spend. An agency analyst connecting a personal assistant directly to an ads MCP endpoint rather than through a governed path produces exactly the pattern Cloudflare labels shadow MCP, and the audit trail that would normally record a campaign change sits with the platform rather than the buyer.

The concern is not new to this coverage. PPC Land reported on security weaknesses in MCP implementations affecting marketing technology platforms in July 2025, when the protocol was still largely a developer curiosity. UK regulators warned in April 2026 that agentic systems granted broad permissions expand the attack surface, citing prompt injection as a risk amplified when an agent autonomously ingests content from multiple sources. Independent research into agentic browsers documented instructions hidden in page content driving cross-site actions that a user never requested.

Cloudflare's own limits define the residual exposure with some precision. A control that depends on TLS inspection on a managed device sees nothing when an analyst works from an unmanaged laptop, nothing when a tool server runs locally over stdio, and nothing on traffic excluded from inspection. Agency staff working across client environments, contractors on their own hardware and anyone operating outside a corporate network sit outside the boundary this release draws. The detection is a boolean on a header, and headers can be absent.

What the release does establish is a measurable baseline. Before it, an organization asking which MCP servers its staff had connected to had no reliable way to answer on the network path. After it, on inspected traffic, the question resolves to a dashboard listing hosts, users and request counts, with a column distinguishing governed connections from direct ones. For advertising organizations whose agent workflows now touch programmatic supply, retail media reporting and campaign write operations through the same protocol, that column is the difference between a governance claim and an observation.

Timeline

Summary

Who: Cloudflare, in a blog post authored by AJ Gerstenhaber and Kenny Johnson, addressing Cloudflare One and Zero Trust customers and, indirectly, any organization whose staff connect AI agents to Model Context Protocol servers.

What: Three connected capabilities. Gateway now classifies TLS-inspected requests as MCP traffic using the MCP-Protocol-Version header, exposed through a boolean policy selector written as experimental.is_mcp. A dedicated dashboard reports MCP requests, unique users, unique servers, per-server counts, top servers seen outside approved Portals, and top users by volume. Traffic Source selectors in Gateway Network and HTTP policies stamp Portal-routed requests with an mcp_portal value, allowing a rule to block detected MCP traffic that did not arrive through a Portal. MCP Portals additionally gained support for pre-registered OAuth clients following the 2026-07-28 specification's deprecation of Dynamic Client Registration, and Agents SDK v0.20.0 shipped with support for the stateless protocol as both client and server, probing with server/discover and falling back to the legacy initialize handshake.

When: August 14, 2026, a Friday. The MCP-Protocol-Version header the detection depends on was introduced in specification version 2025-06-18, required on every request after initialization from 2025-11-25, and required on every POST request from 2026-07-28.

Where: Across Cloudflare's global network, applied to traffic from managed devices routed through Gateway with TLS inspection enabled. Local stdio servers, off-network connections, Do Not Inspect traffic and any request that never traverses Gateway fall outside the detection. MCP Portals currently require an upstream server reachable over the public internet, leaving servers on private DNS or private IP space unsupported pending work Cloudflare describes as in active development.

Why: Enterprise permission models assume a human operator applying judgment at human speed, and agents satisfy neither assumption. Because MCP mandates no hostname convention and no path convention, a direct connection to an unapproved tool server is indistinguishable from an ordinary HTTPS API call without protocol-level inspection. The release separates two problems that had previously been observed as one: connections to servers an organization never approved, and connections that route around the governed path to servers it did approve.