操作员作用域

操作员作用域用于限制 Gateway 客户端在身份验证后可以执行的操作。 它们是一个受信任 Gateway 操作员域内的控制平面护栏， 而非对抗性多租户隔离。若要在人员、 团队或机器之间实现强隔离，请在单独的操作系统用户或主机上运行独立的 Gateway。

相关：安全、Gateway 协议、 Gateway 配对、设备 CLI。

连接角色¶

每个 Gateway WebSocket 客户端都以一个角色连接：

• operator：控制平面客户端，例如 CLI、Control UI、自动化以及 受信任的辅助进程。
• node：能力主机（macOS、iOS、Android、无头），通过 node.invoke 暴露命令。

操作员 RPC 方法要求 operator 角色。源自节点的方法 要求 node 角色。

作用域级别¶

个人 GitHub 连接管理是只读行为的一个范围狭窄的自我限定例外： users.github.* 需要 operator.read 以及完全匹配的已认证持久配置文件。该人员只能连接、轮询、取消、 重新连接或断开其自己的账户。这些方法不会暴露团队机密、修改共享配置，或授予 OpenClaw 写入/管理作用域。系统 和按代理的 GitHub 更改仍属于 operator.admin。

使用 operator.sessions.write 时，请求者可以通过共享 GitHub 账户发布其创建的会话中的常规更改。工作流定义 更改需要原始请求者当前完整的 operator.write 权限。个人发布也需要 operator.write。每次发布 仍需要当前会话授权。参见 GitHub 连接。

未知的未来 operator.* 作用域要求完全匹配，除非调用者 已持有 operator.admin。

operator.sessions.write 包含 operator.sessions.read。广义的 operator.read 也包含会话读取，而 operator.write 包含两个 会话作用域。会话作用域不授予通用诊断、 配置更改、Gateway 范围的工具调用或发布权限。

会话读取者可以浏览可见对话并接收其更新。 Control UI 可以将可见历史复制为 Markdown。会话写入者可以重命名、 置顶、归档或恢复其自己的现有对话。其他人的可见 会话在这些授权下仍为只读，包括共享会话。 会话授权从不允许删除或更改现有会话的 共享和可见性。 归档会话不会授予删除它的权限。

在 Control UI 中，会话写入者可以使用 新建会话，在自己的对话中 发送消息，并停止其自己的活动运行。他们的模型、effort、 fast-mode 和非完整权限选择使用相同的会话授权和 Gateway 允许的模型目录。完整权限模式、沙箱更改以及对现有会话上下文窗口的更改仍需要管理员访问权限。 重新连接会在重放其原始运行的 Stop 之前重新检查当前权限。

自有工作方法（包括发送消息、常规会话创建、 恢复和分支）在其参数不需要管理员访问权限时接受 operator.sessions.write。会话所有权、当前权限、 代理访问权限以及运行时和沙箱要求仍然适用。 artifacts.list、artifacts.get 和 artifacts.download API 需要 更广泛的 operator.read 作用域。

RPC、事件和后台工具使用相同的作用域规则。具有 operator.write 的延续可以读取其 GitHub 身份和会话状态，而无需另一条 交互式消息。会话访问权限和执行生命周期检查仍然适用。

question.* 对于绑定到调用者自身已准入运行和自有会话的常规问题， 也接受 operator.sessions.write。Gateway 从受信任的运行权限记录该绑定，绝不使用调用者提供的会话或 运行标识符。相同的归属检查会过滤问题事件和恢复读取。仅凭会话可见性或成员资格不会授予此访问权限。 仅 operator.sessions.read 无法回答问题。无会话问题、 机密提示以及其他特权问题工作流保留其现有的 operator.questions 和管理检查。

命名操作员角色¶

团队 Gateway 可以将已认证的持久化配置文件绑定到命名操作员角色。 每个角色控制对其他人员会话的访问权限、 可用于创建会话和代理运行的代理、操作员作用域的最大集合， 以及新创建的会话是否需要沙箱化。它还可以要求 由插件提供的访问策略。

