Cloudflare 推出了 WriteGuard（目前处于私有测试阶段），旨在为 MCP（模型上下文协议）服务器提供精细化的安全控制。对于能够修改数据或执行操作的工具，该功能可以控制 AI 代理的访问权限（而非仅限于读取信息），从而提升 AI 代理的安全性。
WriteGuard 是一个集策略、归因和审计于一体的共享层，旨在应对 AI 代理使用 MCP 访问具有写入权限的外部服务（包括数据库、GitHub、SaaS 应用程序、内部 API 等）时产生的风险。
只读模式是一个不错的起点。随着模型的不断改进，团队在人工智能领域积累了更多的经验，来自工程、产品、设计、销售和客户成功等部门的人开始寻求能够执行操作的工具。[……] 我们希望能够集中控制智能代理可以执行的写入操作，确保智能代理标签能在下游应用程序中显示，并建立审计日志，方便调查智能代理的活动。
WriteGuard 部署在 Cloudflare 的 MCP 服务器门户之后，拦截所有传入的 MCP 请求。它会加载与目标工具关联的策略，并评估请求上下文，以确定是允许该请求原样通过，还是应该阻止。如果获得允许的请求随后失败，那么它将与所有最初被拒绝的请求一起被路由到审计服务。
据 Cloudflare 工程师 Scott Roe-Meschke 和 Kenny Johnson 介绍，WriteGuard 的优势在于能够针对特定的工具定义策略，而不需要更改 MCP 服务器本身。它还充当所有通过 Cloudflare 门户连接 MCP 服务器的公共安全层。
仅就 GitLab 而言，我们本可以直接将这些控制措施集成到服务器中。但我们还需要为 Jira、内部维基、Google Workspace 以及新增的每台 MCP 服务器提供相同的功能。如果在每台服务器上重新实现这些功能，不仅工作量更大，还会导致行为不一致。
每项工具都被分配了一个风险等级，从完全没有风险的 read-only 到 critical 。例如，完成合并请求、触发生产环境部署或批量删除记录均被归类为关键操作。创建合并请求或更新问题字段属于 contained write 级别，而将通知标记为已读、订阅问题或添加评论等影响较小的操作则属于 minimal impact。
Roe-Meschke 和 Johnson 指出，WriteGuard 不需要创建独立的智能代理账户，否则将“产生第二套需要管理的权限”。相反，MCP 服务器使用现有的 OAuth 凭据来识别用户。为了确保在集中式审计日志中仍然能识别出由智能代理驱动的操作，WriteGuard 会将 MCP 客户端和会话上下文添加到用户身份信息中。
WriteGuard 将每次调用分类为“成功”、“失败”或“被阻止”，并在随后异步向内部审计 Worker 发送一条经过脱敏处理的事件。该事件会省略被视为机密或敏感信息的键值，并包含服务器、工具、风险等级、结果、用户、客户端和持续时间等信息。
WriteGuard 目前处于私有测试阶段，这使 Cloudflare 能够在正式发布前验证其行为并优化产品功能。
原文链接：https://www.infoq.com/news/2026/08/cloudflare-writeguard-mcp-safety/
