Beyond the News
Sign in
Artificial IntelligenceCloud & InfrastructureAI AgentsEdge & CDN Active dossier

Cloudflare adds shadow-MCP detection and Portal-only enforcement

Cloudflare Gateway can now identify inspected MCP traffic, show which users and servers generate it, and block direct connections that bypass approved MCP Portals on managed network paths.

Reviewed and published by Lars Jansen Updated 4 min read
First published

Key details

  1. Cloudflare announced the MCP Gateway controls on August 14, 2026.
  2. Gateway detects MCP on TLS-inspected traffic using protocol-level signals rather than a fixed hostname or path list.
  3. All Cloudflare Zero Trust customers can see MCP indications in Gateway HTTP logs and use the `experimental.is_mcp` selector.
  4. A dedicated dashboard shows MCP request volume, users, servers, Portal traffic and direct device connections.
  5. Traffic Source selectors let policies distinguish `mcp_portal` traffic from direct connections.
  6. Local `stdio`, off-network, Do Not Inspect and non-Gateway traffic remain outside this visibility.
  7. Cloudflare says MCP Portals cannot yet reach servers available only on private networks.

What builders should take away

  1. If you already use Cloudflare Gateway with TLS inspection, start by observing `experimental.is_mcp` traffic before blocking it; use the dashboard to build an inventory of servers and users.
  2. Separate unapproved servers from approved-server bypasses. The remediation is different: investigate unknown servers, but put approved servers behind a governed Portal and block direct paths where feasible.
  3. Do not describe Gateway MCP detection internally as complete coverage. Pair it with client policy, endpoint controls and server-side authorization because local stdio and off-network use are invisible.
  4. For sensitive MCP servers, combine Portal routing with an origin control such as Access policy, source-IP restriction or server-enforced enterprise authorization so users cannot simply call the upstream directly.
  5. Review TLS inspection exceptions: every Do Not Inspect rule can become a blind spot for network-level MCP detection.

What changed

Cloudflare announced new Cloudflare One controls on August 14, 2026 for detecting and governing MCP traffic at the network layer. Gateway now classifies TLS-inspected MCP requests, exposes a dedicated MCP traffic dashboard, adds an `experimental.is_mcp` policy selector, and can distinguish traffic routed through Cloudflare MCP Portals from direct connections. Administrators can block detected MCP traffic that does not originate from an approved Portal.

Why it matters

MCP adoption creates a governance problem beyond individual AI clients: employees can connect coding agents and assistants directly to third-party or internal tool servers without central approval. Network-level detection gives security teams a way to discover some of that shadow usage and enforce an approved path without relying on every client implementing identical policy controls. The limits matter just as much: the mechanism only sees traffic that traverses Gateway and is decrypted, so it is not a universal MCP inventory.

How Cloudflare identifies MCP traffic

For session-based Streamable HTTP traffic, Cloudflare Gateway looks for protocol signals including the `MCP-Protocol-Version` header on TLS-inspected requests. Cloudflare says all Zero Trust customers now see MCP indications in Gateway HTTP logs and can use `experimental.is_mcp == true` in Allow or Block policy. The classification does not depend on a known hostname or `/mcp` URL pattern.

From discovery to an approved path

Cloudflare added a dedicated MCP traffic dashboard showing request volume, users, servers and whether traffic is flowing through MCP Portals or directly from devices. When a server is approved, administrators can move access behind an MCP Portal, then use a Traffic Source signal to distinguish Portal-proxied requests from direct connections. A baseline rule can block detected MCP traffic unless `traffic.onramp` is `mcp_portal`.

The blind spots are operationally important

Cloudflare explicitly says the visibility depends on network position and decryption. Local `stdio` MCP servers, off-network connections, Do Not Inspect traffic and requests that never traverse Gateway remain invisible. Private-network MCP servers also cannot yet be reached by MCP Portals; Cloudflare says it is working on private-server support through Gateway routing. Builders should therefore treat the new controls as one layer in a client-network-server control model, not as complete agent governance.

What to watch next

  • Cloudflare's planned support for MCP Portals reaching private-network servers.
  • Whether detection expands beyond the current protocol signals and how it handles protocol evolution or evasive clients.
  • Whether Cloudflare exposes richer tool- or argument-level policy at the Gateway layer rather than only traffic classification and routing signals.

Still unclear

  • Cloudflare describes its detection as a heuristic based on inspected protocol signals. Independent false-positive and false-negative rates are not yet available, and coverage necessarily excludes traffic outside the managed/decrypted network path.

Sources

Direct reading behind this dossier.

2 sources
Continue reading
Artificial Intelligence

Cloud Run sandboxes now work inside jobs and worker pools

Cloud Run sandboxes now cover all resource types. The August 5 expansion matters for builders whose agents or automation run in batch jobs or continuously pulling workers rather than HTTP services, while the feature remains pre-GA and shares CPU and memory with the host container.

Artificial Intelligence

Google Cloud opens an agent-ready device farm for mobile testing

Google Cloud’s Developer Device Platform is now in public preview with remote physical-device streaming, parallel emulator testing, smart sharding and an agent skill that can drive multi-step journeys, inspect visual issues and feed fixes back into coding agents. It is billed per active device minute and remains a pre-GA service.

Artificial Intelligence

GitLab 19.3 turns plain-English process knowledge into runnable agentic flows

Custom Flows became generally available in GitLab 19.2; 19.3 adds the missing authoring layer. Flow Creator reads current Flow Registry docs, applies known failure rules and generates a runnable flow from plain English. Builders still need to review, register and govern the automation rather than treating generated YAML as trusted infrastructure.