Give every teammate and agent the right level of access to your Workers

Cloudflare has introduced Worker-level access controls, allowing account owners to grant a teammate or an agent access to a single Worker rather than every resource in the account. The feature arrives alongside four new roles that define what a scoped identity can actually do. All of it is available today for all customers.

Policies can be attached to a user — who will then see only the permitted Worker when they log into the dashboard — or baked into an API token handed to an agent, so the agent's reach stops at that one application. Tokens with per-Worker permissions can be created through the API:

Administrators can also configure the same controls in the dashboard or via Terraform. To grant a team member a single Worker, go to Manage Account > Members, pick the member, and create a policy with the required role and Worker scope. Where several people need identical permissions, a User Group can carry the policy instead; members added to the group inherit it automatically.

The four roles and the three scopes

The role set was chosen to avoid two failure modes: roles so broad they force over-provisioning, and permission lists so long nobody knows which entries to pick. The resulting levels map to common intents — debug a resource without reading its contents, read contents without changing them, change a resource without being able to delete it, and fully manage it.

Each role applies at one of three scopes. Taking metadata read-only as the example:

• Developer Platform level: metadata for all Developer Platform resources.
• Product level: metadata for every resource of one product, such as every Worker.
• Resource level: metadata for one specific resource, such as one Worker.

Investigating an issue without seeing code

Troubleshooting a Worker calls for its settings, metrics, logs, and traces — not its source. Metadata Read-Only covers exactly that surface: analytics via the GraphQL API, logs, traces, and other observability data, with responses limited to the Workers the caller can access. An agent scoped to a single Worker can therefore investigate through the Cloudflare APIs without any visibility into other Workers in the account. Cloudflare intends to preserve this separation as the roles reach other products, so settings and observability for a D1 database or R2 bucket can be inspected without reading the database values or bucket files.

Reviewing code without deploying it

A reviewer or review agent may need to read what is running in a Worker without gaining the ability to modify settings or ship a new version. Content Read-Only draws that line: code can be retrieved and reviewed, not changed or deployed, and scoping to a single Worker limits reads to that Worker's code. The same behavior is planned for other Developer Platform products, letting someone read data in a D1 database, KV namespace, or R2 bucket without write access.

Confining CI/CD to one application

A deployment pipeline needs access only to what it deploys — it should not be able to alter another Worker or delete its own and take the application down. Giving each workflow its own API token with the Editor role scoped to one Worker contains the blast radius of a misconfiguration or a leaked token: deploys succeed, deletion and cross-application changes do not.

Deleting an application

Admin is the top level of access and the only one that permits deleting an application. It too can be scoped to a single Worker so that it does not extend across the account.

Routing needs more than Worker access

Routes and Custom Domains determine which hostnames reach a Worker — a Wrangler configuration entry pointing example.com at a Worker is a typical case:

{
  "route": {
    "pattern": "example.com/*",
    "zone_name": "example.com"
  }
}

Because a change there can redirect production traffic or take an application offline, Worker access by itself is insufficient. Adding, changing, or removing a route or Custom Domain requires both Editor access to the Worker and Workers Routes permission on the zone. Scoping to Workers Routes rather than broader zone access lets someone control how traffic reaches a Worker without touching unrelated domain settings.

Once a route exists, subsequent versions of the Worker can be deployed without any access to the connected zone or resource, provided the deployment leaves that connection unchanged. CI/CD can thus ship the application without also holding your domains, databases, or storage.

Durable Objects follow the Worker

Durable Objects have no roles or permissions of their own; access is conferred by access to the implementing Worker. Grant the appropriate role on that Worker and the Durable Object follows. Metadata Read-Only exposes Durable Object metrics, logs, and traces but not the data stored in the object. Because Durable Objects Data Studio can query and modify that data directly, opening it requires Editor.

403s that name the missing permission

Narrow scoping guarantees that users and agents will eventually attempt something they lack rights for, and a generic 403 Forbidden leaves them stuck. The APIs now return a link to the relevant API documentation in that response, showing precisely which permissions the request requires. Caller and agent can then request or supply the correct level of access instead of escalating to something broader.

Legacy roles and what comes next

Worker access was previously governed by an older set of roles and permissions. Those assignments continue to work — there is no deprecation date, and advance notice is promised before one — but the new roles are the ones that carry granular, resource-level scoping, so migration is recommended.

Worker-level access is the first step toward one authorization model spanning the Developer Platform. The same four roles and their scopes will apply as resource-level controls arrive for more products, including KV namespaces and D1 databases, so an account can hand out access to the specific bucket or database needed rather than to all of them. Setup details are in the developer docs.