Cloudflare adds per-Worker access roles so a CI token or an agent can be scoped to one app instead of the whole account

Cloudflare rolled out per-Worker access control today, replacing the older account-wide model where a token that could deploy any Worker could also deploy every Worker. The four new roles are scoped to individual Workers, and Cloudflare says the same shape will extend to D1, R2 and KV later.

The four roles

Metadata Read-Only is the lowest, and it grants access to observability data such as metrics, logs and traces without letting the token read source code. Content Read-Only lets the token read the Worker's code but not change it. Editor can read and write content, and update settings, but cannot delete the Worker. Admin is full control, including creation, deletion and access management.

Cloudflare specifically calls out CI tokens and AI agents as reasons for the split. An agent asked to check whether a deploy is healthy needs Metadata Read-Only and nothing else. A CI job that ships a specific Worker needs Editor on that Worker. Neither has ever had a reason for the current default, which was an API token that could operate on any Worker on the account.

Where the permissions live

Site owners assign the roles through the dashboard, the API, or Terraform. Cloudflare says the feature is available today for all customers, and that policies can be assigned to individual members or to User Groups for teams that need identical access. The older Workers-specific permission structures are being replaced by these roles rather than layered on top of them.

Why this matters when the token is a model

The pitch is straightforward when the actor is a person. A newcomer to a team should not have delete access on production the day they join. The pitch is sharper when the actor is a coding agent, because a coding agent will not stop to ask whether the task in front of it is what the token is for. If Cloudflare's own docs and examples are anything to judge by, that is who a lot of these tokens now belong to: a task-running loop that is holding an API key and reaching whichever endpoint the current prompt points it at.

The Metadata Read-Only role is the one that changes the most about how a monitoring agent runs. An agent that only needs to answer "is this Worker healthy" no longer has to hold a token that could also rewrite the Worker's code. If a prompt injection or a compromised dependency lands, the blast radius is a read on a metrics endpoint, not a deploy to production.

What is still missing

Cloudflare says the same role shape will reach D1 databases, R2 buckets and KV namespaces, and until then a token that reads a Worker's metrics may still hold broader access on the data those Workers read. A team designing scoped agent access on Cloudflare gets clean Workers scoping today and a mixed picture across the rest of the Developer Platform for now.

Source

Source: Cloudflare, 15 September 2026.