Cloudflare Brings WriteGuard MCP Server Controls Out of Internal Rollout Into Private Beta
Cloudflare opens a private beta of WriteGuard, a policy and audit layer that classifies and can block risky write actions AI agents take through MCP servers.
Editor's Note ·
- Clarification:
- This article stated that "Cloudflare's blog post opens with an internal incident that motivated the project," describing an engineer whose background agents closed thousands of tickets. Cloudflare's blog post introduces this same story with "Let's imagine the Case of the Endlessly Closing Tickets" and later calls it "relatively low-stakes" in contrast to scenarios readers "can all imagine, or read about" - explicitly framing it as an illustrative hypothetical rather than a confirmed, dated internal incident. The article should not have presented it as a verified real event.
Overview
Cloudflare has opened a private beta of WriteGuard, a security layer for MCP (Model Context Protocol) servers that classifies the actions AI agents try to take and can block the riskiest ones before they execute, according to a Cloudflare engineering blog post by engineers Scott Roe-Meschke and Kenny Johnson. The company built the tool for its own internal MCP servers and is now extending it to customers connecting through Cloudflare’s MCP server portals, as reported by InfoQ.
What We Know
MCP is, in Cloudflare’s own description, “a popular standard for connecting AI applications to external tools and data sources,” and MCP servers expose tools that connected AI clients can call to interact with downstream applications, according to Cloudflare. Cloudflare’s internal AI engineering stack has grown quickly: the company’s internal MCP server portal connected 13 MCP servers in April and connects 27 today, according to the same post. Those servers started out read-only, letting employees search tools like Jira, GitLab, and the company’s internal wiki without changing anything — but as AI models improved, people across engineering, product, design, sales, and customer success began asking for tools that could take action, not just read data.
Cloudflare’s blog post opens with an internal incident that motivated the project: background agents running across multiple concurrent sessions closed thousands of tickets under one engineer’s account in a single afternoon, triggered by “a cleanup task with a prompt that was a little too broad.” Because the ticketing system recorded all the closures under the employee’s name, it took the team time to determine which changes were made by a person and which by an agent. “we knew we could not depend on every employee to configure every agent perfectly or watch every tool call,” the company wrote, saying it built WriteGuard before expanding write access across its own internal MCP servers and is now bringing those controls to customers through the private beta.
WriteGuard is described in the post as “a shared policy, attribution, and auditing layer” that sits behind Cloudflare’s MCP server portal and evaluates each incoming tool call against configuration set for that specific tool. Depending on the policy, WriteGuard can pass a call through unchanged, enrich a write action with agent-attribution labeling and log a scrubbed audit event, or block the action entirely before its handler runs, according to Cloudflare. Every tool is assigned one of four risk tiers, InfoQ reported: read-only actions such as searching issues or viewing pipeline status carry no risk; “minimal impact” covers things like marking a notification as read or adding a reaction; “contained write” covers actions such as creating a merge request or updating an issue field; and “critical” covers operations like completing a merge request, triggering a production deployment, or bulk-deleting records.
Cloudflare’s post walks through its own GitLab MCP server as an example. When an agent calls the read-only get_merge_request tool to summarize a proposed code change, WriteGuard classifies it as read-only and lets the call pass through unchanged. When an agent calls create_mr_note to leave a comment on a merge request, WriteGuard classifies it as a contained write, adds agent-attribution text in a format GitLab supports, and logs a scrubbed audit event. Cloudflare classifies its merge_mr tool — which can trigger deployment pipelines — as critical risk and has it configured as disabled by default in WriteGuard, “because merges at Cloudflare typically trigger deployment pipelines, we require a human in the loop,” the company wrote; if an agent calls it anyway, WriteGuard blocks the request before the handler runs and records the attempt.
On identity, Cloudflare said it deliberately avoided creating standalone accounts for agents. Internal MCP servers authenticate through Cloudflare Access and OAuth, so an agent acting on an employee’s behalf inherits that employee’s permissions rather than getting its own credentials — “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 company wrote. WriteGuard instead adds MCP client and session context on top of the human identity, so a downstream write can be traced to a specific agent session acting on behalf of a specific person. For auditing, WriteGuard asynchronously sends a scrubbed event — omitting values considered secret or sensitive — to an internal audit worker for every invocation, classifying it as successful, failed, or blocked and recording the server, tool, risk tier, outcome, user, client, and duration, according to Cloudflare. The company said it built the audit logging asynchronously specifically so it adds no latency to the response an agent is waiting for.
Cloudflare said it chose to build WriteGuard as a shared layer rather than wiring equivalent controls into each MCP server individually: “For GitLab alone, we could have built these controls directly into the server. But we needed the same capabilities for Jira, our internal wiki, Google Workspace, and every new MCP server we added. Reimplementing them in each server would take more work and produce inconsistent behavior.”
What We Don’t Know
Cloudflare did not give a timeline for general availability, saying only that “the beta will start small and expand over time, leading up to general availability” while it validates how the risk model maps to customer tools, which downstream applications need which attribution formats, and what audit-delivery guarantees customers will require. Pricing for the eventual general-availability product was not disclosed, and Cloudflare did not name any beta customers.
Analysis
WriteGuard is a narrow but pointed response to a problem that has come up repeatedly as coding and workflow agents gain write access to real systems: the gap between an agent acting under a human’s credentials and a system’s ability to tell the two apart after the fact. Cloudflare’s framing — building the guardrail internally first, then packaging it for MCP server portal customers — mirrors a pattern in the space generally, where vendors are increasingly shipping policy and audit layers as a prerequisite for letting agents move from read-only tools to ones that can merge code, close tickets, or trigger deployments unsupervised.