{
  gateway: {
    roles: {
      default: "guest",
      definitions: {
        maintainer: {
          sessions: { others: "write" },
          agents: ["roboclaw"],
          scopes: ["operator.read", "operator.write", "operator.approvals"],
        },
        guest: {
          sessions: { others: "view" },
          agents: ["roboclaw"],
          scopes: ["operator.sessions.read", "operator.sessions.write"],
          sandbox: "required",
        },
      },
    },
  },
}

使用具有管理员作用域的 users.setRole Gateway 方法，并传入 { profileId, role } 来分配已配置的角色。设置 role: null 可清除 分配。分配更改会立即使该配置文件 的活动 Gateway 连接失效并关闭它们。重新连接会应用当前角色和作用域 上限。即使返回结果失败，已提交的更改仍会使先前的访问权限失效。经过授权的自我降级会在其 连接关闭之前收到响应。只要配置了角色，gateway.roles.default 就是必需的， 必须指定一个现有定义，并应用于没有有效 已分配角色的配置文件。完全省略 gateway.roles 会保持单人部署和共享密钥 部署不变。

当某个插件必须确认该人员当前访问权限时，将角色的可选 accessPolicyPlugin 设置为精确的插件 ID。例如，Visitor Access 插件 在其受限默认角色上要求 accessPolicyPlugin: "visitor-access"。 被拒绝的连接会收到 OPERATOR_ACCESS_DENIED 连接错误详情， 并且 Control UI 会说明该账户没有访问权限。 该要求属于 Gateway 配置，并且即使 插件或其清单缺失、被禁用、损坏或仍在启动时，也会持续强制执行。已加载的 插件必须返回该人员的当前权限；其他插件的策略 不能满足该要求。配置验证允许不可用的 插件引用，以便 Gateway 仍能启动以进行修复。没有此绑定的独立员工 角色以及 Gateway 所有者保留其现有访问权限。 恢复所需插件以允许绑定角色。移除或更改 绑定会通过下面描述的同一实时角色策略更新生效。

启用实时配置重载后，对 gateway.roles 和 gateway.auth.identityScopes 的编辑无需重启 Gateway 即可生效。现有 Gateway 客户端会重新连接以接收当前作用域上限，但以下情况除外：仅限于模型策略的更改（如下所述），以及不改变 操作员 WebSocket 登录已解析授权集的标识作用域编辑。编辑其他登录 或重新排序相同作用域会保留该连接、其已接受的运行和 排队输入。更改其自身已解析授权会撤销保留和委托的 工作；恢复授权不会恢复原始权限。没有 已验证身份、节点连接、HTTP 请求和插件身份验证 cookie 的客户端 不会消耗标识作用域授权，并且不受这些编辑影响。待处理握手和 变更在获取权限前会重新检查策略； 已准入的运行保留其正常完成和取消生命周期， 包括当其原始访问策略授权过期或被撤销时取消。

当配置了角色时，身份认证的操作员连接不会 接收可重用的设备令牌或引导令牌：这些令牌未绑定到 人员，并且可能绕过角色上限。对于操作员 Gateway 连接和 HTTP 请求，没有已验证用户身份的设备令牌或引导令牌 身份验证会被拒绝。通过可信代理或 其他受支持的已验证身份重新连接，例如 Tailscale。节点连接、 共享密钥/密码访问，以及没有角色配置的 Gateway 保留 其现有行为。

对于由其他人创建的会话，sessions.others 支持以下值：

• "none"：从列表和目标访问中隐藏外部会话，将会话级用量过滤到可见会话，并拒绝 Gateway 范围的 usage.cost， 因为其聚合可能包含隐藏会话。
• "view"：允许读取但不允许变更，即使会话 以其他方式共享。
• "suggest"：允许查看和现有建议流程。
• "write"：允许参与外部会话。草稿和隐身 限制仍然有效。

