過去在 Cloudflare 上管理 Workers 權限，最常見的麻煩是「範圍太大」。你要嘛給對方整個帳號的權限，要嘛在角色與權限之間來回猜測。當 CI/CD 流程和 agent 也開始部署程式碼，這個問題就從不方便變成風險：一個被賦予過多權限的 agent，可能因為一次錯誤的呼叫就動到 production。
Cloudflare 在 2026 年 9 月 15 日推出 Workers 的資源層級授權，讓你能把權限縮到單一 Worker，並搭配四種新角色。這篇文章談的是它改變了什麼，以及你在設計自動化流程時該怎麼用。
四種角色，對應四種「夠用就好」
Cloudflare 把角色收斂成四種，對應不同的工作情境：
- Metadata Read-Only：能看設定、metrics、logs、traces，但看不到 Worker 的原始碼。適合除錯。
- Content Read-Only：能讀取程式碼做審查，但不能修改或部署。適合 code review agent。
- Editor：能部署新版本，但不能刪除 Worker。適合 CI/CD 流程。
- Admin：最高權限，包含刪除。
這四種角色可以套用在三個層級：整個 Developer Platform、單一產品（例如所有 Workers），或單一資源（例如某一個 Worker）。角色決定「能做什麼」，層級決定「能對誰做」。
為什麼這對 agent 特別重要
Cloudflare 在公告中直接點出這個動機：你不會希望 agent 只因為被授予過多權限，就在 production 做出變更。
實際做法是替 agent 建立一個帶有 scoped access 的 API token，讓它只能存取某一個應用程式。如果 agent 被限制在單一 Worker，它透過 Cloudflare API 調查問題時，也只會拿到那個 Worker 的資料，看不到帳號裡其他 Worker 的內容。
這和我們之前在把互動介面塞進對話框之後談到的部署取捨是同一個問題：agent 能碰到的東西越多，你需要設計的邊界就越多。差別在於，這次的邊界不是寫在 prompt 裡，而是寫在授權層。
CI 部署與路由權限的分離
對 CI/CD 來說，最實用的組合是「Editor 角色 + 單一 Worker 範圍」。這樣即使流程設定錯誤或 token 外洩，影響也侷限在那個 Worker：它可以部署新版本，但不能刪除，也不能碰其他應用程式。
路由與 Custom Domain 是另一個需要留意的邊界。要新增、修改或移除路由，你需要同時具備該 Worker 的 Editor 權限，以及該 zone 的 Workers Routes 權限。Cloudflare 選擇要求 Workers Routes 權限而不是更廣泛的 zone 權限，讓你能管理流量怎麼進到 Worker，而不必交出整個網域的其他設定。
反過來說，一旦路由設定完成，只要部署不改變那個連線，你就能繼續部署新版本，不需要 zone 或相關資源的權限。這讓 CI 系統可以部署應用程式，而不必同時拿到你的網域、資料庫或儲存空間。
Durable Objects 與錯誤訊息的處理
Durable Objects 沒有自己的角色或權限，存取權取決於你對實作它的 Worker 的權限。Metadata Read-Only 能看 Durable Object 的 metrics、logs、traces，但看不到物件裡儲存的資料；因為 Data Studio 可以直接查詢和修改那些資料，所以需要 Editor 角色。
另一個實務上的改進是錯誤訊息。當權限不足時，API 不再只回傳通用的 403，而是附上相關 API 文件的連結，讓你和 agent 能查出需要哪些權限，而不是直接要求更大的權限。
現在可以怎麼開始
這些 Worker 層級的存取控制已經對所有客戶開放，可以透過 dashboard、API 或 Terraform 設定。如果同一個團隊或專案有多人需要相同權限，可以建立 User Group，把 policy 指派給群組，成員會自動繼承。
舊的角色與權限沒有設定淘汰日期，現有指派會繼續運作。Cloudflare 建議開始轉向新角色，因為只有新角色支援資源層級的授權。
下一步是把同樣的資源層級控制帶到更多 Developer Platform 產品，包括 KV namespace 和 D1 資料庫，並沿用同一組角色。對正在把 agent 接進部署流程的團隊來說，值得先盤點：目前有哪些 token 的權限範圍，其實比它實際需要的還大。
（本文依據 Cloudflare 官方公告整理，未經實測。）
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。