Cloudflare split Workers access into roles and scopes instead of one big permission list

As more teams and autonomous coding agents began deploying directly to Cloudflare's Developer Platform, the existing permission model forced an uncomfortable choice: grant broad, account-wide roles that let an agent touch every Worker, database, and bucket in the account, or hand-build enough individual permissions to cover every case — which becomes unmanageable as the number of resources and actions grows.

Cloudflare's fix was to stop treating access as one flat list and instead define two independent dimensions. Four roles — Metadata Read-Only, Content Read-Only, Editor, and Admin — describe capability levels, from viewing logs and metrics without seeing code, to reading code without editing it, to editing without deleting, to full control. Separately, each role can be applied at one of three scopes: every resource on the Developer Platform, every resource of one product (all Workers), or a single named resource (one specific Worker).

The two axes compose independently. A CI/CD pipeline can get the Editor role scoped to exactly the one Worker it deploys, so a leaked token can update that Worker but cannot delete it or touch any other application. A debugging agent can get Metadata Read-Only scoped to one Worker, so it can inspect logs and traces without ever reading the source code. Cloudflare designed the same two roles-times-scopes structure to extend later to other Developer Platform resources like D1 databases and R2 buckets, rather than inventing new permissions for each product.

Separate 'what you can do' (role) from 'where you can do it' (scope) as two independent axes

Crossing four roles with three scopes produces twelve precise access levels from a small, fixed vocabulary, instead of a combinatorial explosion of one-off permissions per resource.

Scoping to a single resource (one Worker) means a compromised or misconfigured agent token has contained blast radius — it cannot see or touch any other resource in the account.

The same role/scope structure was built to extend to other products (D1, R2, KV) without redesigning the model each time.

Durable Objects inherit access from their parent Worker's role rather than needing their own permission system, keeping the model from fragmenting further.

When access needs multiply with more agents, don't add more individual permissions — split access control into two orthogonal axes, capability and scope, that compose instead of multiplying.

Cloudflare also added contextual 403 error responses that link directly to the documentation describing which permission is missing, so an agent or developer that hits a permission wall can self-correct instead of getting stuck on a generic 'Forbidden' response. The company said it plans to extend the same role-and-scope model to D1 databases, R2 buckets, and KV namespaces next.