Cloudflare WriteGuard puts a policy in front of agent writes

Most teams govern their AI agents in the system prompt. "Do not delete anything. Ask before you deploy." That is not a control. It is a request. Cloudflare shipped WriteGuard into private beta on August 18 — a policy, attribution, and audit layer that sits in front of MCP servers and decides what an agent's write calls are allowed to do, before the tool handler runs. This is the right shape for MCP security, and you can copy it whether or not you buy it.

What actually happened

WriteGuard sits behind Cloudflare's MCP server portal and intercepts every incoming MCP request. It loads the policy for the targeted tool, evaluates the request context, and takes one of three actions: pass the call through unchanged, execute the write but enrich it with agent attribution and emit a scrubbed audit event, or block it before the handler runs.

Tools are sorted into risk tiers. Read-only is informational. Minimal impact covers things like marking a notification read or adding a comment. Contained write covers creating a merge request or updating an issue field. Critical covers completing a merge, triggering a production deployment, or bulk-deleting records. The tiering is per-tool and lives in the proxy — the MCP server itself does not change.

Two design decisions matter more than the feature list. First, there are no standalone agent accounts: the agent runs under the human user's existing OAuth/Access identity, with MCP client and session context attached for traceability. Second, the audit event captures server, tool, risk tier, outcome, user, client, and duration. Cloudflare's own internal deployment now fronts 27 MCP servers, up from 13 in April. They built it because writing the controls into GitLab's server would not have covered Jira, the wiki, Google Workspace, and every server added next month.

Why MCP write policy matters for your business

Read access is a data question. Write access is a liability question. An agent that reads your CRM can leak. An agent with a write-scoped token to your contract tool can amend an agreement, and an agent with a database MCP can drop a table. Client-side controls — the prompt, the tool description, the model's judgment — do not survive an injected instruction in a document the agent just read.

Policy in the proxy is the only place it composes. You will not have one MCP server. You will have your helpdesk, your billing system, your repo host, your inventory tool. Building approval logic into each one is N implementations that drift. One intercepting layer with per-tool tiers is one implementation.

Attribution is what makes the audit trail usable. A commit or a ticket update with no agent label looks like a human did it. Six weeks later, when you are reconstructing who changed a price, "user: dana" is a dead end if dana's Claude Code session made the call. Label the write at the boundary, not in the app.

You can build the 80% version today. Put your MCP servers behind a proxy you control. Classify every tool your agents can reach into read / reversible / irreversible. Auto-allow reads, log reversible writes, require a human on irreversible ones. Log the tool name, the arguments, the caller, and the outcome to somewhere you can query. That is a week of work and it is the difference between an incident and an incident report.

Sources: Cloudflare Blog: WriteGuard — Fine-grained controls for MCP Servers, InfoQ: Cloudflare WriteGuard Brings Fine-Grained Security Controls for MCP Servers.