摘要： Cloudflare 於 2026 年 9 月 15 日發表 Workers 資源層級授權，可把 agent 或 CI 的權限限縮到單一 Worker。新設計提供 Metadata Read-Only、Content Read-Only、Editor 與 Admin 四種角色，並可在三個層級套用。路由和 Custom Domain 變更仍需要 Worker Editor 加上 zone 層級的 Workers Routes 權限。
以前在 Cloudflare 管 Workers 的權限，痛點幾乎都出在「範圍」兩個字上。選項往往只有兩種：不是把整個帳號交出去，就是在角色與權限的各種組合裡反覆推敲。等到 CI/CD 流程和 agent 也開始負責部署程式碼，這種模糊地帶就從「不方便」升級成實質風險——權限給得太多的 agent，只要一次叫錯 API，就可能直接動到 production。
2026 年 9 月 15 日，Cloudflare 發表了 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 官方公告，未經實測。）