Cloudflare: How MCP Detection Turns Shadow Agent Traffic Into a Security Decision

Cloudflare has expanded MCP traffic detection beyond obvious server names, exposing a conflict that security teams could previously miss. The Cloudflare how question now starts with protocol evidence, not a list of known domains. Gateway can inspect managed HTTP traffic for MCP-specific paths and JSON-RPC methods, then distinguish approved Portal traffic from direct connections.

That distinction matters because Model Context Protocol, or MCP, lets AI agents call external tools and retrieve private data. A single connection might reach source code, customer records, cloud controls, or messaging systems. When employees configure remote servers without review, the resulting shadow MCP activity resembles shadow IT with an agent capable of taking actions.

Cloudflare’s answer combines discovery with an enforcement path. Gateway supplies the network signal, while MCP server portals centralize approved servers behind one endpoint. Access policies govern identity and device conditions, and data loss prevention, or DLP, can inspect tool requests and responses. The unresolved question is whether organizations can route enough traffic through those controls to make the model reliable.

Cloudflare How MCP Detection Reads the Protocol

Cloudflare’s important change is the move from guessing destinations to recognizing MCP behavior inside inspected HTTP traffic.

The simplest detection method looks at the destination hostname. An administrator can search Gateway logs for known MCP endpoints or hostnames containing mcp. This approach catches services that advertise their purpose through names such as mcp.example.com.

A second signal comes from the request URI. Remote servers commonly expose paths such as /mcp, /sse, or /mcp/sse. Gateway can search logged requests for these patterns even when the hostname itself appears generic.

Both methods are useful for an initial inventory, but neither proves that a request carries MCP. A normal application can use the same path. An MCP server can also hide behind an ordinary hostname and an unremarkable API route.

Cloudflare therefore points administrators toward body inspection. MCP encodes messages using JSON-RPC, a structured request format containing fields such as jsonrpc, method, and params. Standard method names create recognizable protocol-level evidence.

Examples include initialize, tools/list, tools/call, resources/read, and prompts/get. A DLP profile can search POST bodies for those strings, even when the domain and path reveal nothing. Cloudflare published example regular expressions in its MCP architecture that cover several common methods and protocol-version fields.

The initialize method is especially useful because it begins the relationship between an MCP client and server. A client declares its protocol version, capabilities, name, and version. The server answers with its own capabilities and may create a session.

Tool calls produce a stronger operational signal. A request containing tools/call indicates that the agent is attempting to invoke a capability, not merely checking whether an endpoint exists. The arguments can also reveal which data or action the tool will handle.

The Cloudflare how model is therefore layered:

• Hostname patterns identify known or plainly named MCP servers.

• URI patterns identify conventional remote MCP endpoints.

• JSON-RPC methods identify MCP behavior on less obvious endpoints.

• User and device fields connect that behavior to a person or managed system.

• Gateway actions show whether the request was allowed, blocked, or otherwise handled.

Cloudflare’s documented workflow uses the gatewayHttpRequestsAdaptiveGroups dataset in its GraphQL Analytics API. Administrators can group results by host, URI, user, action, and matched DLP profiles. The dataset supports up to 30 days of historical queries, according to the company’s detection tutorial.

This is not content-aware threat detection in the broadest sense. A match on tools/call says that an MCP tool was invoked. It does not determine whether the tool is trustworthy, whether its instructions are malicious, or whether the action fits the user’s intent.

Still, protocol recognition closes an important visibility gap. A security team no longer needs to know every MCP vendor or endpoint before beginning an investigation. It can search for properties of the protocol itself.

That creates the article’s central tension. Detection can reveal direct MCP traffic, but a signal alone does not establish which connections should remain available. Cloudflare needs a governed alternative before an administrator can block the unmanaged path without stopping legitimate work.

Shadow MCP Puts Security Teams Between Access and Adoption

The immediate pressure falls on security teams that must separate useful agent connections from unreviewed access to sensitive systems.

MCP standardizes how an AI application discovers tools, reads resources, retrieves prompts, and invokes actions. The protocol reduces custom integration work, which also makes it easier for employees and developers to add servers without a central deployment project.

