OpenShell 权限隔离与默认策略的陷阱

给 AI Agent 写上「不要访问外网」，和让运行环境真正拦住越界请求，是两件事。作者沿着 OpenShell 文档梳理了一次访问链路，发现最容易被误读的地方是：创建命令没有传 --policy，并不能证明限制严格的默认策略已经生效。

这篇解读值得看的，是它把访问权限拆成了几个可检查的环节：谁批准连接、策略从哪里来、凭证交给谁，以及谁能绕过常规路径导出凭证。不过，作者做的是文档分析，没有安装测试，也没有验证逃逸防护。

谁来拦住 Agent，比怎样提醒它更关键

NVIDIA 在 10 月 21 日的 OpenShell 公告中，把运行时强制执行放在了中心位置。它关注的不是 Agent 是否愿意遵守指令，而是请求真正发出去时，哪个组件有权放行。

按照作者阅读的架构文档，Agent 工作负载访问外部 API 时，网络流量需要经过受保护的通道，交给位于 Agent 信任边界之外的 supervisor。后者检查策略，再建立获准的外部连接。

这里的信任边界，可以理解为「哪些组件不能交给 Agent 自己控制」。请求访问的程序，不掌握批准访问的组件，才有机会形成独立于提示词的约束。上图是依据文档绘制的概念说明，不是实际部署截图或渗透测试结果。

文档还提到 policy prover：它在拟议的网络策略变更获批之前，检查变更是否扩大访问范围。作者对此保持了克制。这是在检查模型所描述的策略变化，不能延伸成「Agent 的所有行为都已经得到形式化安全证明」。

没传 --policy，为什么仍可能有外网权限

省略 --policy，不能证明限制严格的回退策略正在生效。

默认策略文档给出的条件更具体：只有不存在生效的全局策略、已保存的沙箱策略，以及镜像提供的策略时，才会采用限制严格的回退策略。

也就是说，命令行只是策略来源之一。即便创建命令没有指定 --policy，镜像或配置仍可能带入策略。镜像策略无效时，OpenShell 会阻止启动，而不是悄悄改用回退策略。

还有第二层容易漏看：回退策略自身没有出站网络规则，但挂载的 provider 可以向最终生效的策略贡献规则。因此，「回退策略不允许出站」与「运行中的沙箱没有出站权限」，不能直接画等号。

审查部署时，应该追问两个结果：实际选中了哪份策略，叠加 provider 规则后最终允许什么。只看 quickstart 命令缺少哪些参数，会漏掉真正决定权限的配置。

原文没有展开所有策略来源同时存在时的完整优先级，不能据此自行补出一套覆盖顺序。

Agent 拿不到真实密钥，谁还能拿到

在文档描述的沙箱请求路径里，真实 provider 凭证保留在 Agent 工作负载之外，仅为获准的目标地址提供。这能减少把可重复使用的密钥直接塞进 Agent 环境变量的需要。

但 provider 文档同时列出了另一种能力：特权 operator 可以通过显式 RPC，取回选定的运行时凭证。文档警告，这会把凭证值导出到沙箱端点强制执行范围之外。普通用户和 OIDC 管理员不能调用这个 RPC。

因此，「Agent 看不到真实密钥」描述的是经过代理控制的工作负载路径，不代表平台不存在凭证导出能力。原文没有给出这个 RPC 的具体名称，也没有测试导出之后的实际使用范围。

审查 provider 挂载关系时，还得一起看 operator 权限。只检查 Agent 的提示词和环境变量，无法覆盖这条特权路径。

我的判断

我认可作者把审查对象从「Agent 被告知什么」推进到「运行时允许什么」。相较于仅靠提示词约束访问，独立 supervisor 至少给出了明确的执行位置；相较于只看网络规则，它又提醒读者把凭证和管理权限放进同一张权限图里。

但这篇材料能支持的是架构与配置层面的判断，还不足以证明某次部署已经安全。作者依据的是固定在 commit bc4c8f0 的文档，没有安装 OpenShell、测试逃逸，也没有验证硬件参考架构。

作者建议追踪一条允许请求和一条拒绝请求，但没有亲自执行。这是待验证的审查方法，不是测试成绩。文中也没有与其他沙箱方案的对照数据，不能据此断言 OpenShell 更安全，或判断这些机制的运行开销。

能拿来做什么

• 给 AI 编程环境配置外部 API 访问时，把「选中的策略」和「最终生效的规则」都列入检查项，同时核对全局配置、已保存策略、镜像策略与 provider 挂载情况。
• 在实际运行环境里准备一条应当允许、一条应当拒绝的请求，沿工作负载到 supervisor 的链路验证结果，并检查谁有权修改相关策略。
• 为 Agent 接入 provider 凭证时，同时盘点特权 operator 的凭证导出能力。普通工作负载拿不到密钥，并不足以完成整个平台的凭证权限审查。