Cloudflare scopes Workers access to one Worker: four roles to hand out instead of the account (2026)

Decision: Audit which credentials can deploy your Cloudflare Workers this week. Since September 15, 2026, Cloudflare lets you attach one of four Workers roles to a single Worker, so a CI pipeline, a coding agent, or a contractor can hold deploy rights on exactly one Worker instead of every Worker in the account. 1

Two jobs still need account-level access. Creating a Worker that does not exist yet, and changing routes or Custom Domains, stay with a product-level grant. 2

The quick read

Aspect	Before September 15, 2026	Current behavior	Action, and when
Scope of a Workers grant	Account level: legacy Workers permissions with write access covered every Worker	Three levels — platform, Workers product (all Workers), and one individual Worker	Re-issue CI and agent credentials at the individual-Worker level. This week 2
Roles available	Legacy account-level permissions, including `Workers Scripts Edit`, `Workers CI Edit`, and `Workers Observability Read`	Four roles — Metadata Read-Only, Content Read-Only, Editor, and Admin — at each level	Map each legacy permission to its replacement role. Before your next grant 2
Deploy credentials	One account-wide token per pipeline	Account-owned API token scoped to Specified Workers, with a role chosen per Worker	Issue one token per Worker or project. This week 3
People and teams	Member and User Group policies at account scope	The same policies, now able to name Individual Workers	Pair wide read access with narrow write access. At your next policy review 2
Creating a Worker	Account-level Admin	Product-level Admin, because a per-Worker grant reaches only Workers that already exist	Keep provisioning on one or two owner-held tokens. Before you hand out any new grant 2
Routes and Custom Domains	Account-level permissions	`Editor` on the Worker plus `Workers Routes Write` for each affected zone; Custom Domains sit outside per-Worker roles	Leave route changes with a product-level holder. Ongoing 2
Legacy permissions	In use	Still working, with no deprecation date announced	Change nothing until Cloudflare names a date 2

What changed at the boundary

Cloudflare's permission model splits into a role, which sets the actions allowed, and a scope, which sets where they apply. Developer Platform scopes come at three levels: the platform (every product), the product (every Worker), and the resource (one Worker). 4

Until this update, Workers permissions were granted at account scope. The legacy permissions Cloudflare is replacing, such as Workers Scripts Edit and Workers CI Edit, were all account-level, which is why the documentation maps each of them onto a replacement role at the Workers product scope. 2 The September 15 change adds the resource level, so a permission policy can name individual Workers. 1

Cloudflare says the controls are available today to all customers, configurable in the dashboard, through the API, or with Terraform. 1 The company's own examples tie a job to a role: Metadata Read-Only for a debugging agent that inspects settings and observability data, Content Read-Only for a code review agent that reads code and changes nothing, and Editor for a CI/CD workflow that deploys.

The four roles, and what each one allows

Role	What it allows	What it stops short of
Metadata Read-Only	Viewing settings, metrics, logs, and traces	Worker code and secret values 2
Content Read-Only	Everything above, plus Worker code and settings	Any modification, including deploys 2
Editor	Reading, updating, deploying, and renaming an existing Worker — script content, settings, schedules, versions, deployments, and observability data	Creating and deleting Workers 2
Admin	Full control at the Workers product scope, including creating and deleting Workers; per-Worker Admin covers a single named Worker	At per-Worker scope, creating Workers and reaching any other Worker 2

The Cloudflare dashboard's Add permission policies form, with the scope set to Individual Workers and the four roles listed under Developer Platform — Choosing the Individual Workers scope narrows a permission policy to the Workers named in the field, and the panel states that these roles grant access only to those Workers. Source: Cloudflare changelog, September 15, 2026.

Where the boundary stops

New Workers need product-level Admin. A per-Worker grant applies to a Worker that already exists, so wrangler deploy for a Worker that does not exist yet requires Admin at the Workers product scope. 2
Custom Domains fall outside per-Worker roles. Adding, updating, or removing routes and Custom Domains needs Editor on the Worker and Workers Routes Write for every affected zone, and per-Worker support for Custom Domains is still on the roadmap. 2
Editor can write secrets. wrangler secret put and wrangler secret delete need Editor on that Worker, so a scoped deploy token can also rotate the credentials the Worker runs with. 2
Durable Objects inherit their Worker's permissions. Cloudflare gives them no roles of their own. A Metadata Read-Only grant on the implementing Worker covers their metrics, logs, and traces, and Data Studio requires at least Editor. The total KV storage metric is the one gap for KV-backed Durable Objects. 5
Workers roles reach Workers. R2 buckets, D1 databases, KV namespaces, Queues, Vectorize, and Hyperdrive keep their own permissions. A deploy that binds them needs only Editor on the Worker, while reading the data inside them needs that product's own grant. 2
API tokens cannot hold platform-level grants. For an automated system, pick the product-level or per-Worker permission the token needs. 4
Pages takes a different route. Members and User Groups use Developer Platform roles for Pages, and tokens use Pages-specific roles. 2

