Cloudflare WriteGuard Adds Four-Tier Policy Layer for MCP Servers
In this article
Cloudflare has launched WriteGuard in private beta, a shared policy, attribution, and auditing layer purpose-built for MCP (Model Context Protocol) servers. WriteGuard intercepts tool invocations before they reach an MCP server, evaluates each request against a per-tool policy, and blocks or passes calls without requiring any modification to the server itself. The timing is relevant: write-access tool calls are now a standard ask across engineering, product, design, sales, and customer success, and the blast radius of an unchecked agent action — bulk-deleting records, triggering a production deployment — has no clean mitigation inside existing MCP implementations.
The problem is structural. As covered in our analysis of four agent control layers with no shared contract, the MCP ecosystem lacks a standardised enforcement boundary between an agent's intent and the downstream effect of a tool call. WriteGuard inserts that boundary at the network layer, where it can be applied consistently across every MCP server connected through the Cloudflare portal rather than reimplemented per integration.
How WriteGuard Works
WriteGuard sits immediately behind Cloudflare's MCP server portal. When an agent issues a tool call, WriteGuard loads the policy associated with that specific tool and evaluates the full request context before deciding whether to pass or block. Requests that are denied go directly to the audit log; requests that are allowed but subsequently fail are also routed there. Each audit event is scrubbed of secret and sensitive key values before being sent asynchronously to an internal audit Worker, and records the server, tool, risk tier, outcome, user, client, and duration.
Identity handling avoids a common pitfall: WriteGuard does not create standalone agent accounts, which would introduce a parallel permission set to manage. MCP servers continue using existing OAuth credentials to identify the human user, and WriteGuard appends MCP client and session context to that identity so agent-driven actions remain distinguishable in the audit trail from human-initiated ones.
Risk Tier Classification
The core policy primitive is a four-level risk tier assigned to each tool, determining how WriteGuard evaluates an invocation and what lands in the audit record.
| Risk Tier | Example Operations |
|---|---|
| Read-only | Any operation that only fetches or reads data; no risk assigned |
| Minimal impact | Marking a notification as read, subscribing to an issue, adding a comment |
| Contained write | Creating a merge request, updating an issue field |
| Critical | Completing a merge request, triggering a production deployment, bulk-deleting records |
Each invocation outcome is classified as successful, failed, or blocked, and that classification is part of every audit event. Policies are defined per tool and evaluated at request time, so a single WriteGuard deployment can enforce different thresholds across GitHub, Jira, Google Workspace, internal wikis, and any new MCP server added later — without rewriting control logic into each individual server.
Cloudflare engineers Scott Roe-Meschke and Kenny Johnson cited the multi-server scaling problem as the design driver directly: building equivalent controls into a GitLab MCP server is tractable, but replicating them consistently across every subsequent integration is not. Their framing — "Reimplementing them in each server would take more work and produce inconsistent behavior" — is precisely what WriteGuard's shared-layer model is designed to avoid.
Availability
WriteGuard is in private beta while Cloudflare validates its behaviour and refines the product before general availability. No GA date has been announced. The risk tier taxonomy and policy schema should be treated as subject to change based on early-adopter feedback, which matters for any team considering building internal tooling on the current API surface.
The security risks that agent hijacking creates are already being exploited in production environments, which raises the stakes for getting the policy model right before WriteGuard reaches GA. A misclassified risk tier or a gap in auditing coverage could give teams a false sense of enforcement where none exists.
WriteGuard represents an architectural bet that MCP security controls belong in a shared infrastructure layer rather than inside individual server implementations. If the model holds, it pushes tool-call governance into the same category as authentication and rate limiting — infrastructure concerns developers shouldn't solve from scratch per integration. Whether Cloudflare can make the policy model expressive enough to cover the full range of MCP tool semantics while keeping it simple enough to configure correctly will determine whether WriteGuard becomes standard infrastructure for production agent deployments.