ARTICLE / 安全
OpenClaw 的三道信任边界：凭据、工具与回调权限
把浏览器、代码执行器和实时语音接入智能体后，真正需要审查的不只是模型会不会被诱导做坏事，还包括另一组问题：凭据是否进入了模型可见的工具结果，工具被声明后是否真的可执行，以及会话建立后回调需要的权限是否仍然有效。
2026 年 9 月到 10 月，OpenClaw 项目公开仓库出现了三个分属不同功能的 issue。它们分别发生在浏览器标签页、Codex 原生子进程和 Talk 实时咨询中，却指向同一种结构问题：授权信息在组件边界上要么多走了一步，要么没有按照实际使用时间继续持有。
凭据不应跟着连接地址进入模型视野
OpenClaw issue #158966 记录了一个浏览器工具输出边界问题：当 loopback CDP 端点包含 HTTP Basic 凭据或 query token 时，标签页列表和打开结果会把派生出的带凭据 WebSocket URL 一并交给模型。
模型操作标签页实际使用的是 targetId，并不需要建立连接所需的认证信息。报告进一步定位到输出处理：formatAgentTab 复制了 wsUrl，而 stripBrowserOpenInternalMetadata 虽然移除了所有权、resolvedProfile 等内部信息，却保留了 wsUrl。凭据传递对运行时建立连接是必要的，问题出在这个字段越过输出边界后没有经过裁剪。
这项验证调用了生产环境中的 URL 规范化、标签页动作和打开结果过滤函数，但只在浏览器代理边界注入了合成响应，没有连接真实浏览器或托管账户。因此，它能证明这些函数在给定输入下会保留带凭据地址，不能替代完整的 Chrome 端到端验证。
这个 issue 还特意澄清：相关实现 PR #137756 正按作者要求撤回，但关闭 PR 不等于缺陷已经修复。其页面后来被自动标记为 stale，原因也是长期没有有效活动，而不是维护者认定问题已经解决。
这类边界可以归纳为一个具体检查：连接凭据和操作标识不应依赖同一个输出字段。运行时可以在内部保留带凭据的连接地址，但交给上层时只应提供模型真正需要的 targetId 和页面元数据。
工具出现在目录里，不代表它有执行通路
OpenClaw issue #150822 关注的是另一种错位。报告环境为 OpenClaw 2026.9.4，父进程使用 native Codex app-server，子进程通过 native collaboration.spawn_agent 创建。
报告给出的对照是：父进程能够成功执行 gateway_exec canary，子进程中的同类调用却失败。子进程能够发现工具定义，调用时返回 OpenClaw did not register a handler for this app-server tool call.，而没有返回命令执行标记。
独立复核确认了“缺少执行处理器”这一机制：当子进程请求找不到精确注册的路由时，就会得到报告中的失败响应。但该 issue 同时包含另一个问题——detached failure delivery，即分离式失败通知。多条复核记录明确表示，这部分没有被独立复现，不能与缺少执行处理器合并成一条已经完整验证的故障链。
源码侧的解释是，native 子进程监控器负责任务、历史通知和子任务认领，却不负责入站子工具执行分发。父级的精确 thread/turn 守卫也不能被移除，否则可能让子进程绕过父级权限和生命周期限制。
这意味着，修复不能只是让子进程继承父进程的工具句柄。保留的 native model 和 source 权限并不自动产生子作用域的记忆工具权限，native pre-tool 恢复租约也不是通用的 detached 工具执行授权。缺少执行器本身不等于已经出现越权，但它会迫使系统面对一个不清楚的能力目录：模型看得到工具，却无法据此判断调用是否可用。
连接还在，setup 阶段的权限却已经释放
OpenClaw issue #167876 把问题推进到异步回调。Gateway 拥有的 Talk 实时会话可以完成 setup、接收音频，但 provider 随后触发 agent 咨询时仍可能失败，因为 setup RPC 返回后，回调已经不再持有后续 agent 执行所需的调用方权限。
报告中的具体错误是 Gateway caller authority is no longer active.。其复现路径分为三步：通过认证创建 Gateway 拥有的浏览器或 gateway-relay 实时会话；由 websocket 分发释放已经完成的 setup 请求所持有 caller authority；再调用 provider 的 agent-consult 回调，后续权限捕获随即失败。native run admission 同样没有收到原始操作者来源。
该 issue 被标记为高置信度源码级复现。这里成立的是权限生命周期与连接生命周期不一致：setup 结束释放了调用方权限，但稍后到达的咨询仍需要它。它不等于权限绕过，也不意味着所有版本的实时咨询都会失败；问题是否出现，还取决于具体版本、传输路径和后续执行位置。
三个 issue 指向同一种边界管理错误
三个 issue 的共同点不是都属于“智能体安全问题”，而是授权信息没有沿着实际使用路径被准确保管。
第一个问题是凭据多走了一步：运行时连接需要认证信息，模型操作标签页却不需要，于是凭据随 wsUrl 一起越过输出边界。第二个问题是能力声明和执行能力脱节：工具能出现在子进程目录中，却没有对应的执行处理器。第三个问题是授权释放早于使用：连接仍然活跃，setup 请求持有的调用方权限却已经被释放。
对部署和代码审查者来说，可以据此做三项直接检查：
模型可见输出面：工具结果中是否出现了操作并不需要的凭据、内部地址或认证字段。
能力目录与执行器：每个向模型公开的工具，是否都存在可到达、权限明确的执行处理器。
权限释放时序：异步回调和后续执行真正发生前，原始调用方权限是否仍在有效期内。
这三个检查的价值，在于它们不依赖攻击者先找到新的利用链，而是直接检查系统是否把自己的连接、能力和授权交代清楚。对自托管智能体基础设施而言，这比单看某个工具是否“对外可见”更接近实际风险边界。
本文面向授权安全研究与防御建设，未经授权对任何系统实施文中技术属违法行为。