Cloudflare wants to make shadow MCP visible

On 22 August a piece of news landed that reads like plumbing at first glance: Cloudflare has added to its Gateway the ability to see and block Model Context Protocol traffic that nobody authorized. Read slowly, it is the moment when MCP stops being a thing for curious developers and becomes a traffic category a security team has to inventory, the same way Dropbox or browser extensions once did.

The original piece is published on forkast.news under the headline «Cloudflare Gateway Makes Shadow MCP Visible and Blockable». Cloudflare did not coin the term shadow MCP, but this is the first time we have seen it turned into a product feature inside a general purpose network provider.

What shadow MCP actually is

MCP is Anthropic's standard for letting a model call external tools. An MCP server connects in one of two ways: as a local process over stdio, or as a remote server over HTTP with its own authorization flow. In Claude Desktop the configuration lives in claude_desktop_config.json, inside the user's laptop. In Claude Code it is added with a command and a scope decision. Neither path goes through an IT ticket.

The outcome is predictable. A developer connects their Claude to Jira, Drive, an S3 bucket or a database replica in five minutes, and the organization has no record of it. The difference with classic shadow IT matters: an unauthorized SaaS read data, whereas an MCP server executes actions with the credentials of whoever installed it, driven by instructions that a third party text can end up dictating. That is where prompt injection and tool description poisoning come in, because the model trusts whatever the tool claims to be.

What a gateway solves and what it does not

Gateway is Cloudflare's secure web gateway: it sits on the egress path of corporate traffic and applies policy before the request reaches its destination. The fact that it can identify MCP endpoints and allow or deny them by rule means two practical things. There is inventory, meaning which servers are in use and from which machines. And there is leverage, because you can cut one specific server without cutting the whole team's internet access.

It is worth not overselling the scope. A gateway sees network traffic, so what it captures well are remote MCP servers. A local stdio server that only touches the laptop's filesystem generates no traffic a gateway can read, and that is precisely the profile most often installed by hand. Full visibility still needs something on the endpoint, not only on the network.

Who this is useful for today

IT and security teams at companies where twenty or more people already use Claude Code or Claude Desktop daily. If you are in that group, the useful exercise is not buying anything yet, but writing the list: which MCP servers run on each machine, with which tokens and against which systems. That list is almost always longer than the CTO expected.

It also matters to anyone building MCP servers for third parties, which is our case. If corporate gateways start filtering by domain, a server published on a stable domain, with documented OAuth scopes and no odd ports, is a server that passes review. One that ships over an ephemeral tunnel created during development is not.

We see this as an expected move, arriving with a reasonable lag behind real MCP adoption. What it does not fix, and this is worth saying, is the underlying problem: control over what a tool can do once connected still lives in the server design and the token scope, not in the network layer.