The Agent Did It: Making Machine-Speed Writes Auditable
Consider a scenario that starts innocently enough. A batch of support tickets begins closing at noon. It's attributed to an engineer having a productive afternoon. By 4 p.m., thousands of tickets are closed, all under that same engineer's name. The twist? The engineer was good, but not that good. The culprit was a background cleanup agent with a prompt that was slightly too broad, running across concurrent sessions and making changes at machine speed.
This case is low-stakes compared to what is possible when an agent with broad access touches contract software, customer support queues, or a production database. The core problem is that downstream systems record actions under a human identity, regardless of whether the change was made directly or by an agent acting on their behalf. From the outside, the two are indistinguishable.
At Cloudflare, the solution couldn't rely on every employee configuring every agent flawlessly. That is why, before broadly enabling write access on internal MCP servers, they built WriteGuard, a shared policy, attribution, and auditing layer. It is now entering a private beta for Cloudflare MCP server portals.
MCP and the Shift to Writes
The Model Context Protocol (MCP) is a standard for connecting AI applications to external tools and data. An MCP server exposes tools, each with a name, description, input schema, and handler. When an agent decides to use a tool, the client sends the call to the server, which interacts with the downstream application.
Internally, Cloudflare's agents connect to MCP servers through a single portal protected by Cloudflare Access. The number of servers has grown from 13 to 27 in recent months. Initially, all were read-only, allowing searches across systems like Jira, GitLab, and internal wikis. As teams across the company gained experience, demand grew for agents that could take action.
Relying on client-side controls like prompts was not viable; they vary by harness and can be disabled. Cloudflare needed centralized control over write actions, clear attribution in downstream applications, and a queryable audit trail. This led to the development of WriteGuard.
Centralized Policy, Server-Side Enforcement
WriteGuard operates as a layer between the MCP client and the server. It uses tool-specific configuration and request context to decide what happens. There are three possible outcomes: allow the call to pass through unchanged, enrich it with attribution before allowing it, or block it entirely before the tool’s handler executes.
This policy is defined per tool without requiring code changes to the underlying MCP server. Each tool receives a risk tier (READ_ONLY, CONTAINED_WRITE, CRITICAL), an enabled or disabled state, and a labeling configuration. The risk tier determines if an action is logged and if it is permitted at all. The labeling configuration defines what attribution to add and in what text format, which must vary depending on the downstream application.
Currently, this is configured in TypeScript in an internal monorepo. The private beta will allow server owners to manage these policies through the MCP server portals.
Keep the Human, Attribute the Agent
Internal MCP servers use Cloudflare Access and OAuth to identify the user. Agents operate with that employee’s permissions. If an engineer cannot perform an action, their agent cannot either. Cloudflare intentionally avoided standalone agent accounts, which would create a parallel permission system and obscure responsibility.
The tradeoff is that downstream apps only see the human's credentials. WriteGuard solves this by adding MCP client and session context, tagging writes as coming from an agent session on behalf of a specific person. This attribution is valuable even in normal operations, helping other humans and agents understand why a change occurred.
Queryable Audit Trail
Labels help explain individual actions, but agent speed requires a fleet-wide view. WriteGuard classifies every tool invocation as successful, failed, or blocked, and asynchronously sends scrubbed events to a central audit Worker. The events exclude values for secret or sensitive keys, but include the server, tool, risk tier, outcome, user, client, and duration. This makes all agent activity across MCP systems queryable in one dashboard.
While portal request logs show raw tool invocations, WriteGuard adds semantic classification, agent context, and outcome. Since logging is asynchronous, it adds no latency to the agent’s request.
Example: Governance on a GitLab Server
To illustrate how the risk tiers work in practice, take three tools on a GitLab MCP server: get_merge_request, create_mr_note, and merge_mr.
Read-Only Access
An agent calling get_merge_request to summarize code changes hits a tool classified as READ_ONLY. WriteGuard allows the call to pass through unchanged.
Contained Writes
When an agent is asked to leave comments on a merge request, it calls create_mr_note. Classified as CONTAINED_WRITE, WriteGuard adds agent attribution to the note field using GitLab's supported format, then invokes the handler. An audit event is logged. This describes the enrichment of a write request with attribution context.
Critical Actions
If an agent goes rogue and attempts to merge code without being asked, it calls merge_mr. Because merges can trigger deployment pipelines, this is classified as CRITICAL and the tool is disabled by default. WriteGuard blocks the request before the handler runs and records the attempt.
A Shared Layer for All Servers
These three tools share a server and identity flow, yet WriteGuard handles each differently. While these controls could be built directly into a single GitLab server, the same requirements applied to Jira, wikis, Google Workspace, and every new server added. Duplicating that work would be inefficient and lead to inconsistency. As a shared layer, WriteGuard requires only per-tool configuration and applies uniformly across every system connected through the portal.
Private Beta Rollout
The private beta brings this architecture to external customers using MCP server portals. The beta starts small and expands, with Cloudflare validating how the risk model maps to external tools, what attribution formats downstream apps need, and what audit delivery guarantees are required. The focus is on organizations that are adding write tools to MCP servers and need a way to classify, block, attribute, and inspect those actions.
