Cloudflare WriteGuard：MCP Server 写入细粒度管控方案

案例：无穷无尽地关闭工单

Bug 工单从中午开始被关闭。没人多想这件事。Joe 把几个工单移到了 Done，Joe 度过了一个高效的下午。然后速度越来越快。到下午 4 点，成千上万个工单被关闭了，全部来自 Joe。

Joe 是个好工程师。Joe 不是那种一小时处理一千个工单的工程师。

我们发现他在三个并发会话中运行着多个后台 Agent。找出那个有问题的 Agent 花了半个小时：一个清理任务，其 prompt 有点过于宽泛。

一旦我们停掉了那个 Agent，就需要修复工单系统的状态。Joe 那天下午也手工合法地关闭了一些工单。系统把所有这些变更都记录在 Joe 名下，无论是他本人还是他的 Agent 操作的，而网络日志无法区分不同的 Agent 会话。从外部看，这些操作看起来完全相同。

上面的例子风险相对较低，但我们都能想象，或者读到更具破坏性的案例。一个可以访问合同软件的 Agent 可以修改协议。一个在支持队列中肆虐的 Agent 可以向客户发送数百条回复。一个有数据库访问权限的 Agent 可以删除整个表。

在 Cloudflare，我们知道我们不能依赖每个员工都完美配置每个 Agent 或监视每个工具调用。因此，在向我们自己的内部 MCP 服务器扩展写权限之前，我们构建了 WriteGuard。我们现在正通过 private beta 将这些控制引入 Cloudflare MCP server portals。

在解释 WriteGuard 之前，让我们回顾一下什么是 MCP server 以及它如何与 AI Agent 配合工作。

MCP 代表 Model Context Protocol，这是一个流行的标准，用于将 AI 应用程序连接到外部工具和数据源。MCP 服务器提供连接客户端可以使用的工具。每个工具都有名称、描述、输入 schema 和执行工作的处理程序。

当 Agent 选择一个工具时，MCP 客户端将工具调用发送到服务器，然后服务器与下游应用程序交互。

MCP 是为 Cloudflare 内部 Agent 提供动力的关键基础设施组件。这些 Agent 通过本地客户端（如 OpenCode 和 Cloudflare OS）以及长期运行的 agentic 服务使用 MCP。我们在 Cloudflare Access 后面运行服务器，并通过单个内部 MCP server portal 连接到它们。

当我们在四月描述我们的内部 AI 工程栈时，我们的 portal 连接了 13 个 MCP 服务器。今天，它连接了 27 个，团队每月都在交付更多服务器。它们最初都是只读服务器，允许团队搜索 Jira、GitLab、我们的 wiki 和运营系统，而无需更改它们。

只读是一个好的起点。随着模型改进和团队获得 AI 经验，工程、产品、设计、销售和客户成功领域的人们开始请求可以执行操作的工具。

为了避免我们自己遇到的无休止关闭工单的情况，我们希望对 Agent 可以执行的写操作进行集中控制，让 Agent 标签出现在下游应用程序中，并提供审计追踪，使 Agent 活动易于调查。我们不能依赖客户端控制（如 skills 或 elicitation prompts）。它们的行为因 harness 而异，用户可以禁用它们。

所以我们构建了 WriteGuard。

介绍 WriteGuard

WriteGuard 是一个共享的策略、归属和审计层。

它使用每个工具的配置和请求上下文来确定发生了什么。WriteGuard 可以让调用原样通过，用 Agent 归属信息丰富支持的写操作并生成一个清理过的审计事件，或者在处理程序运行之前阻止操作。

下图展示了 WriteGuard 在我们当前内部 MCP 架构中的位置。

WriteGuard 将工具策略与人类和 Agent 身份、下游归属和集中审计结合起来。它给了我们一个统一的地方来控制 Agent 操作并保留理解它们所需的上下文。

从可调用工具到可治理操作

WriteGuard 让我们可以沿着每个工具定义策略，而无需更改底层 MCP 服务器。每个工具都有风险等级、启用或禁用状态以及标签配置。风险等级决定操作是否被记录以及工具调用是否被允许，这些等级允许按风险查询审计日志。我们支持标签，以便我们可以插入 Agent 归属标签，并使用对下游应用程序最佳的文本格式，而无需在 MCP 服务器本身进行任何代码更改。

搜索问题；阅读合并请求（MR）；查看流水线状态 — 读操作，原样通过

添加反应；将通知标记为已读；订阅问题 — contained write，记录

添加评论；创建 MR；更新问题字段 — contained write，记录

合并 MR；触发生产部署；批量删除记录 — critical，阻止

const sendEmailTool = {
  tool: EmailMCP.sendEmailTool,
  writeGuard: {
    riskLevel: RiskLevel.CONTAINED_WRITE,
    enabled: true,
    labeling: {
      field: "body",
      supportedFormats: [
        LabelFormat.PLAIN_TEXT,
        LabelFormat.HTML,
      ],
    },
  },
};