That speed creates a familiar governance problem. A user can configure an MCP client with a remote server URL and grant access using OAuth or another credential. The security team might never see the setup inside its approved software catalog.

The risk is larger than an unauthorized web application visit. An MCP server exposes tools to an agent, and those tools can carry meaningful permissions. Depending on the integration, they might search documents, read repositories, open support records, modify infrastructure, or send messages.

A legitimate tool can still receive inappropriate data. An employee might ask an agent to analyze a customer issue, then unknowingly send regulated information to an external server. A compromised or deceptive server could also return instructions designed to manipulate later agent behavior.

This is why Cloudflare describes unmanaged connections as shadow MCP. The defining issue is not whether every unknown server is hostile. It is that the organization has not reviewed the server, its operator, its requested permissions, or the data flowing through it.

Gateway logs can turn that unknown activity into an inventory. Administrators can identify users, destination hosts, request volumes, policy actions, and detected protocol methods. They can then investigate which client created the traffic and what business purpose it serves.

The inventory also supports more measured enforcement. A team could log initial matches, review active destinations, and classify each server before blocking anything. High-confidence cases, such as direct traffic to an unapproved remote tool, can receive a stricter policy.

However, managed network coverage defines the boundary. Gateway must actively proxy the relevant HTTP traffic. If an employee uses an unmanaged device, a separate network path, or a client outside the organization’s controls, those requests will not appear in the same logs.

Encrypted traffic adds another condition. Gateway needs TLS decryption to inspect the HTTP body of a direct MCP connection. Without it, administrators might see the destination hostname but miss JSON-RPC methods and tool arguments.

Cloudflare handles Portal traffic differently. The Portal terminates the client connection and creates a new connection to the upstream server. That architecture allows Gateway to inspect routed Portal traffic without relying on the account-wide TLS decryption setting.

Direct traffic does not receive that automatic treatment. Cloudflare’s Portal documentation says an agent connecting directly through a WARP-managed device requires the normal TLS decryption configuration for body inspection.

There are also legitimate reasons to exempt traffic from inspection. Privacy requirements, certificate-pinning applications, or operational constraints can lead teams to create Do Not Inspect policies. Those policies take precedence and can leave matching MCP activity outside DLP analysis.

These limits do not make the detection useless. They define what the resulting dashboard actually means. A report shows MCP-like activity visible on inspected, managed paths. It is not a complete census of every agent connection across the company.

That distinction should shape incident response. A detected connection deserves investigation, but an empty report does not prove that shadow MCP is absent. Security teams need endpoint coverage, identity data, and client configuration controls alongside network detection.

The Real Contest Is Portal Access Versus Direct Connections

Cloudflare’s security model only becomes enforceable when approved Portal access replaces direct server URLs on managed paths.

An MCP server portal aggregates multiple approved servers behind one HTTP endpoint. Users configure that endpoint in their MCP client, authenticate through Cloudflare Access, and receive only the servers and tools allowed by policy.

The Portal performs several jobs that direct connections distribute across individual integrations. It identifies the user, evaluates Access rules, manages upstream authentication, exposes approved tools, and logs requests. Administrators can organize servers without asking every employee to maintain a separate list of endpoints.

Access policies can use identity groups, location, and device posture. A finance portal might expose selected read-only tools to finance employees. An engineering portal could permit additional actions only from managed corporate devices.

Administrators can also hide individual tools or prompts. This matters because approving a server does not require approving every capability it publishes. A server with repository access might expose search and read operations while its write operation remains unavailable.

Cloudflare’s Portal design supports unauthenticated upstream servers and servers protected by OAuth. Users can authenticate separately to an upstream service, or some machine-to-machine workflows can use Access service tokens. The Portal then attaches the appropriate credentials when proxying a tool call.

When Gateway routing is enabled, real-time calls pass from the Portal through Gateway before reaching the upstream server. Gateway logs the requests and can apply HTTP and DLP policies. Egress controls can also give those requests predictable source addresses.

