What happened

Cloudflare added four new access roles for Workers, its platform for running app code without managing a server yourself, the kind of setup a coding agent often reaches for by default when it deploys something on your behalf. 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, the old default was an all-or-nothing token covering your entire account. If that token leaked, ended up logged somewhere it shouldn’t, or the agent simply sent the wrong request by mistake, the damage could reach every app in your account, not just the one you meant to hand over.

Scoped roles shrink that exposure. A token scoped to Content Read-Only on one Worker can’t touch any of your other apps, and can’t change even the one it’s scoped to.

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.

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.

Then run the actual test, not just the setup. Try the new scoped token or account against a different Worker in your account, one it shouldn’t be able to touch. If the request still goes through, the scope isn’t doing what you think it is, and it’s worth fixing before an agent finds that gap for you.

End of article