Cloudflare Introduces WriteGuard for MCP Server Control and Auditing

Cloudflare Introduces WriteGuard for MCP Server Control and Auditing Cloudflare has introduced WriteGuard in private beta, providing fine-grained access policies, attribution, and centralized auditing for Model Context Protocol (MCP) servers executing write operations. WriteGuard enforces tool policies and risk tiers directly between MCP clients and servers, intercepting or enriching calls without modifying underlying server code. The system retains human user permissions through Cloudflare Access and OAuth while attaching client and session context to attribute agent actions in downstream applications. Audit logs are scrubbed of sensitive keys and processed asynchronously by a Cloudflare Worker to avoid adding latency to tool calls. Cloudflare created the layer after expanding its internal catalog from 13 read-only MCP servers to 27 servers with increasing demand for write actions. Transitioning Beyond Read-Only Agent Tools As Cloudflare expanded its internal Model Context Protocol infrastructure from 13 read-only servers to 27, teams across engineering, sales, and product sought tools capable of executing actions in downstream systems like Jira and GitLab. Running agents under human credentials via Cloudflare Access prevented privilege escalation, but downstream applications could not differentiate human actions from automated agent sessions. To address risks such as bulk ticket closures or unauthorized table drops without relying on inconsistent client-side prompt controls, Cloudflare developed WriteGuard as a shared control layer. Risk Tiers and Execution Interception Configured at the tool level, WriteGuard evaluates requests using risk tiers, enabled statuses, and labeling requirements. In practice, read-only tools are passed through unchanged, contained writes are enriched with formatted agent attribution and audited, and critical tools—such as deployment-triggering repository merges—can be disabled to block execution before their handlers run. This shared policy architecture applies consistent enforcement across tools from various applications without requiring custom guardrails in each individual MCP server. Asynchronous Auditing and Portal Rollout WriteGuard records every tool invocation outcome as successful, failed, or blocked, generating a scrubbed event that captures the server, tool, risk tier, user, client, and duration while omitting sensitive data. By logging events asynchronously via an internal audit Worker, the platform maintains centralized observability without increasing agent response latency. Initially configured via TypeScript in an internal repository, these capabilities are entering private beta through Cloudflare MCP server portals ahead of general availability.