This creates a practical allow-and-block pattern. Security teams give employees an approved Portal endpoint, then create Gateway rules that stop direct connections to upstream MCP servers. The Portal path remains available while ungoverned alternatives are restricted.

The policy must target the right destination. Cloudflare says DLP rules for Portal traffic should match the upstream MCP server hostname, not merely the Portal domain. The Portal is the client-facing entry point, but Gateway evaluates the re-originated request traveling toward the actual server.

The arrangement resembles an application gateway more than a simple directory. It provides a chokepoint where identity, tool selection, logging, and data controls meet. That chokepoint is what turns discovery into governance.

Yet the direct URL remains a central weakness. Cloudflare warns that hiding a server from a Portal does not prevent a user from connecting to its original address. If the upstream server remains publicly accessible, Portal policy alone cannot stop bypass.

Organizations therefore need an enforcement control outside the Portal’s interface. They can protect a server with Access when they control its hostname, restrict inbound traffic to known egress addresses, or block direct destinations through Gateway. Third-party services will require whatever controls their deployment model supports.

The choice is not Cloudflare versus another security vendor. The primary opponent is governed Portal access versus direct, user-configured connections. Every major feature serves that contest.

Portal logs identify approved activity. Gateway discovery looks for traffic outside the approved route. Access establishes who can use the Portal. DLP evaluates data crossing the managed path. Network policy attempts to close the direct route.

This model also gives developers a usable destination after enforcement begins. A blanket ban on MCP would push experimentation outside official channels. A curated Portal lets teams keep approved tools available while security reviews additional servers.

The result depends on operational discipline. Someone must own the approved-server catalog, review tool permissions, maintain Access policies, and respond to newly detected destinations. Centralization reduces scattered controls, but it does not remove those decisions.

Protocol Heuristics Create Coverage, Not Certainty

Cloudflare can identify strong MCP indicators, but those indicators do not prove that a connection is safe, malicious, or correctly governed.

The detection patterns are heuristics. A body containing "method":"tools/call" closely resembles MCP, yet another JSON-RPC application could use the same method name. A custom MCP implementation could also produce formatting that falls outside a narrowly written regular expression.

Whitespace allowances illustrate the problem. Example expressions permit a limited amount of spacing around JSON fields. Reordered fields should remain detectable when each pattern targets one field, but alternative serialization and escaping can complicate matching.

Encrypted or unsupported traffic creates larger gaps. DLP cannot inspect a direct HTTPS body unless Gateway decrypts it. Local MCP servers communicating through standard input and output do not traverse an HTTP gateway at all.

Streamable HTTP is the most important remote transport in Cloudflare’s current design. The MCP transport specification defines HTTP requests carrying JSON-RPC messages and optional session identifiers. Those regular structures help Gateway recognize the protocol.

Cloudflare’s routed Portal path supports Streamable HTTP. If an upstream server only supports the older Server-Sent Events transport, Gateway routing will fail for that server. The Portal attempts Streamable HTTP when routing is enabled, but the upstream service must support it.

Background synchronization is another exception. Portals periodically retrieve tools and prompts from upstream servers, but Cloudflare says those synchronization requests do not pass through Gateway. Only real-time user tool calls receive the documented routed inspection.

DLP coverage also has product-specific limits. Cloudflare says its AI prompt profiles do not apply to MCP Portal traffic because those profiles expect different API paths and formats. Administrators must use standard DLP profiles.

Do Not Inspect rules remain effective for Portal traffic. Although Portal routing permits automatic decryption, an explicit exemption prevents payload inspection. A broad exception could therefore remove DLP protection from an approved upstream server.

Identity policies have caveats as well. Cloudflare documents that independent MFA, purpose justification, and temporary authentication are not enforced for servers authorized through a Portal. Email, group, country, and device-posture selectors still apply.

These constraints matter because a Portal can appear more restrictive than its actual policy path. An administrator might assign a server-level requirement and assume users will encounter it during Portal authorization. Cloudflare’s documentation says several step-up controls will not behave that way.