Wiring it up

For a teammate, go to Manage Account > Members, create a permission policy, set the scope to Individual Workers, select the Workers, and choose a role. Assign the same policy to a User Group when a whole team needs it. Members inherit the group's policy, and a person's effective permissions are the union of their own policies and every group they belong to. 6

For CI, agents, and scripts, create an account-owned API token and set its scope to Specified Workers. Account-owned tokens are generally available to all accounts and act as service principals, so a pipeline keeps running after the person who created the token leaves. 3

Wrangler authenticates with an account-owned token and reads that token's permissions, so a token scoped to one Worker limits every Wrangler command to that Worker. 4

export CLOUDFLARE_API_TOKEN="..."
export CLOUDFLARE_ACCOUNT_ID="..."

The shape Cloudflare recommends for mixed access is one broad grant plus narrow writes: Metadata Read-Only at the Workers product scope so someone can browse every Worker and its observability data, paired with Editor only on the Workers they should deploy. 2

An account API token policy scoped to Specified Workers, with Metadata Read-only selected for Individual Workers — *The same four roles apply to an account-owned token, and the Specified Workers scope restricts it to the Workers named in the policy. Source: Cloudflare changelog, September 15, 2026.*

A low-risk rollout

Inventory the credentials that can write to Workers. Start with account-owned API tokens and member or User Group policies carrying Editor or Admin at the account or Workers product scope. 1
Rebuild pipeline tokens at Worker scope. Create a per-Worker Editor token for each pipeline that deploys a single Worker, and prove it on a staging Worker before retiring the wide token. 2 3
Keep provisioning separate. Hold one product-level Admin token for creating Workers and for route and Custom Domain changes, and keep it away from agents. 2
Split reading from writing. Give review and debugging work Metadata Read-Only or Content Read-Only at the Workers product scope, and add Editor per Worker only where changes have to land. 1 4
Settle the secrets policy before granting Editor. A Worker-scoped Editor token can rotate that Worker's secrets, which is worth writing into the token's description. 2
Leave the legacy permissions in place for now. They keep working with no deprecation date announced, so migrate each policy the next time you touch it. 2

Verdict: scope the tokens now, migrate nothing

This change lives in your account's access model. Your code and your deployments stay as they are. 1 4

Adopt it now when your account holds more than one Worker and some token, agent, or contractor reaches all of them. A per-Worker grant is strictly smaller than the account-wide one it replaces, and creating it costs nothing. 1 2

Watch two edges. Pipelines that update Custom Domains still need Editor plus Workers Routes Write on each zone, and a credential that also reads R2, D1, or KV data needs those products' permissions as well. 2 4

Skip it when you run a single Worker with one deployer and one token, where per-Worker scope restates what account scope already gave you. 2

References

1
Grant teammates and agents access to specific Workers
developers.cloudflare.com
2
Workers roles and permissions
developers.cloudflare.com
3
Account API tokens
developers.cloudflare.com
4
Roles and permissions
developers.cloudflare.com
5
Durable Objects roles and permissions
developers.cloudflare.com
6
User Groups
developers.cloudflare.com

Two jobs still need account-level access. Creating a Worker that does not exist yet, and changing routes or Custom Domains, stay with a product-level grant. 2

The quick read

Aspect	Before September 15, 2026	Current behavior	Action, and when
Scope of a Workers grant	Account level: legacy Workers permissions with write access covered every Worker	Three levels — platform, Workers product (all Workers), and one individual Worker	Re-issue CI and agent credentials at the individual-Worker level. This week 2
Roles available	Legacy account-level permissions, including `Workers Scripts Edit`, `Workers CI Edit`, and `Workers Observability Read`	Four roles — Metadata Read-Only, Content Read-Only, Editor, and Admin — at each level	Map each legacy permission to its replacement role. Before your next grant 2
Deploy credentials	One account-wide token per pipeline	Account-owned API token scoped to Specified Workers, with a role chosen per Worker	Issue one token per Worker or project. This week 3
People and teams	Member and User Group policies at account scope	The same policies, now able to name Individual Workers	Pair wide read access with narrow write access. At your next policy review 2
Creating a Worker	Account-level Admin	Product-level Admin, because a per-Worker grant reaches only Workers that already exist	Keep provisioning on one or two owner-held tokens. Before you hand out any new grant 2
Routes and Custom Domains	Account-level permissions	`Editor` on the Worker plus `Workers Routes Write` for each affected zone; Custom Domains sit outside per-Worker roles	Leave route changes with a product-level holder. Ongoing 2
Legacy permissions	In use	Still working, with no deprecation date announced	Change nothing until Cloudflare names a date 2

