The problem with account-wide tokens
If you hand an agent an API token today, it usually carries the same reach as the account that issued it. That means a coding agent debugging one Worker can also read every other Worker’s source, and a CI workflow that only needs to deploy one app can delete another. Cloudflare’s new Worker-level access controls, published September 15, 2026, target exactly that gap: you can now scope a teammate or an agent to a single Worker instead of the whole account.
Four roles, three scopes
Cloudflare introduced four roles for Workers, each available today for all customers. Metadata Read-Only lets someone inspect settings, metrics, logs, and traces without seeing source code. Content Read-Only lets them read the code without deploying or changing settings. Editor allows deploys but not deletion. Admin is the highest level and can delete an application.
Each role can be applied at three scopes: the whole Developer Platform, a single product like Workers, or one specific resource. So a code review agent can hold Content Read-Only on one Worker and see nothing else in the account. Cloudflare says it plans to reuse these same roles as resource-level controls reach D1, R2, and KV.
What this changes for agent and CI tokens
The practical win is containment. A CI/CD workflow can get its own Editor token scoped to one Worker, so a misconfigured pipeline or a leaked token can deploy that app but cannot delete it or touch anything else. For agents, the same logic applies: an agent scoped to one Worker can query analytics and logs through the GraphQL API without pulling data from other Workers.
There is one wrinkle worth planning for. Routes and Custom Domains are not covered by Worker access alone. To add, change, or remove a route, you need Editor access to the Worker plus Workers Routes permission for the zone. Once a route is configured, though, you can keep deploying new versions without zone access, as long as the deployment does not change that connection. That separation matters if you want CI to ship code without also handing it your domain configuration.
Durable Objects inherit their access from the Worker that implements them. Metadata Read-Only covers their metrics, logs, and traces, but reading or modifying stored data through Data Studio requires Editor.
Errors that name the missing permission
Narrow scopes create a new failure mode: an agent hits a wall and cannot tell why. Cloudflare changed its API errors so that instead of a bare 403, the response links to documentation showing which permissions the request needs. That is a small change with outsized value for autonomous agents, which can otherwise retry blindly or ask for broader access than necessary.
If you are already thinking about how much system access to hand an agent, this connects to a broader question we covered in what it takes to hand an agent the whole system: the more surface area you grant, the more you need a way to bound the blast radius.
Migration and what to watch
The legacy Workers roles still work, and Cloudflare says there is no deprecation date yet, with advance notice promised before any change. The recommendation is to start moving to the new roles because they are the ones that support resource-level scoping.
For teams with several people on the same project, User Groups let you assign a policy once and add members to inherit it, rather than configuring each person individually. Setup is available in the dashboard, the API, or Terraform.
The supplied material does not specify how these roles interact with existing account-level policies in edge cases, so if you have layered permissions today, test the combination before rolling it out broadly. A reasonable first step is to pick one CI workflow or one agent and give it a scoped token, then watch what breaks.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.