Security teams should also separate protocol detection from semantic security. A request can travel through an approved Portal, match no DLP rule, and still trigger an unsafe action. DLP looks for defined data patterns, not whether deleting a project fits the user’s intent.

Tool injection presents a related problem. An upstream server can return content that influences an agent’s next decision. Network inspection may record or block sensitive strings, but it does not necessarily recognize manipulative instructions embedded in otherwise valid content.

The reverse is also true. A shadow MCP connection is not automatically an incident. A developer might be testing a harmless public data source. The connection remains ungoverned, but its business and security impact requires context.

False positives and false negatives therefore belong in the operating model. Teams should treat hostname and URI matches as leads, then use body signals, user attribution, client data, and server review to reach a decision. High-impact blocking rules should rely on more than a generic path match.

A staged rollout can reduce disruption. Administrators can begin with logging, establish expected Portal traffic, and identify common direct destinations. They can then block high-confidence shadow connections while creating an approval process for new servers.

The strongest version combines network and endpoint controls. Gateway sees remote traffic crossing managed paths. Endpoint management can control which clients and configurations users install. Access and upstream restrictions make bypass harder once an approved route exists.

Cloudflare has provided the pieces for that architecture. It has not eliminated the need to design it.

Three Signals Will Show Whether Cloudflare’s MCP Model Holds

The next test is whether enterprises can convert MCP visibility into consistent routing, meaningful blocking, and measurable tool governance.

The first signal is the share of detected traffic that moves through approved Portal domains. Initial Gateway searches will likely reveal a mixture of known services, experiments, and false positives. The model gains credibility when direct MCP activity falls after approved alternatives become available.

Security teams should measure this as a routing outcome, not only a block count. A rising number of blocked requests might show that policy works, but it can also indicate that users keep trying to bypass the approved route. Successful migration means legitimate activity continues through the Portal.

The second signal is policy quality at the tool and data levels. A Portal that exposes every capability from every approved server centralizes access without applying much restraint. Stronger deployments will curate tools, use identity conditions, and apply DLP profiles to both requests and responses.

Cloudflare’s Gateway can block a tool request when outbound content matches a standard DLP profile. It can also block the response when the upstream server returns matched sensitive data. The MCP client receives an error instead of the protected content.

Those controls become more valuable when organizations tune them for actual workflows. Credentials, financial information, customer identifiers, and proprietary documents carry different risks. A policy that blocks everything will frustrate users, while one that never fires supplies little protection.

Security teams should track blocked tool methods, matched data categories, affected servers, and user outcomes. They should also review whether agents repeatedly retry blocked requests. Repeated attempts might reveal poor client behavior or a workflow that needs a safer approved design.

The third signal is how quickly Cloudflare and the MCP ecosystem close known coverage gaps. Streamable HTTP adoption should reduce the number of upstream servers that cannot use Gateway routing. Better endpoint controls could improve visibility into local and unmanaged configurations.

Protocol changes will matter too. Detection patterns built around current JSON-RPC methods must follow the specification as it evolves. A stable header or other standardized transport signal could make classification easier, but security teams should not assume every client adopts new fields immediately.

Competitor behavior will provide another clue without changing the central contest. Secure web gateway and endpoint vendors will likely add their own MCP classifications, server inventories, or agent controls. That pressure can improve detection methods and expose where network-only approaches fall short.

Cloudflare’s advantage is architectural integration. Its Portal, Access, Gateway, DLP, egress, and application controls can participate in one policy path. Its challenge is proving that customers can configure those components without leaving meaningful bypasses.

The Cloudflare how story is therefore less about a single detector than a feedback loop. Find direct MCP traffic, investigate it, approve the necessary servers, route them through a Portal, and block the unmanaged path. Then repeat as users adopt new tools.

Organizations considering this model should begin with one practical question: which managed network paths and agent clients can their security team actually observe today?

From there, they can inventory MCP signals, compare them with approved Portal traffic, and choose where enforcement has enough confidence. The goal is not to label every MCP connection as dangerous. It is to ensure that agents reach sensitive tools through a route the organization can authenticate, inspect, and audit.