Correction, October 13, 2026: Earlier Worker permissions already distinguished read and edit access. The new roles add resource-level scope. Changing a route or custom domain also requires zone-level Workers Routes permission.

What happened

Cloudflare added four new access roles for Workers, its platform for running app code without managing a server yourself, a hosting option for apps built with coding agents. Before this, giving someone, or an agent, access to a single Worker usually meant granting broader access to your whole account along with it.

Now you can scope access to one Worker at a time. Cloudflare named four roles:

  • Metadata Read-Only: view a Worker’s settings and observability data, like metrics, logs, and traces (records of what a running app did and when), without seeing its actual code. Useful for debugging without exposing your source.
  • Content Read-Only: read a Worker’s code without being able to change it. Useful for code review.
  • Editor: read and write a Worker’s code and settings, but can’t create new Workers or delete existing ones. Cloudflare built this one for CI/CD (continuous integration/continuous deployment, the automated process that pushes code changes live) pipelines.
  • Admin: full control, including creating, renaming, and deleting the Worker, and managing who else has access to it. Reserve this for cases where someone genuinely needs the power to delete something.

You can hand these out two ways. Assign a role to a specific teammate under Manage Account > Members in the dashboard, so they only see the one Worker you gave them when they log in. Or create an API token, a credential a script or agent uses to authenticate instead of typing a password, scoped to just one Worker and one role, and hand that token to your agent instead of a broader one.

Why it matters

Cloudflare states the problem plainly: “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.” That’s the real failure mode here. If you’ve already handed an API token to a coding agent so it can deploy or check on a Worker, older Worker permissions could cover more Workers than the task needed, although separate read and edit permissions already existed. If a broadly scoped token leaked or an agent made a mistaken request, other Workers within its scope could be affected.

Scoped roles shrink that exposure. With only Content Read-Only access to one Worker, a token can read that Worker’s code but cannot deploy changes or access other Workers.

Who should care

This matters if you already deploy on Cloudflare Workers and have given, or plan to give, an API token to an agent so it can deploy code, check logs, or review a Worker without you in the loop. It also matters if more than one person touches your Cloudflare account and everyone has been getting the same broad access by default because scoping felt like extra setup.

It matters less if you’re a solo builder with one Worker and no agent holding a standing credential to your account. There’s less at stake when there’s only one app and one person with access to begin with.

What builders should do next

If you’ve already given an agent or a teammate a Cloudflare API token or account role, check what it’s actually scoped to instead of assuming it’s fine. Open the token or the person’s access and see whether it covers your whole account or more Workers than they actually use. If it does, replace it with access scoped to just the Worker they need, using the least-powerful role that still works: Content Read-Only if they only review code, Editor if they need to deploy changes, and Admin reserved for a human who might need to delete something.

If deployment changes a route or custom domain, it also needs Workers Routes permission for that zone. Deploying a new version through an existing unchanged connection does not require that additional access.

For teammates specifically, that fix lives under Manage Account > Members: open the person’s access and swap any account-wide role for one scoped to just their Worker.

Test with two disposable Workers that have no real data or production bindings. Scope the test token to one. Make the same harmless read operation permitted by its role against both Workers.

The authorized read should succeed and the other should be denied. Do not use a production edit or deletion as the probe. If the unauthorized read succeeds, fix the scope before handing that token to an agent.

End of article