{"slug": "writeguard-fine-grained-controls-for-mcp-servers", "title": "WriteGuard: fine-grained controls for MCP Servers", "summary": "Cloudflare introduced WriteGuard, a policy engine providing fine-grained controls for Model Context Protocol (MCP) servers, now in private beta for Cloudflare MCP server portals. The tool addresses risks from AI agents performing unintended write actions, such as closing thousands of tickets, by centralizing write permissions, adding agent labels, and creating audit trails. Cloudflare's internal MCP server count grew from 13 in April to 27 today, all initially read-only.", "body_md": "# WriteGuard: fine-grained controls for MCP Servers\n\nLet’s imagine the Case of the Endlessly Closing Tickets.\n\nThe 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.\n\nJoe is a good engineer. Joe is not a thousand-tickets-an-hour engineer.\n\nWe 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.\n\nOnce 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.\n\nThe 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.\n\nAt 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.\n\n## MCP Fundamentals\n\nBefore explaining WriteGuard, let’s review what an MCP server is and how it works with AI agents.\n\nMCP 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.\n\nWhen an agent selects a tool, the MCP client sends the tool call to the server, which then interacts with the downstream application.\n\n## MCPs at Cloudflare\n\nMCP 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\n\n[, as well as through long-running agentic services. We run the servers behind](http://blog.cloudflare.com/cloudflare-os)\n\n__Cloudflare OS__[and connect to them through a single internal](https://developers.cloudflare.com/cloudflare-one/access-controls/)\n\n__Cloudflare Access__[.](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)\n\n__MCP server portal__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.\n\nRead-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.\n\nTo 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.\n\nSo we built WriteGuard.\n\n## Introducing WriteGuard\n\nWriteGuard is a shared policy, attribution, and auditing layer.\n\nIt 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.\n\nThe diagram below shows where WriteGuard sits in our current internal MCP architecture.\n\nWriteGuard 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.\n\n## Beyond callable tools to governable actions\n\nWriteGuard 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.\n\nRisk Tier | Examples |\n|---|---|\nRead Only | Search issues; read a Merge Request (MR); view pipeline status |\nMinimal Impact | Add a reaction; mark a notification as read; subscribe to an issue |\nContained Write | Add a comment; create an MR; update an issue field |\nCritical | Merge an MR; trigger a production deployment; bulk-delete records |\n\n``` js\nconst sendEmailTool = {\n  tool: EmailMCP.sendEmailTool,\n  writeGuard: {\n    riskLevel: RiskLevel.CONTAINED_WRITE,\n    enabled: true,\n    labeling: {\n      field: \"body\",\n      supportedFormats: [\n        LabelFormat.PLAIN_TEXT,\n        LabelFormat.HTML,\n      ],\n    },\n  },\n};\n```\n\nToday, 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.\n\n## Keep the person, add the agent\n\nOur 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.\n\nWe 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.\n\nWriteGuard 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.\n\n## Make machine-speed activity queryable\n\nVisible 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.\n\nWriteGuard 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.\n\nThis makes agentic activity queryable across all of our MCP-enabled systems.\n\nThe 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.\n\nWe made audit logging asynchronous, so it adds no latency to the response the agent is waiting for.\n\n## WriteGuard in Action: GitLab\n\nEarlier 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.\n\n### Reading a merge request\n\nSuppose 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.\n\n### Adding a note to a merge request\n\nNow the engineer asks the agent to leave comments on a merge request (MR), and the agent calls the create_mr_note tool.\n\nThe 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.\n\n### Merging the code\n\nSuppose 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.\n\nBecause 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.\n\nIf called, WriteGuard will block the request before its handler runs and record the attempt.\n\n## Beyond the single server example\n\nThese tools use the same server, identity flow, and downstream API, but WriteGuard handles each one differently before its code runs.\n\nFor 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.\n\nInstead, we built WriteGuard as a shared layer that needs only per-tool configuration and works across every MCP server connected through the portal.\n\n## From internal rollout to private beta\n\nWe 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.\n\nThe 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.\n\nIf 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/).", "url": "https://wpnews.pro/news/writeguard-fine-grained-controls-for-mcp-servers", "canonical_source": "https://blog.cloudflare.com/mcp-portal-writeguard-private-beta/", "published_at": "2026-08-05 13:00:00+00:00", "updated_at": "2026-08-05 13:59:44.919003+00:00", "lang": "en", "topics": ["ai-safety", "ai-policy", "ai-infrastructure", "ai-tools"], "entities": ["Cloudflare", "WriteGuard", "Model Context Protocol", "Cloudflare MCP server portals", "OpenCode", "Cloudflare OS", "Cloudflare Access", "Jira"], "alternates": {"html": "https://wpnews.pro/news/writeguard-fine-grained-controls-for-mcp-servers", "markdown": "https://wpnews.pro/news/writeguard-fine-grained-controls-for-mcp-servers.md", "text": "https://wpnews.pro/news/writeguard-fine-grained-controls-for-mcp-servers.txt", "jsonld": "https://wpnews.pro/news/writeguard-fine-grained-controls-for-mcp-servers.jsonld"}}