Cloudflare announced the availability of access controls for each Worker, allowing a user, software agent, or API token to interact with a specific application without accessing the rest of the resources in the account. The move comes with four new roles for the developer platform, designed to separate application monitoring, content reading, modification, and full administration.
The controls are available to all customers as of September 15, 2026, and can be configured through the Cloudflare dashboard, API, or Terraform. They can also be applied to an individual user or a User Group, with all group members inheriting the same policy.
Four Permission Levels
- Metadata Read-Only: Allows viewing resource lists, settings, and monitoring data, such as metrics, logs, and traces, without access to product content or code. It is suitable for investigating outages when reading the source is not required.
- Content Read-Only: Allows reading product content, such as Worker code or D1 database content, without modifying or deploying changes.
- Editor: Allows reading and writing content and updating settings, but does not permit creating or deleting resources. Cloudflare presents it as a suitable option for CI/CD systems that need to deploy changes to a specific Worker.
- Admin: Grants full control over the resource, including creating, renaming, deleting, and granting access to other users, with the ability to limit this permission to a single Worker rather than the entire account.
What Changes in Practice?
An operations team can grant an engineer or agent the Metadata Read-Only permission to inspect settings, metrics, logs, and traces without exposing the code. Similarly, a code-review agent can use Content Read-Only without having the ability to deploy it or change application settings.
For CI/CD pipelines, an API token can be created with the Editor role and restricted to a single Worker. If the pipeline is misconfigured or the token is exposed, its capabilities remain limited to deploying changes to that application, without allowing the Worker to be deleted or other applications in the account to be modified. Cloudflare explains that these permissions are applied across three scopes: the entire developer platform, a specific product such as Workers, or a specific resource such as a single Worker.
Important Scope and Connectivity Limitations
Access to a Worker alone is not sufficient to add, change, or delete a Route or Custom Domain. These operations require the Editor permission on the Worker, along with the Workers Routes permission for the zone. This separation allows management of how traffic is routed to the application without granting broader permissions over domain settings.
After the route is configured, a CI/CD system can continue deploying new versions as long as the deployment does not change the existing connection, without being granted access to the associated domains, databases, or storage. Durable Objects likewise rely on the permissions of the Worker that operates them; the Metadata Read-Only role provides access to their metrics, logs, and traces, but not to the data stored in them. Access to Data Studio, which can query and modify data, requires the Editor role.
Error Messages and Legacy Versions
Cloudflare has updated API responses when operations are denied so that they are no longer limited to the general 403 Forbidden error, but also include a link to documentation specifying the required permission. This is expected to help users and agents configure permissions precisely instead of expanding them randomly.
The company recommends moving to the new roles instead of the legacy Workers-specific permissions, but it has not announced a retirement date for them, and existing assignments will continue to work until advance notice is provided. Cloudflare plans to extend the same model to other products, including D1, R2, and KV, so that access can be restricted to a particular database or storage space.
certi.news's Take
The actual change here is not merely the addition of a new administrative role, but the shift of control from the account or product level to the resource level, with a clear separation between monitoring data, content, and execution. This is especially important for teams that use software agents or automated deployment pipelines, because an error or token leak can be contained within a single Worker. At the same time, route and domain management remains an area requiring separate permission, while support for D1, R2, and KV is still described as a future plan rather than a current availability. As for the continuation of legacy permissions without an announced retirement date, this means organizations will need to review their policies gradually rather than assume an immediate transition.