WriteGuard：MCP 服务器的细粒度控制
让我们设想一下一个不断关闭工单的案例。
工单在中午开始关闭。没人对此多加注意。乔处理了一些工单，并度过了一个高效的下午。然后关闭工单的速度加快。到下午四点，成千上万的工单都被乔关闭了。
乔是个优秀的工程师，但他并不是每小时关闭一千个工单的工程师。
我们得知他在三个并发会话中运行了多个后台代理。找到故障的代理花费了半小时：一个清理任务的提示过于宽泛。
一旦我们停止了该代理，就需要修复工单系统的状态。乔在那天下午也确实手动关闭了一些工单。系统将所有这些更改记录在乔名下，无论是他自己操作还是他的代理，网络日志也无法区分不同的代理会话。外部看，这些操作是一样的。
上述例子风险相对较低，但我们都能想象，或者[阅读关于](https://www.theguardian.com/technology/2026/apr/29/claude-ai-deletes-firm-database)更具破坏性的案例。一个可以访问合同软件的代理可能会修改协议；一个在支持队列中肆虐的代理可能会向客户发送数百条回复；一个可以访问数据库的代理可能会删除整个数据表。
在 Cloudflare，我们知道不能依赖每位员工完美配置每个代理或监控每个工具调用。因此，在扩展我们自己内部的 MCP 服务器的写权限之前，我们构建了 WriteGuard。我们现在通过私人测试版将这些控制引入[Cloudflare MCP 服务器门户](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)。
## MCP 基础知识
在解释 WriteGuard 之前，先回顾一下什么是 MCP 服务器及其如何与 AI 代理协同工作。
MCP 代表[模型上下文协议](https://modelcontextprotocol.io/)，这是一个流行的标准，用于将 AI 应用程序与外部工具和数据源连接。MCP 服务器提供已连接客户端可使用的工具。每个工具都有一个名称、描述、输入模式和执行工作的处理程序。
当代理选择工具时，MCP 客户端会将工具调用发送到服务器，然后与下游应用程序交互。
## Cloudflare 的 MCP
MCP 是支持 Cloudflare 内部代理的关键基础架构组成部分。那些代理通过本地客户端（如[OpenCode](https://opencode.ai/)和[Cloudflare OS](http://blog.cloudflare.com/cloudflare-os)）以及通过长时间运行的代理服务使用 MCP。我们在[Cloudflare Access](https://developers.cloudflare.com/cloudflare-one/access-controls/)后面运行服务器，并通过一个内部的[ MCP 服务器门户](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)进行连接。
当我们在四月份描述[我们的内部 AI 工程技术栈](https://blog.cloudflare.com/internal-ai-engineering-stack/)时，我们的门户连接了 13 个 MCP 服务器。今天，它连接了 27 个，每个月都有团队部署更多的服务器。它们最初都是只读服务器，允许团队在不更改的情况下搜索 Jira、GitLab、我们的维基以及操作系统。
只读是一个良好的起点。随着模型的改进和团队在 AI 方面的经验的积累，工程、产品、设计、销售和客户成功等领域的人们开始要求能够采取行动的工具。
为了避免出现我们自己不断关闭工单的情况，我们希望能集中控制代理能够执行的写操作，确保代理标签在下游应用程序中显示，并有审计跟踪以便轻松调查代理活动。我们无法依赖客户端控制，如技能或引导提示。它们的行为因使用的设备而异，用户可以禁用它们。
因此，我们构建了 WriteGuard。
## 介绍 WriteGuard
WriteGuard 是一个共享策略、归属和审计层。
它使用每个工具的配置和请求上下文来决定发生什么。WriteGuard 可以不改变地传递调用，丰富支持的写入操作与代理归属，生成清理的审计事件，或在处理程序运行之前阻止操作。
下图展示了 WriteGuard 在我们当前内部 MCP 架构中的位置。
WriteGuard 将工具策略与人类和代理身份、下游归属以及集中审计结合起来。它为我们提供一个控制代理行动的地方，并保留理解它们所需的上下文。
## 超越可调用工具到可治理操作
WriteGuard 使我们能够在不改变底层 MCP 服务器的情况下，为每个工具定义策略。每个工具都有一个风险层、启用或禁用状态以及标签配置。风险层决定该操作是否被记录，工具调用是否被允许，这些层允许按风险查询审计日志。我们支持标签，以便能够插入代理归属标签，并使用最适合下游应用程序的文本格式，而无需在 MCP 服务器中进行任何代码更改。
今天，我们在我们的内部 MCP 单仓库中使用 TypeScript 定义此配置。随着私人测试版在未来几个月的推出，服务器所有者将能够通过 Cloudflare MCP 服务器门户来配置相同的策略。每个 MCP 服务器将具有基线访问策略以及单个工具的 WriteGuard 控制。
## 保持人类，增加代理
我们的内部 MCP 服务器使用[Cloudflare Access 和 OAuth](https://blog.cloudflare.com/managed-oauth-for-access/) 来识别用户。因此，使用这些服务器的代理以该员工的权限运行。如果乔无法关闭某个特定问题，乔的代理也无法关闭它。
我们保留了这种模型，而不是引入独立的代理账户。代理账户会创建第二组权限，更难管理，同时使责任人和代理之间的联系变得不清晰。然而，这个决定的权衡在于，下游应用程序看到的是乔的凭证，但没有任何信息来标识代理在背后执行的操作。
WriteGuard 将 MCP 客户端和会话上下文添加到人类身份，从而识别每个写操作为代表特定人的代理会话。值得注意的是，即使在没有出现问题的情况下，这种归属也是极其有用的。它帮助人类和其他代理理解更改并决定如何响应。
## 使机器速度活动可查询
可见标签解释各个操作，并在下游应用程序中提供有益的上下文，但它们并不能提供整个系统的全景视图。由于代理执行操作的速度远快于人类，我们还需要对每个 MCP 服务器进行集中审计。
WriteGuard 将每次调用分类为成功、失败或被阻止，然后异步发送清理后的事件到内部审计 Worker。该事件省略了被视为秘密或敏感的键的值。它包括服务器、工具、风险层、结果、用户、客户端和持续时间。
这使得代理活动能够在我们所有启用 MCP 的系统中进行查询。
仪表板补充了通过[MCP 服务器门户](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)提供的请求日志。门户日志显示工具调用，而 WriteGuard 增加了语义工具分类、代理上下文和来自支持服务器的结果。
我们将审计日志记录设置为异步，因此它不会增加代理正在等待的响应的延迟。
## WriteGuard 的实际应用：GitLab
在本文早些时候，我们提到 GitLab MCP 服务器中的三个工具：get_merge_request、create_mr_note 和 merge_mr。让我们跟随每一个工具经过 WriteGuard。
### 阅读合并请求
假设一名工程师要求代理总结提议的代码更改，代理调用了 `get_merge_request` 工具。WriteGuard 将此工具分类为 `READ_ONLY`，并允许调用不变地通过。
### 在合并请求中添加注释
现在，工程师要求代理在合并请求（MR）中留下评论，代理调用 `create_mr_note` 工具。
该工具被分类为 CONTAINED_WRITE。WriteGuard 将代理归属添加到配置的注释字段中，使用 GitLab 支持的格式，然后调用工具处理程序。它还异步记录了一条清理的审计事件，包含用户、工具、结果和代理身份上下文。
### 合并代码
假设一名工程师要求代理帮助审核合并请求。为了表现得友好，代理超出了请求并在没有被请求的情况下调用了 merge_mr 工具。
因为在 Cloudflare 合并通常会触发部署管道，所以我们需要人类在场。因此，我们将 merge_mr 工具分类为 CRITICAL 风险层，并在 WriteGuard 中将该工具禁用。
如果被调用，WriteGuard 会在处理程序运行之前阻止请求并记录尝试。
## 超越单一服务器的示例
这些工具使用相同的服务器、身份流和下游 API，但 WriteGuard 在其代码运行之前以不同方式处理每一个。
仅仅对于 GitLab，我们可以直接在服务器中构建这些控制。但我们需要对 Jira、我们的内部维基、Google Workspace 以及每个新添加的 MCP 服务器提供相同的能力。如果在每个服务器中重新实现这些控制将需要更多的工作，并可能产生不一致的行为。
因此，我们构建了 WriteGuard 作为一个共享层，只需每个工具的配置，便可以跨通过门户连接的每个 MCP 服务器工作。
## 从内部推广到私人测试版
我们为 Cloudflare 自己的 MCP 服务器构建了 WriteGuard，因为我们需要在不失去对后续写入控制的情况下，摆脱只读工具。这个[私人测试版](https://www.cloudflare.com/resource/writeguard-beta-landing-page/)将该架构带入 MCP 服务器门户，提供了一种分类写入工具、在执行前阻止工具、添加代理归属以及检查连接服务器写活动的方法。
测试版将起步较小并逐渐扩大，最后实现普遍可用。我们希望验证风险模型如何映射到客户工具，哪些下游应用程序需要归属格式，以及客户在广泛提供 WriteGuard 之前所需的审计交付保证。
如果您的组织正在向 MCP 服务器添加写工具，并希望与我们测试这些控制，[请注册 WriteGuard 私人测试版](https://www.cloudflare.com/resource/writeguard-beta-landing-page/)。
---
原文链接：[点击查看](https://blog.cloudflare.com/mcp-portal-writeguard-private-beta/)
工单在中午开始关闭。没人对此多加注意。乔处理了一些工单，并度过了一个高效的下午。然后关闭工单的速度加快。到下午四点，成千上万的工单都被乔关闭了。
乔是个优秀的工程师，但他并不是每小时关闭一千个工单的工程师。
我们得知他在三个并发会话中运行了多个后台代理。找到故障的代理花费了半小时：一个清理任务的提示过于宽泛。
一旦我们停止了该代理，就需要修复工单系统的状态。乔在那天下午也确实手动关闭了一些工单。系统将所有这些更改记录在乔名下，无论是他自己操作还是他的代理，网络日志也无法区分不同的代理会话。外部看，这些操作是一样的。
上述例子风险相对较低，但我们都能想象，或者[阅读关于](https://www.theguardian.com/technology/2026/apr/29/claude-ai-deletes-firm-database)更具破坏性的案例。一个可以访问合同软件的代理可能会修改协议；一个在支持队列中肆虐的代理可能会向客户发送数百条回复；一个可以访问数据库的代理可能会删除整个数据表。
在 Cloudflare，我们知道不能依赖每位员工完美配置每个代理或监控每个工具调用。因此，在扩展我们自己内部的 MCP 服务器的写权限之前，我们构建了 WriteGuard。我们现在通过私人测试版将这些控制引入[Cloudflare MCP 服务器门户](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)。
## MCP 基础知识
在解释 WriteGuard 之前，先回顾一下什么是 MCP 服务器及其如何与 AI 代理协同工作。
MCP 代表[模型上下文协议](https://modelcontextprotocol.io/)，这是一个流行的标准，用于将 AI 应用程序与外部工具和数据源连接。MCP 服务器提供已连接客户端可使用的工具。每个工具都有一个名称、描述、输入模式和执行工作的处理程序。
当代理选择工具时，MCP 客户端会将工具调用发送到服务器，然后与下游应用程序交互。
## Cloudflare 的 MCP
MCP 是支持 Cloudflare 内部代理的关键基础架构组成部分。那些代理通过本地客户端（如[OpenCode](https://opencode.ai/)和[Cloudflare OS](http://blog.cloudflare.com/cloudflare-os)）以及通过长时间运行的代理服务使用 MCP。我们在[Cloudflare Access](https://developers.cloudflare.com/cloudflare-one/access-controls/)后面运行服务器，并通过一个内部的[ MCP 服务器门户](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)进行连接。
当我们在四月份描述[我们的内部 AI 工程技术栈](https://blog.cloudflare.com/internal-ai-engineering-stack/)时，我们的门户连接了 13 个 MCP 服务器。今天，它连接了 27 个，每个月都有团队部署更多的服务器。它们最初都是只读服务器，允许团队在不更改的情况下搜索 Jira、GitLab、我们的维基以及操作系统。
只读是一个良好的起点。随着模型的改进和团队在 AI 方面的经验的积累，工程、产品、设计、销售和客户成功等领域的人们开始要求能够采取行动的工具。
为了避免出现我们自己不断关闭工单的情况，我们希望能集中控制代理能够执行的写操作，确保代理标签在下游应用程序中显示，并有审计跟踪以便轻松调查代理活动。我们无法依赖客户端控制，如技能或引导提示。它们的行为因使用的设备而异，用户可以禁用它们。
因此，我们构建了 WriteGuard。
## 介绍 WriteGuard
WriteGuard 是一个共享策略、归属和审计层。
它使用每个工具的配置和请求上下文来决定发生什么。WriteGuard 可以不改变地传递调用，丰富支持的写入操作与代理归属，生成清理的审计事件，或在处理程序运行之前阻止操作。
下图展示了 WriteGuard 在我们当前内部 MCP 架构中的位置。
WriteGuard 将工具策略与人类和代理身份、下游归属以及集中审计结合起来。它为我们提供一个控制代理行动的地方，并保留理解它们所需的上下文。
## 超越可调用工具到可治理操作
WriteGuard 使我们能够在不改变底层 MCP 服务器的情况下，为每个工具定义策略。每个工具都有一个风险层、启用或禁用状态以及标签配置。风险层决定该操作是否被记录，工具调用是否被允许，这些层允许按风险查询审计日志。我们支持标签，以便能够插入代理归属标签，并使用最适合下游应用程序的文本格式，而无需在 MCP 服务器中进行任何代码更改。
今天，我们在我们的内部 MCP 单仓库中使用 TypeScript 定义此配置。随着私人测试版在未来几个月的推出，服务器所有者将能够通过 Cloudflare MCP 服务器门户来配置相同的策略。每个 MCP 服务器将具有基线访问策略以及单个工具的 WriteGuard 控制。
## 保持人类，增加代理
我们的内部 MCP 服务器使用[Cloudflare Access 和 OAuth](https://blog.cloudflare.com/managed-oauth-for-access/) 来识别用户。因此，使用这些服务器的代理以该员工的权限运行。如果乔无法关闭某个特定问题，乔的代理也无法关闭它。
我们保留了这种模型，而不是引入独立的代理账户。代理账户会创建第二组权限，更难管理，同时使责任人和代理之间的联系变得不清晰。然而，这个决定的权衡在于，下游应用程序看到的是乔的凭证，但没有任何信息来标识代理在背后执行的操作。
WriteGuard 将 MCP 客户端和会话上下文添加到人类身份，从而识别每个写操作为代表特定人的代理会话。值得注意的是，即使在没有出现问题的情况下，这种归属也是极其有用的。它帮助人类和其他代理理解更改并决定如何响应。
## 使机器速度活动可查询
可见标签解释各个操作，并在下游应用程序中提供有益的上下文，但它们并不能提供整个系统的全景视图。由于代理执行操作的速度远快于人类，我们还需要对每个 MCP 服务器进行集中审计。
WriteGuard 将每次调用分类为成功、失败或被阻止，然后异步发送清理后的事件到内部审计 Worker。该事件省略了被视为秘密或敏感的键的值。它包括服务器、工具、风险层、结果、用户、客户端和持续时间。
这使得代理活动能够在我们所有启用 MCP 的系统中进行查询。
仪表板补充了通过[MCP 服务器门户](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)提供的请求日志。门户日志显示工具调用，而 WriteGuard 增加了语义工具分类、代理上下文和来自支持服务器的结果。
我们将审计日志记录设置为异步，因此它不会增加代理正在等待的响应的延迟。
## WriteGuard 的实际应用：GitLab
在本文早些时候，我们提到 GitLab MCP 服务器中的三个工具：get_merge_request、create_mr_note 和 merge_mr。让我们跟随每一个工具经过 WriteGuard。
### 阅读合并请求
假设一名工程师要求代理总结提议的代码更改，代理调用了 `get_merge_request` 工具。WriteGuard 将此工具分类为 `READ_ONLY`，并允许调用不变地通过。
### 在合并请求中添加注释
现在，工程师要求代理在合并请求（MR）中留下评论，代理调用 `create_mr_note` 工具。
该工具被分类为 CONTAINED_WRITE。WriteGuard 将代理归属添加到配置的注释字段中，使用 GitLab 支持的格式，然后调用工具处理程序。它还异步记录了一条清理的审计事件，包含用户、工具、结果和代理身份上下文。
### 合并代码
假设一名工程师要求代理帮助审核合并请求。为了表现得友好，代理超出了请求并在没有被请求的情况下调用了 merge_mr 工具。
因为在 Cloudflare 合并通常会触发部署管道，所以我们需要人类在场。因此，我们将 merge_mr 工具分类为 CRITICAL 风险层，并在 WriteGuard 中将该工具禁用。
如果被调用，WriteGuard 会在处理程序运行之前阻止请求并记录尝试。
## 超越单一服务器的示例
这些工具使用相同的服务器、身份流和下游 API，但 WriteGuard 在其代码运行之前以不同方式处理每一个。
仅仅对于 GitLab，我们可以直接在服务器中构建这些控制。但我们需要对 Jira、我们的内部维基、Google Workspace 以及每个新添加的 MCP 服务器提供相同的能力。如果在每个服务器中重新实现这些控制将需要更多的工作，并可能产生不一致的行为。
因此，我们构建了 WriteGuard 作为一个共享层，只需每个工具的配置，便可以跨通过门户连接的每个 MCP 服务器工作。
## 从内部推广到私人测试版
我们为 Cloudflare 自己的 MCP 服务器构建了 WriteGuard，因为我们需要在不失去对后续写入控制的情况下，摆脱只读工具。这个[私人测试版](https://www.cloudflare.com/resource/writeguard-beta-landing-page/)将该架构带入 MCP 服务器门户，提供了一种分类写入工具、在执行前阻止工具、添加代理归属以及检查连接服务器写活动的方法。
测试版将起步较小并逐渐扩大，最后实现普遍可用。我们希望验证风险模型如何映射到客户工具，哪些下游应用程序需要归属格式，以及客户在广泛提供 WriteGuard 之前所需的审计交付保证。
如果您的组织正在向 MCP 服务器添加写工具，并希望与我们测试这些控制，[请注册 WriteGuard 私人测试版](https://www.cloudflare.com/resource/writeguard-beta-landing-page/)。
---
原文链接：[点击查看](https://blog.cloudflare.com/mcp-portal-writeguard-private-beta/)
评论
暂无评论。