Cloudflare推出WriteGuard：为MCP服务器提供细粒度写入控制与归属审计 为了防止AI Agent在执行写操作时出现意外破坏，Cloudflare构建了共享策略层WriteGuard，并将其引入Cloudflare MCP server portals开启私密测试，以实现细粒度的工具控制、Agent归属标记与全局审计。 WriteGuard为MCP服务器工具提供风险分级（如READ_ONLY、CONTAINED_WRITE、CRITICAL）与启用/禁用控制，可在代码执行前拦截请求。 保留以人类员工凭证为基础的权限体系，同时注入客户端与会话上下文，使下游应用可区分人工与特定Agent操作。 通过异步审计机制将脱敏事件发送至内部Worker，在不增加调用延迟的前提下实现全平台Agent活动的集中追踪。 目前WriteGuard通过Cloudflare MCP server portals进入私密测试，未来将逐步推广至正式可用。 背景：Agent写操作带来的失控风险 随着内部AI应用从搜索工单或文档等只读操作扩展到能够执行修改的场景，依赖客户端提示词来约束Agent往往不够可靠且易被绕过。当Agent在后台批量关闭工单或误删数据时，若系统仅记录发起人账号而缺乏会话标识，将难以追溯具体故障源头并区分人工与Agent行为。为此，Cloudflare需要一套集中式的控制方案。 WriteGuard的核心架构与功能 WriteGuard作为一个独立的策略、归属与审计层，无需修改底层MCP服务器代码即可为每个工具定义风险层级、开关状态与标记格式。在权限管理上，系统沿用Cloudflare Access和OAuth的人类身份，避免设立独立Agent账号造成的权限碎片化；同时补充MCP客户端与会话上下文，将归属信息直接写入下游应用支持的文本字段中。 执行流程与审计机制 在实际运行中，只读操作会被直接放行，低风险写入会被注入归属信息并记录，而高风险操作（例如未经允许的代码合并）则会在处理程序运行前被直接拦截。此外，WriteGuard异步记录去除敏感信息的审计事件，涵盖工具、结果、用户和持续时间等维度，确保在不增加Agent请求延迟的同时，提供全局可查询的活动日志。

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](https://www.theguardian.com/technology/2026/apr/29/claude-ai-deletes-firm-database), 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](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/) through a private beta. Before explaining WriteGuard, let’s review what an MCP server is and how it works with AI agents. MCP stands for [Model Context Protocol](https://modelcontextprotocol.io/), 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. MCP is a critical piece of the infrastructure powering Cloudflare's internal agents. Those agents use MCP through local clients such as [OpenCode](https://opencode.ai/) and [Cloudflare OS](http://blog.cloudflare.com/cloudflare-os), as well as through long-running agentic services. We run the servers behind [Cloudflare Access](https://developers.cloudflare.com/cloudflare-one/access-controls/) and connect to them through a single internal [MCP server portal](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/). When we described [our internal AI engineering stack](https://blog.cloudflare.com/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. 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. 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. 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. Our internal MCP servers use [Cloudflare Access and OAuth](https://blog.cloudflare.com/managed-oauth-for-access/) 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 respond. Visible labels explain individual actions and provide helpful context in the downstream application, but they don’t provide a fleet-wide view. Because an agent can repeat an action much faster than a person, we also needed central auditing across every MCP server. WriteGuard classifies each invocation as successful, failed, or blocked, then asynchronously sends a scrubbed event to an internal audit Worker. The event omits values for keys considered secret or sensitive. It includes the server, tool, risk tier, outcome, user, client, and duration. This makes agentic activity queryable across all of our MCP-enabled systems. The dashboard complements the request logs provided by [MCP server portals](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/). Portal logs show tool invocations, while WriteGuard adds semantic tool classifications, agent context, and outcomes from the backing servers. We made audit logging asynchronous, so it adds no latency to the response the agent is waiting for. Earlier in this post, we mentioned three tools from our GitLab MCP server: get\_merge\_request, create\_mr\_note, and merge\_mr. Let’s follow each one through WriteGuard. Suppose an engineer asks an agent to summarize a proposed code change and the agent calls the `get_merge_request` tool. WriteGuard classifies the tool as `READ_ONLY` and WriteGuard allows the call to pass through unchanged. Now the engineer asks the agent to leave comments on a merge request (MR), and the agent calls the `create_mr_note` tool. The tool is classified as CONTAINED\_WRITE. WriteGuard adds agent attribution to the configured note field using a format GitLab supports, then invokes the tool handler. It also asynchronously records a scrubbed audit event containing the user, tool, outcome, and agent identity context. Suppose an engineer asks an agent to help review a merge request. Trying to be helpful, the agent goes beyond the request and calls the merge\_mr tool without being asked. Because merges at Cloudflare typically trigger deployment pipelines, we require a human in the loop. We therefore classify the merge\_mr tool as CRITICAL risk tier and configure the tool disabled in WriteGuard. If called, WriteGuard will block the request before its handler runs and record the attempt. These tools use the same server, identity flow, and downstream API, but WriteGuard handles each one differently before its code runs. 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. Instead, we built WriteGuard as a shared layer that needs only per-tool configuration and works across every MCP server connected through the portal. We built WriteGuard for Cloudflare's own MCP servers because we needed to move beyond read-only tools without losing control of the writes that followed. The [private beta](https://www.cloudflare.com/resource/writeguard-beta-landing-page/) brings that architecture to MCP server portals, providing a way to classify write tools, block tools before execution, add agent attribution, and inspect write activity across connected servers. The beta will start small and expand over time, leading up to general availability. We want to validate how the risk model maps to customer tools, which downstream applications need attribution formats, and what audit delivery guarantees customers require before making WriteGuard broadly available. If your organization is adding write tools to MCP servers and wants to test these controls with us, [sign up for the WriteGuard private beta](https://www.cloudflare.com/resource/writeguard-beta-landing-page/).