人员始终拥有自己的会话。显式会话成员资格可以提高 特定会话的 "view" 或 "suggest" 访问权限，并且已经 持有 operator.admin 的连接保留其管理会话访问权限。

设置 agents: "*" 以允许在每个代理上创建会话和代理运行，列出 代理 ID 以仅允许这些代理，或使用空数组以禁止两者。 当运行目标为已存在的会话时，也应用允许列表。

设置角色的可选 modelPolicy 以限制其请求使用的模型：

```json5 validate=false // Inside gateway.roles.definitions.guest modelPolicy: { sourceAgent: "shared-agent", deny: ["provider/restricted-*"], }

在没有 `allow` 覆盖的情况下，策略按顺序遵循该代理配置的主模型和
回退模型。省略 `sourceAgent` 会使用配置的系统代理或
默认代理，或唯一代理。没有此类所有者的多代理 Gateway
必须指定源代理。这会读取现有代理配置；它不会
复制模型列表或授予对每个已安装模型的访问权限。

使用 `allow` 集中替换允许集合，使用 `deny` 从任一来源中排除模型。
空 `allow: []` 拒绝所有模型。两个列表都接受
精确的 `provider/model` 引用、来自源代理模型设置的别名，
以及尾随通配符，例如 `provider/*`、`provider/family/*` 或
`provider/restricted-*`。其他通配符位置会被拒绝。排除项
匹配已解析身份，因此别名无法绕过它们，并且家族前缀
也会排除新配置的家族成员。



角色策略是额外的上限。现有代理规则仍然约束手动模型选择。默认可以使用目标代理已允许手动使用或通过其配置的主用和回退链使用的首个允许源模型。自动重试在准备提供商之前会过滤该链；如果允许结果为空，则返回错误，而不是扩大访问权限。

启用配置重载后，仅限于现有角色 `modelPolicy` 设置的编辑会在配置事务提交时生效，无需重启 Gateway 或重新连接其客户端。其他角色更改会热应用，并使用当前权限重新连接客户端，包括与模型策略编辑组合时。禁用配置重载会使当前策略保持有效，直到配置应用恢复。

原始角色上限会跟随排队工作和子运行。已接受的工作必须同时满足其原始模型上限和当前策略。移除一个源模型会取消使用它的活动模型请求，并阻止后续使用它的调用，而仍被允许的兄弟模型和无关工作保留其权限。新请求使用更新后的源选择。直接模型请求、标题预览以及用户调用的模型补全或决策工具应用相同策略。交互式插件运行时尝试在执行受限请求之前，必须证明已强制执行确切的模型策略，无论谁提供其凭据。目前内置的 OpenClaw 运行时支持这些尝试；未认证的插件运行时（包括 Codex）会以兼容运行时错误拒绝它们。添加策略还会取消在没有策略下启动的未认证工作，包括其前台轮次结束后保留的工作。外层选择的模型不会确定原生运行时实际使用哪个模型。隔离的仅提示补全保留其单独的精确路由契约，并通过补全和清理绑定所选模型。

有界的自动元数据、操作员配置入站媒体预处理以及主机拥有的执行审批保留其现有服务权限。省略 `modelPolicy` 会保留角色的现有模型访问权限，共享密钥 System 访问不变。

没有模型策略的原生 Codex 员工工作，在合格的原生钩子被禁用或不可用时，存在有限的归属情况：先前接受的不受限制输入与其他工作混合后，可能在其发送者失去授权或变为受限后，继续在其接收者的有效权限下运行。直接绑定且无歧义的工作仍然遵守撤销。参见[原生模型策略边界](../plugins/codex-harness/routing.md#operator-role-model-permissions)。访客访问需要显式模型策略；其 Codex 运行需要合格的集成。

可选的 `sandbox` 策略默认为 `"inherit"`，这会保留代理配置的沙箱模式。设置 `sandbox: "required"` 会为具有该角色的已认证人员创建的每个新会话启用沙箱，即使代理的沙箱模式为 `"off"`。示例允许维护者在 `roboclaw` 上使用主机执行，而同一代理上由访客创建的会话仍保持沙箱化。

必需沙箱按已认证会话创建者隔离，而不仅仅是按代理或按会话隔离。使用同一代理的不同访客会获得独立的沙箱环境和工作区。同一访客创建的多个会话会复用该访客的环境和工作区。无论配置的沙箱范围如何，此按访客边界均适用。如果代理配置了 `workspaceAccess: "rw"`，OpenClaw 会将角色必需会话的访问权限降低为 `"ro"`，并记录 `agent/sandbox` 警告，防止共享代理工作区成为访客之间的可写桥梁。维护者会话和其他没有角色必需沙箱的会话保留其配置的范围和工作区访问权限。

Gateway 会在新会话首次运行之前，将已认证创建者及其沙箱要求一起记录，包括聊天、OpenAI 兼容 HTTP 端点、Talk、恢复、分叉、检查点分支、cron、出站消息和派生子项。
委托的子工作继承必需父项的原始创建者和沙箱策略，即使角色更改后也是如此。由另一人请求的恢复和分支使用该人自己的角色，而不是源会话的策略。

必需的创建来源不可变。角色更改、共享、参与、`sessions.patch`、整条替换、遗留导入和规范键修复不能移除或替换现有必需标记。被阻止的持久化覆盖会发出 `session-sqlite` 警告。使用 [`openclaw logs --follow`](../cli/logs.md) 检查它们。现有未标记会话以及创建者不需要沙箱的新会话保留其现有行为。

角色要求沙箱的人员无法在现有主机执行会话中启动运行，即使被明确邀请也是如此。如果其沙箱后端不可用或配置失败，必需会话会失败。它们永远不会回退到 Gateway 或节点。`/elevated`、`exec` 主机覆盖和配置的主机目标无法绕过此限制。代理管理的 GitHub 身份不会注入到沙箱化执行中：`GH_CONFIG_DIR` 不存在，`GH_TOKEN` 和 `GITHUB_TOKEN` 被置空。

角色的 `scopes` 列表限制通过连接认证、身份授权、配对、范围升级和已认证可信代理 HTTP 请求授予的范围。上限使用正常的范围蕴含：`operator.admin` 允许每个操作员范围，`operator.write` 允许 `operator.read` 和 `operator.talk`。它只过滤现有授权。它不能添加连接尚未收到的范围。
上限与能力相交，包括由更广泛授权蕴含的能力。缩小为只读角色的写授权保留 `operator.read`；缩小为写角色的仅管理员授权保留 `operator.write`。角色不能授予原始凭据不允许的能力，空授权或角色保持为空。



会话读取和组织使用最后一次成功应用的角色配置。被拒绝的配置重载不会改变这些权限。

这包括插件 HTTP 请求和 WebSocket 升级：在没有 scope 头的情况下，普通 Gateway 身份验证的插件路由最初只有 `operator.write`，然后应用角色上限。因此，只读角色在该路径上保留 `operator.read`，而空角色不会获得任何运行时 scope。Control UI 插件授权会在签名 cookie 中携带已认证 profile。插件 HTTP 请求会重新应用该 profile 的当前角色上限，并在启用角色时拒绝没有匹配持久化身份的授权。仅当该角色应保留管理连接权限时，才显式包含 `operator.admin`。

由管理员证明的[频道身份链接](../concepts/user-model.md#channel-identity-links)还允许发送者从其有效角色的 `operator.admin` scope 继承频道所有者权限。这不需要额外的身份 scope 授权。当不存在角色时，频道所有权改用匹配的管理身份 scope 授权。连接 scope 授权和上限保持不变。

命名角色适用于已认证的持久化 profile 及其证明的频道身份。它们在一个受信任的 Gateway 域内组织协作，当需要敌对租户隔离时，不能替代独立的 Gateway。诊断审计方法（包括 `audit.run.inspect`）仍然是共享域的 `operator.read` 接口，并且不按会话角色过滤。同样，`operator.write` 仍然授权 Gateway 范围的操作，例如工具调用、普通节点命令中继以及其他 write scope 的控制平面操作。会话限制不会将该 scope 变成按人员划分的隔离边界。当互不信任的人员不能共享诊断或控制平面写权限时，请使用独立的 Gateway。

## 身份 scope 授权 {#identity-scope-grants}

`gateway.auth.identityScopes` 为来自可信代理身份验证或 Tailscale WhoIs 的已验证用户身份授予 operator scope：

```json5
{
  gateway: {
    auth: {
      identityScopes: {
        "admin@example.com": ["operator.admin"],
        "operator@example.com": ["operator.read", "operator.write"],
      },
    },
  },
}

键是已验证的代理身份或 Tailscale WhoIs 登录名。电子邮件键不区分大小写匹配。非电子邮件身份必须完全匹配。配置验证会拒绝上述封闭集合之外的 scope 名称。

连接权限按以下顺序解析：

1. 对于可信代理 Control UI 连接，x-openclaw-scopes 首先限制设备注册或升级请求。设备授权随后建立持久 scope。无设备会话不会贡献任何自声明 scope。
2. OpenClaw 将匹配的服务器端身份授权与这些 scope 取并集。
3. OpenClaw 将 x-openclaw-scopes 作为会话上限应用于最终并集。缺失该头表示没有上限。存在但为空的头不会产生任何 scope。
4. 如果已认证 profile 具有有效的命名 operator 角色，OpenClaw 会将结果与该角色配置的 scope 上限取交集。

该结果同时用于 hello.auth.scopes 和 Gateway 方法授权。身份授权仅限会话：它们不会创建或修改配对记录，也不会请求设备 scope 升级。Token、密码和无身份验证连接不携带已验证身份，也不会获得授权。身份授权仅适用于 operator 角色连接。node 角色连接永远不会获得它们。

方法 scope 只是第一道关卡¶

每个 Gateway RPC 都有一个最小权限方法 scope，用于决定请求是否到达其处理器。感知参数的方法会在分发前推导该 scope，以便授权失败具有一个规范的结构化响应：

• agent 普通轮次需要 operator.write，/new 或 /reset 会话生命周期命令需要 operator.admin。
• node.invoke 普通中继命令需要 operator.write，当中继 browser.proxy、browser.proxy.upload.v1、fs.listDir 或 terminal.upload 到节点时需要 operator.admin。
• 顶层 fs.listDir RPC 对 Gateway 主机请求需要 operator.write，当 nodeId 指向节点时需要 operator.admin。其处理器将非管理员 Gateway 主机浏览限制在已配置的 agent 工作区。
• plugins.sessionAction 要求所选 action 的 requiredScopes 中声明的每个 scope。省略或空列表默认为 operator.write。operator.write 满足 operator.read 和 operator.talk。其他 scope 需要精确匹配，或 operator.admin。
• sessions.create 接受 operator.sessions.write 用于普通自有会话创建（包括 projectId），或更广泛的 operator.write scope。隐身会话和任何 execNode 请求需要 operator.admin。对于非管理员调用者，处理器将 cwd 限制在已配置的 agent 工作区。projectId 不能与 cwd 或 execNode 组合使用。
• environments.list 普通清单需要 operator.read，当 runtimeId 请求运行时特定命令资格时需要 operator.write。会话放置方法在 schema 验证前根据请求目标推导其 scope：sessions.dispatch 对 deviceId 需要 operator.write，对 profileId 或无目标的 cloudWorkers.projectProfiles 查找需要 operator.admin。sessions.move 对 Gateway 或设备目标需要 operator.write，对 profile 目标需要 operator.admin。abandonSource: true 仍为 operator.write，但仅在 Gateway 目标下 schema 有效，且仅对精确的离线设备源运行时有效。sessions.reclaim 仍为 operator.write。格式错误的 dispatch 参数或格式错误的 move 目标使用 operator.write，以便处理器返回精确的 schema 错误。这三个方法都保留会话所有权、参与关系和提交时重新验证围栏。仅 operator.read 不能启动、停止或移动会话。云 profile 分配和变更、配对和 Connect 机器、原始 environments.create 或 environments.destroy、隐身会话、直接 execNode 执行以及任意主机或节点路径仍为 operator.admin。
• worktrees.branches 需要 operator.write。其处理器将非管理员调用者限制在工作区包含的路径或已注册项目根目录。其他主机路径需要 operator.admin。
• talk.config 需要 operator.read。includeSecrets: true 还需要 operator.talk.secrets。
• talk.client.*、talk.session.*、talk.speak 和 talk.mode 需要 operator.talk（或兼容的更广泛 operator.write）。
• sessions.patch 和 sessions.patchMany 接受 operator.sessions.write 用于组织字段、model、agentRuntime、思考级别、快速模式以及自有会话上的非完整权限模式。元数据补丁要求存在已拥有的会话；它们不能声明未使用的键。广泛的 operator.write 保留其现有会话访问权限。完整权限模式、沙箱变更、原生运行时同意以及特权或未知字段需要 operator.admin。运行时可用性和沙箱检查仍然适用。将所选模型持久化为已配置的 agent 默认值仅限管理员。
• sessions.delete 对带有受支持字段的仅归档请求需要 operator.write，否则需要 operator.admin。两种会话 scope 都不授权删除。

项目 RPC 使用以下作用域：

随后，某些处理器会根据被审批或被变更的具体对象施加更严格的检查：

• device.pair.approve 在持有 operator.pairing 时即可访问，但审批操作员设备时，只能授予或保留调用方已经持有的作用域。
• node.pair.approve 在持有 operator.pairing 时即可访问，然后根据待审批节点声明的命令列表推导出额外的审批作用域。
• chat.send 是一个需要写入作用域的方法，但 /config set 和 /config unset 聊天命令在此基础上还要求 operator.admin，无论调用方的 chat-send 作用域如何。

这样，较低作用域的操作员就可以执行低风险配对操作，而不必让所有配对审批都变成仅限管理员。

会话变更 RPC 依据协商得到的操作员作用域进行授权，与连接客户端的 client.id 或 client.mode 无关。客户端身份仍会影响连接和设备认证策略，但它既不会授予也不会撤销会话变更权限。

audit.run.inspect 有意使用 operator.read。在 Gateway 操作员域中，每个持有该作用域的客户端都可能收到保留的执行身份上下文，包括受限的假名化引用和经机密脱敏的显示标签。operator.read 既不是按人划分的隐私边界，也不是对抗性多租户环境下的隐私边界。需要将此数据隔离开来的操作员，必须使用独立的 Gateway 信任域。

设备配对审批¶

设备配对记录是已批准角色和作用域的持久来源。已配对的设备不会静默获得更宽泛的访问权限：如果重新连接时请求更宽泛的角色或更宽泛的作用域，则会创建新的待处理升级请求。

已连接的受限 Control UI 如果具有宽泛的读取权限，则可以通过 Inbox > System > Limited access > Request admin 提交同一待处理请求，而无需尝试更宽泛的重新连接。该请求绑定到当前活动连接上经签名的设备身份。审批仍然来自 device.pair.approve，因此需要 operator.pairing，并且对每个所请求的作用域都具备权限。审批轮换操作员令牌后，Gateway 只会将新令牌返回给该设备的活动等待方。浏览器会在重新连接前存储该令牌。如果在审批前取消等待或断开连接，则会在下次连接时回退到常规配对修复流程。

仅包含 operator.admin 的角色允许 Control UI 请求完整操作员作用域。审批仍然是必需的。角色上限本身并不会授予设备作用域。

超出已认证人员所分配角色上限的请求会被拒绝，而不会进入设备审批队列。Gateway 会在审批后、返回令牌前再次检查当前角色，因此如果在等待期间角色被降级，仍会阻止超出角色范围的结果。Control UI 会显示拒绝信息和管理员指引，但不提供 Retry 按钮。管理员必须先更改角色。

明确的例外是：由 openclaw dashboard 或图形化引导直接在 Gateway 主机上签发的、具备管理员能力的 Control UI 所有者档案。其短期、单次使用的引导凭证仅当绑定到同一签名浏览器密钥对时，才能为全新浏览器审批精确的闭合作用域集合，或升级现有的受限凭据。通用 Control UI 和 Telegram 移交流程、移动端设置档案、共享凭据、本地性以及调用方自行选择的作用域均不享有此例外。

审批设备请求时：

• 不包含操作员角色的请求无需操作员作用域审批。
• 请求非操作员设备角色（例如 node）需要 operator.admin，即使 device.pair.approve 本身只需要 operator.pairing。
• 请求 operator.read、operator.write、operator.approvals、operator.sessions.read、operator.sessions.write、operator.questions、operator.pairing、operator.talk 或 operator.talk.secrets 时，调用方必须已经持有该作用域，或持有 operator.admin。
• 请求 operator.admin 需要 operator.admin。
• 未明确指定作用域的修复请求可以继承现有操作员令牌的作用域。如果该令牌具有管理员作用域，审批仍然需要 operator.admin。

非管理员的共享密钥和受信代理会话只能在其自身声明的操作员作用域内审批操作员设备请求。审批非操作员角色仅限管理员，即使这些会话在其他情况下可以使用 operator.pairing。

对于已配对设备令牌会话，除非调用方持有 operator.admin，否则管理操作以自身作用域为限：非管理员调用方只能看到自己的配对条目，并且只能审批、拒绝、轮换、撤销或移除自己的设备条目。

节点配对审批¶

node.pair.* 能力审批存储在共享 SQLite 配对存储中的已配对设备记录上。Gateway 会在启动时一次性将已退役的独立 nodes/paired.json 存储中的任何剩余条目迁移到这些记录中。详见 Gateway 配对。

node.pair.approve 会从待处理请求的命令列表中派生额外所需范围：

此处，fs.listDir 是通过 node.invoke 中继声明的节点命令，而不是上文所述的顶层 Gateway RPC。

批准节点声明会记录其命令表面。对于 computer.act，节点仅在本地启用 Computer Control 后才通告该表面。配对更新获批后，通过 node.invoke 调用它时，每个操作需要 write 范围，但不需要 admin 范围。被归类为危险或隐私敏感的命令，除配对外仍需要持久化的 gateway.nodes.commands.allow 条目。

节点配对建立身份和信任。它不会替代节点自身的 system.run 执行审批策略。

共享密钥认证¶

共享 Gateway 令牌/密码认证被视为对该 Gateway 的可信操作员访问。OpenAI 兼容的 HTTP 接口、/tools/invoke 以及 HTTP 会话历史端点会为共享密钥 bearer 认证恢复完整的默认操作员范围集，即使调用方发送了更窄的声明范围。

携带身份的模式，例如可信代理认证或私有入口 none，仍可以遵循显式声明的范围。请使用独立的 Gateway 来实现真正的信任边界隔离。

相关¶

• 可信代理认证 — 可信代理如何提供这些范围所附加的操作员身份
• Gateway 协议 — 这些范围授权的方法
• Cloud Workers — worker 分发，其环境和会话调用会针对这些范围进行授权