AI NewsInfrastructureAnnouncement
Cloudflare added per-Worker roles so an agent can access one app only
Cloudflare Workers can now be scoped with four new roles, from Metadata Read-Only up to Admin, so a teammate, a CI job, or an AI agent gets access to one Worker rather than every Worker on the account.

Image: Cloudflare
Why it mattersA leaked CI token or a compromised agent that used to reach every Worker on the account can now be limited to one, which is the difference between a small problem and an urgent incident that reaches production.
Cloudflare released 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 model 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 names 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 deploys 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 case is stronger when the actor is a coding agent, because a coding agent will not stop to ask whether its current task is what the token is for. Judging by Cloudflare's own docs and examples, that is who a lot of these tokens now belong to: a program that runs tasks in a loop, holds an API key, and calls whichever endpoint the current prompt tells it to.
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 gets in, the most it can do is read a metrics endpoint, and it cannot deploy to production.
What is still missing
Cloudflare says the same role model 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 uneven control across the rest of the Developer Platform for now.
Source
Source: Cloudflare, 15 September 2026.
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.


