Cloudflare 將 Workers 存取權拆分為角色與範圍，而非單一大型權限清單

隨著越來越多團隊與自主編碼代理開始直接部署到 Cloudflare 的 Developer Platform，既有的權限模型迫使他們做出一個令人為難的選擇：授予廣泛的帳戶層級角色，讓代理得以觸及帳戶中的每一個 Worker、資料庫與儲存桶；或是手工建構足以涵蓋每種情況的個別權限——而隨著資源與動作數量增長，這種做法會變得難以管理。

Cloudflare 的解法是停止將存取權視為一份扁平清單，改為定義兩個獨立的維度。四種角色——中繼資料唯讀、內容唯讀、編輯者與管理員——描述能力層級，從檢視日誌與指標而不看到程式碼，到讀取程式碼而不編輯，到編輯而不刪除，再到完整控制。另外，每種角色可套用於三種範圍之一：Developer Platform 上的每一項資源、單一產品（所有 Workers）的每一項資源，或單一具名資源（某個特定的 Worker）。

這兩個軸向可獨立組合。CI/CD 管線可取得僅限於其部署的那一個 Worker 的編輯者角色，因此外洩的權杖雖能更新該 Worker，卻無法刪除它或觸及任何其他應用程式。除錯代理可取得僅限於某一個 Worker 的中繼資料唯讀角色，因此它能檢視日誌與追蹤記錄，卻永遠無法讀取原始碼。Cloudflare 設計了同樣的「角色乘以範圍」結構，以便日後延伸至其他 Developer Platform 資源，例如 D1 資料庫與 R2 儲存桶，而非為每個產品另行發明新權限。

將「你能做什麼」（角色）與「你能在哪裡做」（範圍）分離為兩個獨立的軸向

將四種角色與三種範圍交叉組合，能以一套小而固定的詞彙產生十二種精確的存取層級，而非為每項資源產生一次性權限的組合爆炸。

將範圍限定於單一資源（一個 Worker）意味著遭入侵或設定錯誤的代理權杖其影響半徑受到侷限——它無法看見或觸及帳戶中的任何其他資源。

同樣的角色／範圍結構在設計上可延伸至其他產品（D1、R2、KV），而無須每次重新設計模型。

Durable Objects 從其父 Worker 的角色繼承存取權，而不需要自己的權限系統，使模型不至於進一步碎裂。

當存取需求隨著更多代理而倍增時，不要增加更多個別權限——將存取控制拆分為兩個正交的軸向，即能力與範圍，讓它們組合而非相乘。

Cloudflare 也新增了情境化的 403 錯誤回應，直接連結到說明缺少哪項權限的文件，因此遇到權限阻擋的代理或開發者能夠自行修正，而不會卡在籠統的「Forbidden」回應上。該公司表示，計畫接下來將同樣的角色與範圍模型延伸至 D1 資料庫、R2 儲存桶與 KV 命名空間。