Cloudflare Adds Resource-Scoped Workers Roles: A Proxy Operations Audit

Cloudflare announced resource-scoped access controls for Workers on September 15, 2026. The update introduces four roles—Metadata Read-Only, Content Read-Only, Editor and Admin—and lets administrators apply them at the Developer Platform, product or individual Worker level. The roles are available to all customers through the dashboard, API and Terraform.

This matters to proxy operations teams because edge code often sits beside request normalization, routing, observability and credential-handling workflows. A person or automation that only needs metrics should not automatically receive source-code access. A deployment pipeline should not need permission to delete unrelated Workers. The new model makes those boundaries easier to express, but only if teams map roles to real tasks and test denial paths.

What the four roles permit

Cloudflare describes the new roles as follows:

These roles can be scoped to one Worker. Cloudflare's example notes that CI/CD can receive Editor access to a specific Worker, allowing deployment without permission to delete it or change other Workers.

Inventory every principal before assigning roles

List human users, service accounts, agents, CI jobs and API tokens that can reach the edge platform. For each principal, record an owner, business purpose, target Worker, permitted actions, expiry or review date and revocation path.

Do not assign a broad role merely because the current identity name is unclear. Rename or replace ambiguous credentials first. One token shared by deployment, monitoring and emergency administration prevents meaningful attribution and makes revocation unnecessarily disruptive.

Use the proxy credential encoding validation guide when a deployment tool constructs proxy authentication values. Use the GitHub proxy-secret blocking update to strengthen repository-side prevention.

Map each workflow to the narrowest role

Start from the action, not the job title:

1. Give an on-call observer Metadata Read-Only on the affected Worker when metrics and traces are sufficient.
2. Give a code auditor Content Read-Only only when source inspection is required.
3. Give a deployment job Editor on the exact Worker it updates.
4. Reserve Admin for a small, monitored break-glass path that can create, delete or delegate access.
5. Add time bounds to temporary incident access and verify that expiry actually removes it.

Avoid stacking roles “just in case.” If one workflow needs two permissions, document why both are required and test each separately.

Separate Worker deployment from route changes

Cloudflare states that custom domains and routes require both Editor access to the Worker and Workers Routes permission for the relevant zone. That separation is useful: changing code and changing where traffic is sent are different risk decisions.

Keep ordinary deployments unable to alter production routing. Use a distinct approval path for route or custom-domain changes, and scope the zone permission to the smallest applicable boundary. After a change, verify both the selected Worker revision and the public route. A successful upload of code does not prove that traffic reaches the intended version.

The proxy market failover acceptance test provides a pattern for canarying routing changes without turning one regional issue into a global failover.

Treat secrets as a separate control plane

Resource-scoped roles reduce unnecessary access, but they do not make exposed secrets safe. Store proxy usernames, passwords, tokens and endpoint credentials in an approved secret mechanism. Never embed them in Worker source, build output, command history, analytics dimensions or logs.

Keep observability useful without recording complete authorization headers, cookies, proxy URLs or stable session identifiers. Hash or redact sensitive identifiers before export, and define retention by operational need.

Test the denial paths

An access policy is not proven by a successful deployment. In a non-production fixture, verify that:

• Metadata Read-Only can inspect allowed telemetry but cannot retrieve source.
• Content Read-Only can review code but cannot publish a revision.
• Editor can update its assigned Worker but cannot delete it.
• A principal scoped to Worker A cannot view or change Worker B.
• A deployment identity without Workers Routes permission cannot alter routes.
• Revoked or expired access fails promptly and produces an attributable audit event.

Cloudflare says API authorization errors now include a link to relevant permission documentation rather than only a generic 403. Use that detail for diagnosis, not automatic privilege escalation. A missing permission may indicate that the workflow is attempting an action it should not perform.

Migrate legacy permissions with a canary

Cloudflare has not deprecated legacy permissions, but recommends moving to the new roles. Do not replace every identity at once. Select one low-risk Worker, create a narrowly scoped identity, run read, deploy and denial tests, then observe a complete operational cycle.

Record the old and new policy, owner, rollback condition and removal date. Once the new role proves sufficient, revoke the legacy grant rather than leaving both active indefinitely. Repeat by workload class, starting with read-only monitoring before deployment and administration.

Audit checklist

• Every human, agent, CI job and token has a named owner.
• Each principal is scoped to the smallest Worker or product boundary.
• Monitoring, code review, deployment and administration use separate identities.
• Ordinary CI uses Editor rather than Admin where possible.
• Route changes require a separate zone permission and approval path.
• Proxy credentials remain outside source, build output and logs.
• Positive and negative permission tests are documented.
• Temporary access has a tested expiry and revocation path.
• Legacy grants are removed after a successful canary migration.
• Authorization errors trigger review, not automatic privilege expansion.

FAQ

Does Editor allow a CI job to delete a Worker?

No. Cloudflare describes Editor as able to update content and settings but not create or delete resources. Confirm the exact behavior with a non-production denial test.

Is Metadata Read-Only enough for incident response?

It is a strong default for an observer who needs settings, metrics, logs and traces. Escalate only when the incident task genuinely requires code access or modification.

Does Worker access also allow route changes?

Not by itself. Cloudflare states that routes and custom domains additionally require Workers Routes permission for the relevant zone.

Should an automation follow a 403 permission hint and request a broader role?

No. Treat the hint as diagnostic evidence. Compare the attempted action with the approved workflow, then have an owner decide whether the action or policy is wrong.

Compliance note

Apply access controls only to accounts and edge resources your organization owns or is authorized to administer. Follow organizational approval, audit, retention and regional data requirements. Do not use proxy infrastructure or scoped identities to bypass service controls, conceal unauthorized access or collect data without permission.