Cloudflare 将 Workers 访问权限拆分为角色和范围，而非一份大权限清单

随着越来越多的团队和自主编码代理开始直接部署到 Cloudflare 的开发者平台，现有的权限模型迫使人们做出一个令人不安的选择：要么授予宽泛的账户级角色，让代理能够触及账户中的每个 Worker、数据库和存储桶；要么手工构建足够多的单独权限以覆盖所有情况——而随着资源数量和操作数量的增长，这种做法会变得难以管理。

Cloudflare 的解决办法是停止将访问权限视为一份扁平清单，转而定义两个相互独立的维度。四种角色——元数据只读、内容只读、编辑者和管理员——描述能力级别，从查看日志和指标但不查看代码，到读取代码但不编辑，到编辑但不删除，再到完全控制。另外，每种角色都可以应用于三种范围之一：开发者平台上的每个资源、某个产品的每个资源（所有 Workers），或单个命名资源（某个特定的 Worker）。

这两个维度可以独立组合。CI/CD 流水线可以获得编辑者角色，且范围恰好限定为它部署的那一个 Worker，因此即使令牌泄露，也只能更新该 Worker，而无法删除它或触及任何其他应用。调试代理可以获得元数据只读角色，且范围限定为一个 Worker，因此它可以检查日志和追踪信息，而永远无法读取源代码。Cloudflare 设计了同样的“角色乘以范围”结构，以便日后扩展到其他开发者平台资源（如 D1 数据库和 R2 存储桶），而不是为每个产品发明新的权限。

将“你能做什么”（角色）与“你能在哪里做”（范围）分离为两个相互独立的维度

将四种角色与三种范围交叉组合，用一套小而固定的词汇产生十二种精确的访问级别，而不是为每个资源单独设置权限所导致的组合爆炸。

将范围限定为单个资源（一个 Worker）意味着被泄露或配置错误的代理令牌影响范围有限——它无法看到或触及账户中的任何其他资源。

同样的角色/范围结构被设计为可扩展到其他产品（D1、R2、KV），而无需每次都重新设计模型。

Durable Objects 从其父 Worker 的角色继承访问权限，而无需自己的权限系统，从而避免模型进一步碎片化。

当访问需求随着更多代理而倍增时，不要添加更多单独权限——而应将访问控制拆分为两个正交维度：能力和范围，它们可以组合而非相乘。

Cloudflare 还添加了上下文相关的 403 错误响应，直接链接到说明缺少哪项权限的文档，因此遇到权限墙的代理或开发者可以自行纠正，而不是卡在通用的“禁止访问”响应上。该公司表示，计划接下来将同样的角色和范围模型扩展到 D1 数据库、R2 存储桶和 KV 命名空间。