WriteGuard: fine-grained controls for MCP Servers

WriteGuard: Fine-grained controls for MCP Servers | The Cloudflare Blog

Skip to content

Let’s imagine the Case of the Endlessly Closing Tickets. The bug tickets start closing at noon. Nobody thinks much of it. Joe moved a few tickets to Done, and Joe is having a productive afternoon. Then the pace picks up. By 4 p.m., thousands of tickets have been closed, all by Joe. Joe is a good engineer. Joe is not a thousand-tickets-an-hour engineer. We learn that he has several background agents running across three concurrent sessions. It takes half an hour to find the one at fault: a cleanup task with a prompt that was a little too broad. Once we’ve stopped the agent, we need to repair the state of the ticketing system. Joe has also been legitimately closing tickets by hand that afternoon. The system records all those changes under Joe regardless of whether it was him or his agent, and the network logs do not distinguish one agent session from another. From the outside, the actions look identical. The example above is relatively low-stakes, but we can all imagine, or read about , much more destructive cases. An agent with access to contract software could amend an agreement. An agent wreaking havoc in a support queue could send hundreds of replies to customers. An agent with database access could drop entire tables. At Cloudflare, we knew we could not depend on every employee to configure every agent perfectly or watch every tool call. So before expanding write access across our own internal MCP servers, we built WriteGuard. We are now bringing those controls to Cloudflare MCP server portals through a private beta. MCP Fundamentals Before explaining WriteGuard, let’s review what an MCP server is and how it works with AI agents. MCP stands for Model Context Protocol , a popular standard for connecting AI applications to external tools and data sources. MCP servers provide tools that connected clients can use. Each tool has a name, a description, an input schema, and a handler that performs the work. When an agent selects a tool, the MCP client sends the tool call to the server, which then interacts with the downstream application. MCPs at Cloudflare MCP is a critical piece of the infrastructure powering Cloudflare's internal agents. Those agents use MCP through local clients such as OpenCode and Cloudflare OS , as well as through long-running agentic services. We run the servers behind Cloudflare Access and connect to them through a single internal MCP server portal . When we described our internal AI engineering stack in April, our portal connected 13 MCP servers. Today, it connects 27, with teams shipping more servers every month. They all began as read-only servers, allowing teams to search Jira, GitLab, our wiki, and operational systems without changing them. Read-only was a good starting point. As models improved and teams gained experience with AI, people across engineering, product, design, sales, and customer success began asking for tools that could take action. To avoid our own case of the endlessly closing tickets, we wanted centralized control over the write actions agents could perform, agent labels to appear in downstream applications, and an audit trail that made agent activity easy to investigate. We could not count on client-side controls such as skills or elicitation prompts. Their behavior varies by harness, and users can disable them. So we built WriteGuard. Introducing WriteGuard WriteGuard is a shared policy, attribution, and auditing layer. It uses each tool’s configuration and the request context to determine what happens. WriteGuard can pass a call through unchanged, enrich supported writes with agent attribution and produce a scrubbed audit event, or block an action before its handler runs. The diagram below shows where WriteGuard sits in our current internal MCP architecture.

WriteGuard combines tool policy with human and agent identity, downstream attribution, and centralized auditing. It gives us one place to control agent actions and preserve the context needed to understand them. Beyond callable tools to governable actions WriteGuard lets us define policy alongside each tool without changing the underlying MCP server. Every tool gets a risk tier, an enabled or disabled state, and a labeling configuration. Risk tiers determine whether the action is logged and whether the tool call is permitted, and the tiers allow for querying the audit log by risk. We support labeling so that we can insert agent attribution labeling and use the best text format for the downstream application, without any code changes needed in the MCP server itself. Risk Tier Examples

Read Only Search issues; read a Merge Request (MR); view pipeline status get_merge_request

Minimal Impact Add a reaction; mark a notification as read; subscribe to an issue

Contained Write Add a comment; create an MR; update an issue field create_mr_note

Critical Merge an MR; trigger a production deployment; bulk-delete records merge_mr

const sendEmailTool = { tool: EmailMCP.sendEmailTool, writeGuard: { riskLevel: RiskLevel. CONTAINED_WRITE , enabled: true , labeling: { field: "body" , supportedFormats: [ LabelFormat. PLAIN_TEXT , LabelFormat. HTML , ], }, }, }; Today, we define this configuration in TypeScript in our internal MCP monorepo. As private beta access rolls out in the coming months, server owners will be able to configure the same policies through Cloudflare MCP server portals. Every MCP server will have a baseline Access policy along with WriteGuard controls for individual tools. Keep the person, add the agent Our internal MCP servers use Cloudflare Access and OAuth to identify the user. Agents using those servers therefore operate with that employee’s permissions. If Joe cannot close a particular issue, Joe’s agent cannot close it either. We kept that model instead of introducing standalone agent accounts. Agent accounts would create a second set of permissions to manage and make the connection to the person responsible for the agent less clear. The tradeoff with that decision, however, is that downstream applications see Joe’s credentials but nothing identifying the agent behind the action. WriteGuard adds MCP client and session context to the human identity, identifying each write as an agent session acting on behalf of a particular person. Notably, that attribution is extremely useful even when nothing goes wrong. It helps humans and other agents interpret changes and decide how to...