Cloudflare now lets you assign permissions at the individual Worker level, offering four distinct roles that can be applied through the dashboard, API, or Terraform. This change gives engineering teams the ability to enforce least‑privilege access for debugging agents, code reviewers, CI/CD pipelines, and teammates, reducing the risk of accidental or malicious modifications.
New per‑Worker permission model
Permissions are no longer limited to account‑wide or product‑wide scopes. You can select a specific Worker and attach a role that defines exactly what actions the principal can perform on that Worker. The same model works across all Developer Platform products that use Workers.
Roles and their practical use
- Metadata Read‑Only: Allows viewing settings, metrics, logs, and traces. Ideal for debugging agents that need observability data without seeing source code.
- Content Read‑Only: Grants read access to the Worker’s code, settings, and observability data. Suitable for code‑review bots that must inspect code but not modify it.
- Editor: Permits updating and deploying the Worker while preventing deletion. Designed for CI/CD workflows that need to push new versions safely.
- Admin: Includes all Editor capabilities plus the ability to delete the Worker. Use sparingly for trusted operators who require full lifecycle control.
Applying policies via dashboard, API, or Terraform
In the Cloudflare dashboard, navigate to Manage Account → Members, pick a member, and create a permission policy scoped to Individual Workers. Select the target Workers and assign the appropriate role. For larger teams, attach the same policy to a User Group so every group member inherits the permissions automatically. The same configuration can be expressed in API calls or Terraform resources, enabling version‑controlled IAM definitions.
Implications for architecture, operations, and security
Granular Worker permissions enable a tighter separation of duties. AI engineers can expose only the metadata needed for model monitoring, while cloud platform engineers can restrict deployment rights to CI pipelines without granting delete privileges. SREs gain the ability to grant read‑only observability to alerting agents, reducing the attack surface. Security engineers can audit role assignments per Worker and ensure that any token used by automation is scoped to the minimal set of Workers required.
Durable Objects inherit the permissions of the Worker that implements them, meaning that controlling access to a Worker automatically governs access to its associated Objects. This inheritance simplifies policy management but also requires careful selection of Worker roles when Objects contain sensitive state.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Review existing Worker access patterns and map them to the new role set. Create User Groups for common role‑to‑Worker combinations to avoid per‑member policy drift. When automating deployments, generate scoped API tokens that reference only the Workers they need to update. Finally, incorporate permission‑policy checks into your CI/CD validation steps to catch over‑privileged assignments before they reach production.