MCP Governance Is Table Stakes. What Comes Next?

Cloudflare published a clear-eyed post last week on enterprise MCP. Discovery, shadow MCP, authorisation sprawl, compliance gaps — they’re right about the problem, and their answer covers a real surface. Centralised registry, portal-based discovery, authenticated access, sensible defaults. If you’re an enterprise standing up MCP, you want this.

It also makes one thing clear: MCP governance is becoming table stakes. A year from now, every enterprise will assume their MCP stack includes discovery, SSO, shadow-MCP prevention, and audit logs. The interesting question sits one layer higher.

What MCP governance covers

The Cloudflare pitch is access and discovery. Who can see which MCP servers, who can connect to them, how to keep employees off unapproved ones. These are identity and routing problems, and they’re solved with identity and routing tools: SSO, portals, reverse proxies, audit logs. Cloudflare already has those tools, which is why this was a natural product for them to ship.

At this layer, the primitive is the MCP server. The enforcement surface is the connection. The question being answered is: is this agent allowed to reach this server?

The tool-call gap

That question is the right one for access control. It’s the wrong one for most of what CISOs actually worry about.

An agent with authorised access to the Stripe MCP can refund ten pounds or ten thousand. An agent with authorised access to the Linear MCP can add a comment or delete a project. An agent with authorised access to the Gmail MCP can reply to a colleague or forward the inbox to an external address. Server-level auth can’t tell these apart — its primitive is access, not behaviour.

“This agent may reach the Stripe MCP” is not a meaningful policy. It’s a binary on a capability surface that contains both benign and dangerous calls. Once the binary is flipped to yes, everything on that surface is in scope.

This isn’t a theoretical gap. Agents compose tool calls. An agent authorised to “read customer data” and “send emails” becomes, at runtime, an agent that can exfiltrate your customer list. No server-level policy catches that. The combination is the threat, and the combination is expressed only in tool calls.

What runtime enforcement looks like

Move down a layer. Treat the tool call as the unit of governance, not the server.

Policy becomes concrete:

• allow refund_payment where amount <= 100
• deny delete_project
• rate_limit send_email to 10/hour per agent

Enforced deterministically, before the call reaches the upstream — not observed afterwards and flagged in a dashboard. The proxy inspects arguments, evaluates rules, and either forwards or blocks. Every decision is auditable because every decision is made in the same place, at the same layer, with the same primitive.

This is the problem PolicyLayer is built around. A policy document format, a validator, a per-request evaluator, rate-limit state, and a way to propagate policy changes to a live proxy without dropping sessions. It’s a harder engineering problem than server-level auth. It is also the problem that produces the controls enterprises are already asking for.

Two layers, same stack

Access control and behaviour control are different primitives, and both matter. Cloudflare has built the first well. The second needs its own product, its own vocabulary, and its own enforcement surface.

PolicyLayer is the control plane for AI agent tool use. It proxies MCP traffic, enforcing policy on every tool call before execution.

Once your agents have authorised access to the MCPs they need, the next question is what they’re allowed to do with them. MCPs are the plumbing. Tool calls are the object of governance. Policies are the new layer security teams will demand as agents move from pilots to production.

Cloudflare has solved the entrance. The inside of the building is the next problem.