今天，我们在内部 MCP monorepo 的 TypeScript 中定义此配置。随着 private beta 访问在未来几个月逐步推出，服务器所有者将能够通过 Cloudflare MCP server portals 配置相同的策略。每个 MCP 服务器都将有一个基线 Access 策略以及针对单个工具的 WriteGuard 控制。

保留人员，添加 Agent

我们的内部 MCP 服务器使用 Cloudflare Access 和 OAuth 来识别用户。因此，使用这些服务器的 Agent 因此代表该员工执行操作。如果 Joe 不能关闭某个特定问题，Joe 的 Agent 也不能关闭它。

我们保留了该模型，而不是引入独立的 Agent 账户。Agent 账户会创建第二组需要管理的权限，并使与 Agent 负责人的联系变得不那么清晰。然而，该决定的权衡是，下游应用程序看到的是 Joe 的凭证，但没有识别操作背后的 Agent。

WriteGuard 将 MCP 客户端和会话上下文添加到人类身份中，将每次写操作识别为代表特定人员行事的 Agent 会话。值得注意的是，即使一切正常，这种归属也非常有用。它帮助人类和其他 Agent 解释变更并决定如何回应。

让机器速度的活动可查询

可见的标签解释个人操作并在下游应用程序中提供有用的上下文，但它们不能提供全舰队视图。因为 Agent 可以比人更快地重复操作，我们还需要跨每个 MCP 服务器进行集中审计。

WriteGuard 将每次调用分类为成功、失败或阻止，然后异步向内部审计 Worker 发送一个清理过的事件。该事件省略被视为秘密或敏感的键的值。它包含服务器、工具、风险等级、结果、用户、客户端和持续时间。

这使得跨我们所有 MCP 启用系统的 Agent 活动可查询。

该仪表板补充了 MCP server portals 提供请求日志。Portal 日志显示工具调用，而 WriteGuard 添加了语义工具分类、Agent 上下文和来自支持服务器的结果。

我们使审计日志异步，因此它不会为 Agent 等待的响应增加任何延迟。

WriteGuard 实战：GitLab

在本文早些时候，我们提到了 GitLab MCP 服务器的三个工具：get_merge_request、create_mr_note 和 merge_mr。让我们通过 WriteGuard 来追踪每一个。

阅读合并请求

假设一名工程师要求 Agent 总结一个提议的代码变更，而 Agent 调用了 get_merge_request 工具。WriteGuard 将该工具分类为 READ_ONLY，WriteGuard 允许调用原样通过。

向合并请求添加备注

现在工程师要求 Agent 在合并请求（MR）上留下评论，Agent 调用了 create_mr_note 工具。

该工具被分类为 CONTAINED_WRITE。WriteGuard 使用 GitLab 支持的格式向配置的备注字段添加 Agent 归属，然后调用工具处理程序。它还异步记录一个清理过的审计事件，包含用户、工具、结果和 Agent 身份上下文。

合并 MR

假设工程师要求 Agent 帮助审查合并请求。为了表现得有帮助，Agent 超越了请求，未经要求就调用了 merge_mr 工具。

因为在 Cloudflare 合并通常会触发部署流水线，我们要求有人在循环中。因此我们将 merge_mr 工具分类为 CRITICAL 风险等级，并在 WriteGuard 中将工具配置为禁用。

如果被调用，WriteGuard 将在其处理程序运行之前阻止请求并记录该尝试。

超越单个服务器示例

这些工具使用相同的服务器、身份流程和下游 API，但 WriteGuard 在代码运行之前对每个工具进行不同的处理。

仅对于 GitLab，我们本可以将这些控制直接构建到服务器中。但我们对 Jira、我们的内部 wiki、Google Workspace 以及我们添加的每个新 MCP 服务器都需要相同的能力。在每个服务器中重新实现它们会花费更多工作并产生不一致的行为。

相反，我们将 WriteGuard 构建为一个共享层，只需每个工具的配置即可工作，并通过 portal 连接的所有 MCP 服务器运行。

从内部推广到 Private Beta

我们为 Cloudflare 自己的 MCP 服务器构建了 WriteGuard，因为我们需要在不失去对后续写操作控制的情况下超越只读工具。Private beta 将该架构引入 MCP server portals，提供了一种对写工具进行分类、在执行前阻止工具、添加 Agent 归属以及检查跨连接服务器的写活动的方式。

Beta 将从小规模开始，随着时间推移逐步扩展，直至正式发布。我们希望在广泛提供 WriteGuard 之前，验证风险模型如何映射到客户工具、哪些下游应用程序需要归属格式，以及客户需要什么审计交付保证。

如果您的组织正在向 MCP 服务器添加写工具，并希望与我们一起测试这些控制，请注册 WriteGuard private beta。