Cloudflare Limits What a Client's Deploy Agent Can Change

Cloudflare's four Worker roles turn one shared deployment credential into a per-client boundary. Since September 15, 2026, an agency can let a client CI job deploy one existing Worker without also giving it deletion rights or access to every other Worker on the account, as long as no broader policy widens that access.

The useful change is the scope

A permission has two parts. The role says what someone can do. The scope says where they can do it.

Cloudflare now lets you combine a Worker role with an individual Worker scope for a teammate, User Group, agent, or API token. The same role can still cover every Worker, but it no longer has to.

That sounds like a small admin feature. For a studio or agency carrying several clients inside one Cloudflare account, it changes the handoff. The deployment credential for Client A can stop at Client A's Worker.

The September 15 release is available to all customers and works through the dashboard, API, or Terraform.

Here is the whole role set from the Workers role reference:

The split is useful because debugging, reviewing code, shipping code, and deleting the service are four different jobs. They shouldn't all inherit the same credential.

Cloudflare's older Workers permissions were account-level. The replacement model can be applied across the Developer Platform, across all Workers, or to one existing Worker. A product-level Workers policy covers every current and future Worker. A per-Worker policy covers only the Workers you select.

There is one structural limit: you can't scope access to a Worker that does not exist yet. Creating a new Worker still needs product-level Admin.

What changes for a client handoff

Take a small agency that hosts one Worker for each client. Its deployment workflow needs to publish new versions of client-a-api. It does not need to create Workers, delete that Worker, or touch client-b-checkout.

Before this release, the common Workers CI permissions Cloudflare now labels as legacy were account-level. That left two clean options: accept a broad credential or separate the client into another account. Individual Worker scope adds a third option. Keep the account layout, but give the deploy token Editor on client-a-api only.

The subscription math does not change because Worker-level controls are available to all customers. The operating math does.

That model leaves out an important trade. Twelve scoped client credentials are more secrets to issue, store, and rotate than one shared token. The win is not fewer credentials. It is a smaller set of projects to investigate when one credential fails or leaks.

A solo founder with one Worker and no shared deployment access will not feel much change. Neither will a team that intentionally gives its platform group control over every Worker. This matters when several people, clients, or automated jobs share one Cloudflare account but should not share one blast radius.

Give one client deploy job enough access

The clean first handoff is an existing Worker with a stable Route or Custom Domain. That removes Worker creation and domain changes from the deployment job.

1. 1

   Write down the job before choosing the role

   Start with one sentence: “This workflow deploys new versions of the existing client-a-api Worker.”

   That sentence points to Editor at the individual Worker scope. If the job must create a new Worker, it needs product-level Admin. If it must add, change, or remove a Route or Custom Domain, it also needs Workers Routes Write for each affected zone.

2. 2

   Create an account-owned API token

   In Cloudflare, go to Manage Account > Account API Tokens and create an account-owned token. Set its scope to Specified Workers, choose client-a-api, then choose Editor.

   Use an account-owned token for the workflow, not a person's user token. Cloudflare positions account-owned tokens as service principals for durable integrations, so the deployment does not stop when the person who created it leaves. Creating or updating one requires Super Administrator permission.

3. 3

   Run Wrangler with that token

   Store the token in the deployment system's secret store. Cloudflare documents these environment variables for Wrangler:

   export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
   export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"
   npx wrangler deploy

   Run this from the configured project for the existing Worker. wrangler login is not a substitute here because its OAuth flow does not currently support granular authorization.

4. 4

   Cut over, then remove the broad path

   Deploy a harmless version through the new token and confirm the intended Worker updates. Check the token has no product-level Workers role and no unrelated resource scope.

   Then remove the old broad deployment secret from that workflow. Keeping both credentials during the test is sensible. Keeping both after the test defeats the boundary.

That is the complete handoff for a routine deployment. The client job can update, upload, deploy, roll back, rename, and manage secrets for that Worker because those actions sit inside Editor. It cannot delete the Worker, and the per-Worker policy does not grant access to other Workers.

Four jobs, four sensible policies

A support agent that only needs evidence

Give a debugging agent Metadata Read-Only on the affected Worker. It can inspect settings, metrics, logs, and traces without reading the source or changing the service.

The payoff is a support workflow that can collect evidence without quietly becoming a code-review or deployment workflow. The same role is enough for wrangler tail on that Worker.

An outside developer reviewing a client build

Give a contractor Content Read-Only on the client's Worker. They can inspect the deployed source and settings, but they cannot modify or deploy it.

The payoff is a cleaner review boundary. You do not need to grant Editor merely because the reviewer needs to understand what is running.

A client-specific CI pipeline

Give the account-owned token Editor on one existing Worker. It can publish and roll back versions without deleting the Worker or reaching other Workers.

This is the strongest fit for an agency handoff because the credential belongs to the workflow, not to a staff member. If you also run browser agents for client work, Cloudflare's approved-host controls solve a different half of the boundary: where the browser may go. This release controls which Worker the deployment identity may change.

A platform owner who handles lifecycle changes

Reserve Admin for the teammate or automation that truly needs deletion rights. Keep product-level Admin with the owner who creates Workers, then hand the finished Worker to the narrower day-to-day policies.

The payoff is a visible split between lifecycle work and routine delivery. A deploy job does not need the same authority as the person who creates and retires client services.

The boundary is narrower, not complete isolation

The headline benefit is real, but “one Worker only” can become a dangerous oversimplification.

Durable Objects need the same care. They do not have independent roles or scopes. They inherit access from the Worker that implements them. Metadata Read-Only includes Durable Object metrics, logs, and traces without stored-data access, but Editor also meets the documented threshold for using Data Studio to query or modify data in a SQLite-backed Durable Object.

Routes are another separate boundary. Editor is enough to deploy a new version when an existing Route or Custom Domain stays unchanged. Changing that connection also requires Workers Routes Write for every affected zone. Cloudflare also says Custom Domains do not currently support per-Worker roles.

Finally, Cloudflare permissions add together. A narrow direct policy does not cancel a broad policy inherited through a User Group. The Members view shows direct permissions, while inherited group policies must be checked in the Groups tab. If you skip that check, the screen may show the narrow policy you wanted while the effective permission set stays wide.

Who should act now

Act this week if one account holds several client Workers and any person, agent, or CI job still carries an all-Workers permission for a one-Worker job. The benefit is clearest when the Worker already exists and its domain connections do not change during routine deploys.

Wait before tightening the token if the workflow creates Workers, changes Routes or Custom Domains, or relies on direct access to bound data products. Map those actions first or the next deploy will fail halfway through.

You are unaffected if you never share Worker access, operate only one Worker, or intentionally keep deployment under a platform team with account-wide responsibility.

The Monday move

Change the permission policy behind one existing client's CI deployment first. Set an account-owned token to Editor, scope it to that one Worker, list every binding and inherited Durable Object it can affect, check direct and group policies, then deploy without changing the Route or Custom Domain.

Once that run passes, remove the old all-Workers secret. That single cutover gives you a real boundary and a pattern you can repeat for the next client.

If you want more plain-English operating notes on platform changes, join the newsletter.