Cloudflare Brings Granular Access Control to Workers, Great News for CI Tokens and AI Agents Alike!

Hi everyone, it's Shii-chan! Today I found a nice update to Cloudflare's access controls. It's about being able to hand out just the right amount of access to teammates, CI/CD, and AI agents alike. Let's dive in!

Cloudflare Blog blog.cloudflare.com

What was announced?

Cloudflare's blog announced granular access control for Workers. You can now scope access down to an individual Worker, so teammates, CI/CD tokens, and AI agents can each get exactly the access they need, no more, no less.

The story so far

Until now, you had to pick one of two uncomfortable options: grant broad permissions that hand out more access than intended, or manage a large pile of narrow, individual permissions. Someone you only wanted to give log access to for debugging could end up seeing your source code, and a CI/CD token could end up able to touch every Worker in the account. Following the principle of least privilege was the goal, but hard to actually pull off.

What changes

Four new roles are now available:

• Metadata Read-Only: view metrics, logs, and traces only, with no access to source code
• Content Read-Only: read product content like a Worker's code, but can't change it
• Editor: read and write content and update settings, but can't delete resources
• Admin: full management, including creating and deleting resources

On top of that, you can now choose from three levels of access scope:

• Developer Platform level: access to all resources
• Product level: access to resources within a specific product (e.g. all Workers)
• Resource level: access to a single individual resource (e.g. one specific Worker)

Combining roles and scopes unlocks setups like:

• Give an engineer or an AI agent debugging a Worker Metadata Read-Only access to just that Worker, so they can see settings, metrics, logs, and traces without seeing the source code
• Give someone doing a code review Content Read-Only access, so they can read the code but can't modify or deploy it
• Issue a dedicated API token per CI/CD workflow with the Editor role scoped to a specific Worker, so it can update only that Worker, with no delete permission and no access to other Workers

Dive Deep

You can configure this from the dashboard, the API, or Terraform. From the dashboard, the flow is Manage Account > Members, pick the member, then set their role and scope. If you're granting the same permissions to multiple people, using a user group is recommended.

One thing to watch for: if you want someone to manage routes or custom domains, you need both Editor access to the Worker itself and a separate "Workers Routes" permission on the zone.

Migration from legacy permissions is supported too. For example, "Workers Platform (Read-Only)" maps to "Developer Platform Content Read-Only," and "Workers Scripts Edit" maps to "Editor." Cloudflare recommends moving to the new roles, but the legacy permissions have no set retirement date and keep working as-is.

Looking ahead, Cloudflare plans to extend the same role system to other Developer Platform products like D1, R2, and KV.

Wrap-up

• Granular access control has arrived for Workers
• Combine four roles (Metadata Read-Only / Content Read-Only / Editor / Admin) with three scope levels (Developer Platform / product / resource) to fine-tune permissions
• Debugging engineers, code reviewers, and CI/CD tokens can each get least-privilege access
• Configurable via dashboard, API, or Terraform, with a migration path from legacy permissions
• Available to all customers starting today, with D1, R2, and KV support planned next

If you've been wrestling with how much access to hand your team and your agents, this update is exactly what you needed!