Cloudflare Workers now lets teams and AI agents be limited to a single app, with four new access roles

What Cloudflare announced

On September 15, 2026, Cloudflare published a post on its official blog, written by Dina Kozlov, Anthony Oreglia and Visal In, announcing finer-grained access control for Workers. A Worker is an application that a developer runs on Cloudflare's Developer Platform. Cloudflare says a teammate or AI agent (software that carries out tasks on its own) can now be given access to one specific Worker. They can then change that application but no other resources in the account.

Cloudflare explained the motivation in the post: "the last thing you want is for an agent to make a change in production, just because it was granted more access than it needs." "Production" means the live version of an application that real users rely on.

Read the full description

Sources are collected, independently checked, then reviewed by Jev.

According to Cloudflare, the new roles are available to all customers from the day of the announcement. Roles can be assigned to a specific user, so that when that person logs in to the Cloudflare dashboard they see only the Worker they have been given access to. Alternatively, you can create an API token, a kind of access key that software uses instead of a login. That token can be limited to one Worker and handed to an agent.

The four new roles compared

Some terms in the table: observability data means the records that show how an application is running, such as performance metrics, logs of events and traces of individual requests. CI/CD refers to automated systems that build and deploy (publish) new versions of code. D1 is Cloudflare's database product.

Permission scope: three levels

Cloudflare says each role can be applied at one of three scopes. The Developer Platform level covers all Developer Platform resources. The product level covers every resource of one product, for example all Workers. The resource level covers one specific resource, for example a single Worker. The role decides what someone can do; the scope decides which resources they can do it to.

Cloudflare says it designed the roles to strike a balance. Roles that are too broad force you to grant more access than intended. That undermines the principle of least privilege: give each person or tool only the access it needs. On the other hand, too many individual permissions make it hard to know which ones to grant.

Practical impact for teams

For development teams using Cloudflare Workers, the main benefit is limiting the damage when something goes wrong, such as a misconfigured tool or a leaked access key. Cloudflare says it is now possible to give an automation tool or AI agent a specific role on a single Worker, rather than broader access.

• Debugging: According to Cloudflare, Metadata Read-Only lets people or agents view metrics, logs and traces without seeing source code.
• Code review: According to Cloudflare, Content Read-Only lets reviewers or review agents read code but not modify or deploy it.
• Automated deployment: Cloudflare says a CI/CD system can use an Editor token scoped to a single Worker. Even if it is misconfigured or the token leaks, the token can only deploy changes to that Worker; it cannot delete the Worker or touch other applications.
• Full management: Admin is the highest level of access and can delete the application, but Cloudflare says it can still be limited to a single Worker.

Rules for routes, custom domains and Durable Objects

A route or Custom Domain tells Cloudflare which web addresses send traffic to a Worker. Cloudflare says changing one could redirect live traffic or take the application offline, so access to the Worker alone is not enough. To add, change or remove a route or Custom Domain, you need two things. The first is Editor permission on that Worker. The second is the Workers Routes permission for the zone, which is Cloudflare's term for a domain in your account. Cloudflare says the Workers Routes permission lets someone manage how traffic reaches a Worker without being able to change unrelated settings for the domain.

However, according to Cloudflare, once a route is set up, you can keep deploying new versions of the Worker without access to the connected zone or resource. This works as long as the deployment does not change that connection. As a result, a CI/CD system does not also need access to your domains, databases or storage.

Durable Objects are components that a Worker uses to store data. Cloudflare says they have no roles or permissions of their own; access to them is decided by your access to the Worker that implements them. Metadata Read-Only shows a Durable Object's metrics, logs and traces but not the data stored in it. Using Durable Objects Data Studio requires the Editor role, because that tool can read and change the stored data directly.

What comes next

Cloudflare says it plans to bring the same roles to other Developer Platform products, including D1 (databases), R2 (file storage buckets) and KV (key-value storage). It says it will keep the same separation, so someone could see settings and observability data without seeing the stored content. Cloudflare did not give a rollout timeline in the post.

Browse the latest news in this topic

• Tech news