部署一个 Worker，不应该顺带拿到修改其他服务的权限。Workers 现在支持将访问权限限定到单个 Worker，并提供更细粒度的 Developer Platform 角色。团队成员、CI 令牌和智能体因此可以按任务获得访问能力，而不必共享一把“全能钥匙”。

这项变化的重点不是多了几个角色，而是可以同时回答两个问题：谁能访问哪个 Worker，以及进去以后能做什么。

权限要同时限定资源和动作

只限制操作、不限制资源，仍然可能让一个部署令牌影响多个服务；只限制资源、却给出过大的操作权限，也会让监控任务拥有不必要的修改能力。

可以这样规划访问边界：

这是权限设计示例，不是官方角色名称清单。具体角色能否查看日志、修改配置或执行部署，应以实际权限说明为准。

角色名称不能代替权限核对。 尤其要确认某个任务是否还依赖账户级资源，避免“Worker 范围已经收窄，但其他权限仍然过宽”。

把 CI 的部署目标和凭据分开管理

可以这样实践：给每个生产 Worker 配置独立的发布凭据，将凭据作为 CI 密钥注入，而不是写进仓库。下面的命令假设项目已经具备有效的 Wrangler 配置，并且令牌拥有目标 Worker 部署所需的权限。

运行前，设置账户 ID、目标 Worker 名称和 API 令牌：

export CLOUDFLARE_ACCOUNT_ID="your-account-id"
export WORKER_NAME="your-worker-name"

read -rsp "Cloudflare API token: " CLOUDFLARE_API_TOKEN
echo
export CLOUDFLARE_API_TOKEN

(
  set -euo pipefail

  : "${CLOUDFLARE_ACCOUNT_ID:?Missing account ID}"
  : "${CLOUDFLARE_API_TOKEN:?Missing API token}"
  : "${WORKER_NAME:?Missing Worker name}"

  npx wrangler deploy --name "$WORKER_NAME"
)

unset CLOUDFLARE_API_TOKEN

这里有一个容易混淆的边界：--name 只是选择部署目标，不会收窄令牌权限。真正的限制必须在平台的访问控制配置中完成。

在 CI 中，还应固定 Wrangler 版本，避免发布工具自动变化；不要开启会打印环境变量或令牌的调试输出。

给智能体权限，不等于把决策权全部交出去

智能体可能承担查询运行状态、分析故障或修改服务的任务，但这些任务不应该天然共享同一套权限。

一个稳妥的工作流是：

1. 默认提供目标 Worker 的诊断所需访问。
2. 需要修改时，明确列出目标资源和拟执行操作。
3. 通过单独的审批或受控执行环节完成变更。
4. 任务结束后撤销临时访问，并记录执行结果。

这是一种可采用的流程，不代表平台自带上述审批机制。它解决的是另一个问题：权限系统能够限制“能做什么”，却不能自动保证智能体判断正确。

即使权限已经限定到单个 Worker，错误部署仍然可能导致该服务不可用。生产变更仍需测试、审查和回滚准备。

从共享令牌开始迁移

落地时，优先检查三类凭据：团队共享令牌、同时发布多个服务的 CI 令牌，以及交给智能体的账户级凭据。

迁移清单可以很短：

• 明确每个凭据对应的使用者和任务。
• 将资源范围收窄到必要的 Worker。
• 选择满足任务的最小角色，并检查额外依赖。
• 验证允许的操作能够成功，范围外的操作会被拒绝。
• 定期清理闲置凭据，并在职责变化后重新审查权限。

最小权限不是“权限越少越好”，而是权限足够完成任务，又不足以把一次错误扩散到其他服务。

English version

Scope Workers Access to the Service and the Job

Deploying one Worker should not require permission to change unrelated services. Workers now supports access scoped to individual Workers and narrower Developer Platform roles, allowing teammates, CI tokens, and agents to receive the access they need.

The useful distinction is between two boundaries: which Worker an identity can access, and what it can do there.

Restrict both resources and actions

Limiting actions without limiting resources can still expose multiple services to one deployment token. Limiting resources while granting broad capabilities can leave a monitoring task with unnecessary write access.

A practical access plan could look like this:

These are design examples, not official role names. Check the actual permission definitions before assuming a role can read logs, change configuration, or deploy.

Also review any account-level dependencies. A narrow Worker scope does not make unrelated broad permissions harmless.

Separate the deployment target from the credential

One approach is to give each production Worker a dedicated release credential and inject it through CI secret storage rather than committing it to the repository.

The following example assumes an existing project with valid Wrangler configuration and a token authorized to deploy the target Worker. Replace the account ID and Worker name before running:

export CLOUDFLARE_ACCOUNT_ID="your-account-id"
export WORKER_NAME="your-worker-name"

read -rsp "Cloudflare API token: " CLOUDFLARE_API_TOKEN
echo
export CLOUDFLARE_API_TOKEN

(
  set -euo pipefail

  : "${CLOUDFLARE_ACCOUNT_ID:?Missing account ID}"
  : "${CLOUDFLARE_API_TOKEN:?Missing API token}"
  : "${WORKER_NAME:?Missing Worker name}"

  npx wrangler deploy --name "$WORKER_NAME"
)

unset CLOUDFLARE_API_TOKEN

The important boundary: --name selects the deployment target; it does not restrict the token’s permissions. Configure the actual restriction in the platform’s access controls.

For CI, pin the Wrangler version and avoid debug output that exposes tokens or environment variables.

Agent access still needs operational guardrails

An agent that checks service health does not automatically need permission to modify the service.

A cautious workflow is to grant diagnostic access first, require the agent to identify the resource and proposed change, and route mutations through a separate approval or controlled execution step. Revoke temporary access afterward and record the outcome.

This is a suggested workflow, not a claim that the platform supplies that approval mechanism. Access controls limit capabilities; they do not guarantee sound decisions.

Even access restricted to one Worker can permit a damaging deployment to that service. Testing, review, and rollback preparation remain necessary.

Start with shared credentials

Prioritize shared team tokens, CI tokens that deploy multiple services, and account-wide credentials issued to agents.

For each credential:

• Identify its owner and purpose.
• Restrict access to the necessary Worker.
• Choose the smallest suitable role and check dependencies.
• Test that required actions succeed and out-of-scope actions are denied.
• Remove unused credentials and review access when responsibilities change.

Least privilege means enough access to complete the job, without letting one mistake spread to unrelated services.

SEO description

Scope Workers access to individual services and narrower roles, giving teammates, CI tokens, and AI agents only the permissions their tasks require.