What changed at the boundary

The four roles, and what each one allows

Role	What it allows	What it stops short of
Metadata Read-Only	Viewing settings, metrics, logs, and traces	Worker code and secret values 2
Content Read-Only	Everything above, plus Worker code and settings	Any modification, including deploys 2
Editor	Reading, updating, deploying, and renaming an existing Worker — script content, settings, schedules, versions, deployments, and observability data	Creating and deleting Workers 2
Admin	Full control at the Workers product scope, including creating and deleting Workers; per-Worker Admin covers a single named Worker	At per-Worker scope, creating Workers and reaching any other Worker 2

Where the boundary stops

New Workers need product-level Admin. A per-Worker grant applies to a Worker that already exists, so wrangler deploy for a Worker that does not exist yet requires Admin at the Workers product scope. 2
Custom Domains fall outside per-Worker roles. Adding, updating, or removing routes and Custom Domains needs Editor on the Worker and Workers Routes Write for every affected zone, and per-Worker support for Custom Domains is still on the roadmap. 2
Editor can write secrets. wrangler secret put and wrangler secret delete need Editor on that Worker, so a scoped deploy token can also rotate the credentials the Worker runs with. 2
Durable Objects inherit their Worker's permissions. Cloudflare gives them no roles of their own. A Metadata Read-Only grant on the implementing Worker covers their metrics, logs, and traces, and Data Studio requires at least Editor. The total KV storage metric is the one gap for KV-backed Durable Objects. 5
Workers roles reach Workers. R2 buckets, D1 databases, KV namespaces, Queues, Vectorize, and Hyperdrive keep their own permissions. A deploy that binds them needs only Editor on the Worker, while reading the data inside them needs that product's own grant. 2
API tokens cannot hold platform-level grants. For an automated system, pick the product-level or per-Worker permission the token needs. 4
Pages takes a different route. Members and User Groups use Developer Platform roles for Pages, and tokens use Pages-specific roles. 2

Wiring it up

Wrangler authenticates with an account-owned token and reads that token's permissions, so a token scoped to one Worker limits every Wrangler command to that Worker. 4

export CLOUDFLARE_API_TOKEN="..."
export CLOUDFLARE_ACCOUNT_ID="..."

A low-risk rollout

Inventory the credentials that can write to Workers. Start with account-owned API tokens and member or User Group policies carrying Editor or Admin at the account or Workers product scope. 1
Rebuild pipeline tokens at Worker scope. Create a per-Worker Editor token for each pipeline that deploys a single Worker, and prove it on a staging Worker before retiring the wide token. 2 3
Keep provisioning separate. Hold one product-level Admin token for creating Workers and for route and Custom Domain changes, and keep it away from agents. 2
Split reading from writing. Give review and debugging work Metadata Read-Only or Content Read-Only at the Workers product scope, and add Editor per Worker only where changes have to land. 1 4
Settle the secrets policy before granting Editor. A Worker-scoped Editor token can rotate that Worker's secrets, which is worth writing into the token's description. 2
Leave the legacy permissions in place for now. They keep working with no deprecation date announced, so migrate each policy the next time you touch it. 2

Verdict: scope the tokens now, migrate nothing

This change lives in your account's access model. Your code and your deployments stay as they are. 1 4

Skip it when you run a single Worker with one deployer and one token, where per-Worker scope restates what account scope already gave you. 2

References

1
Grant teammates and agents access to specific Workers
developers.cloudflare.com
2
Workers roles and permissions
developers.cloudflare.com
3
Account API tokens
developers.cloudflare.com
4
Roles and permissions
developers.cloudflare.com
5
Durable Objects roles and permissions
developers.cloudflare.com
6
User Groups
developers.cloudflare.com

Cloudflare scopes Workers access to one Worker: four roles to hand out instead of the account

The quick read

What changed at the boundary

The four roles, and what each one allows

Where the boundary stops

Wiring it up

A low-risk rollout

Verdict: scope the tokens now, migrate nothing

References

Related content

Cloudflare scopes Workers access to one Worker: four roles to hand out instead of the account

The quick read

What changed at the boundary

The four roles, and what each one allows

Where the boundary stops

Wiring it up

A low-risk rollout

Verdict: scope the tokens now, migrate nothing

References

Related content