WriteGuard: Fine-grained controls for MCP Servers (opens in new tab)
Cloudflare built WriteGuard to safely expand AI agents’ write access to internal MCP servers. The system centralizes authorization, risk classification, agent attribution, and auditing, addressing failures that client-side prompts or individual user vigilance cannot reliably prevent. It preserves the human user’s permissions while making each agent session identifiable and its actions queryable.
The Risk of Uncontrolled Agent Actions
- A broadly instructed cleanup agent accidentally closed thousands of tickets.
- Human and agent actions were recorded under the same employee identity, making the incident difficult to investigate and repair.
- Network logs could not distinguish between multiple agent sessions.
- More serious failures could involve:
- Amending contracts
- Sending mass customer replies
- Deleting database tables
- Triggering destructive production actions
MCP Fundamentals
- The Model Context Protocol connects AI applications to external tools and data.
- An MCP server exposes tools with:
- A name
- A description
- An input schema
- A handler that performs the operation
- When an agent selects a tool, the MCP client sends the call to the server, which interacts with the downstream application.
Cloudflare’s MCP Expansion
- Cloudflare uses MCP with local clients such as OpenCode and Cloudflare OS, as well as long-running agent services.
- Its internal MCP portal grew from 13 servers to 27.
- Servers initially provided read-only access to systems such as Jira, GitLab, internal documentation, and operational tools.
- As agents became more capable, teams requested write actions across engineering, product, design, sales, and customer success.
- Cloudflare decided centralized controls were necessary because client-side skills and elicitation prompts vary across agent harnesses and can be disabled.
WriteGuard’s Policy and Attribution Layer
- WriteGuard evaluates tool configuration together with request context.
- It can:
- Pass a call through unchanged
- Add agent attribution to supported writes
- Create a scrubbed audit event
- Block a call before the tool handler executes
- Policies are defined per tool and include:
- Risk tier
- Enabled or disabled status
- Labeling configuration
- Risk tiers include:
- Read Only: Search issues or inspect merge requests
- Minimal Impact: Add reactions or mark notifications read
- Contained Write: Add comments, create merge requests, or update issue fields
- Critical: Merge code, deploy to production, or bulk-delete records
- Labeling allows agent context to be inserted into downstream applications in formats such as plain text or HTML without modifying the MCP server.
Preserving Human Permissions While Identifying Agents
- Agents operate through the employee’s Cloudflare Access and OAuth identity.
- An agent cannot perform an action its user is not authorized to perform.
- Cloudflare avoided standalone agent accounts because they would create additional permissions to manage and weaken accountability.
- WriteGuard supplements the human identity with MCP client and session information.
- Each write can therefore be tied to both the responsible person and the specific agent session.
Centralized, Queryable Auditing
- WriteGuard classifies every invocation as successful, failed, or blocked.
- It asynchronously sends scrubbed events to an internal audit Worker.
- Audit records include:
- MCP server and tool
- Risk tier
- Outcome
- User and client
- Request duration
- Secret and sensitive input values are omitted.
- Asynchronous logging avoids adding latency to the agent’s response.
- MCP portal logs show raw tool invocations, while WriteGuard adds semantic classifications, agent context, and backing-service outcomes.
- Central auditing makes unusually fast or widespread agent activity easier to detect and investigate.
Recommendation
Organizations expanding MCP agents beyond read-only access should use centralized, server-side policy enforcement, preserve human authorization boundaries, attach per-session agent attribution, and maintain scrubbed audit logs. Relying solely on prompts, client configuration, or undifferentiated user identities makes destructive automation difficult to prevent and even harder to understand afterward.