Summary: Cloudflare published Worker-level access controls on September 15, 2026 so teammates and agents can be scoped to a single Worker rather than an account. Four roles cover metadata reads, content reads, deployment, and administration, and all customers can use them today. Routes and Custom Domains still require separate Workers Routes permission in addition to Worker Editor access.
Account-wide tokens hand out more reach than anyone needs
Hand an agent an API token today and it usually carries the same reach as the account that issued it. A coding agent debugging one Worker can therefore read every other Worker’s source, and a CI workflow that only needs to deploy a single app is able to delete another. Cloudflare’s new Worker-level access controls, published September 15, 2026, go straight at that gap: a teammate or an agent can now be scoped to one Worker instead of the whole account.
Four roles, applied at three scopes
Four roles now exist for Workers, and all customers can use them as of today. Metadata Read-Only lets someone inspect settings, metrics, logs, and traces without ever seeing source code. Content Read-Only permits reading that code but neither deploying nor changing settings. Editor allows deploys while withholding deletion. Admin sits at the top and can delete an application.
Every role can be applied at three scopes: the whole Developer Platform, a single product such as Workers, or one specific resource. A code review agent, for instance, can hold Content Read-Only on a single Worker and see nothing else in the account. Cloudflare says it intends to reuse these same roles as resource-level controls reach D1, R2, and KV.
What changes for agent and CI tokens
Containment is the practical payoff. A CI/CD workflow can carry its own Editor token scoped to one Worker, so a misconfigured pipeline or a leaked token can deploy that app yet neither delete it nor touch anything else. Agents follow the same logic: scoped to a single Worker, an agent can query analytics and logs through the GraphQL API without pulling data from other Workers.
One wrinkle deserves some planning. Routes and Custom Domains are not covered by Worker access alone. Adding, changing, or removing a route calls for Editor access to the Worker plus Workers Routes permission on the zone. After a route is configured, though, new versions keep deploying without zone access, provided the deployment leaves that connection alone. That separation matters whenever CI is to ship code without also being handed your domain configuration.
Durable Objects inherit their access from the Worker implementing them. Their metrics, logs, and traces fall under Metadata Read-Only, yet reading or modifying stored data through Data Studio requires Editor.
API errors that name the missing permission
Narrow scopes bring a failure mode of their own: an agent runs into a wall with no way to tell why. Cloudflare reworked its API errors so that a request lacking permission receives a response linking to documentation showing which permissions it needs, rather than a bare 403. For autonomous agents that small change carries outsized value — without it they either retry blindly or ask for broader access than the job requires.
If how much system access to hand an agent is already on your mind, this ties into a wider 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 keep an eye on
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 one project, User Groups let you assign a policy once and add members who inherit it, rather than configuring each person individually. Setup is available in the dashboard, the API, or Terraform.
How these roles behave alongside existing account-level policies in edge cases is not specified in the supplied material, so if you run 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.