NVIDIA 发布 OpenShell 0.1.0：在智能体外围强制运行时权限，读放行、写拦截，凭证不进入工作负载

OpenShell 0.1.0 把权限执行放在智能体工作负载之外，由三个组件分工：Gateway 管理大量沙箱的生命周期与策略，Supervisor 与每个沙箱配对并在工作负载之外检查出站请求，Sandbox 用内核级控制限制文件系统与进程且除经监督器外没有网络路径。 与把安全约束写进智能体自身逻辑或提示的做法不同，这里把执行点移到工作负载外部，因此当智能体启动 shell、运行生成代码、拉起子进程或提议委派给子智能体时，控制依然生效。 文中以组件职责描述与示例命令给出机制说明，并称策略决策记录在 OCSF 审计轨迹中；未给出性能或吞吐数据。

网络策略可以细到同一 API 的读与写：策略以 YAML 编写并编译为 OPA/Rego，对每个出站请求求值；示例中 protocol: rest 使监督器检查 HTTP 请求，放行对 api.github.com 的读、拦截同一端点的 POST，且替换策略无需重启沙箱。 相对只允许或禁止连接到某个服务，这里把控制粒度推进到请求语义层，并明确监督器可检查 HTTP、GraphQL 与 MCP 流量。 示例使用 curl 与 GitHub REST API 的未认证端点，使每次策略决策可见且不需要 API key 或语言模型；文中称智能体发出同样请求会遇到相同限制。

凭证保留在智能体工作负载之外并绑定到已授权请求：对某一服务的授权不会让凭证对另一服务可用，若占位符被发往凭证批准端点之外，OpenShell 会拒绝该请求；接收服务仍执行真实凭证自身的权限，OpenShell 在其上再加一层使用方式控制，例如只读 API 策略可拦截写请求，即使凭证本身具备写权限。 把凭证托管与请求级策略叠加，使权限控制不再只依赖下游服务对凭证的授权范围。 文中以 provider profile 定义凭证、端点与允许程序，并给出将名为 github 的 provider 附加到新沙箱并启动 Codex 的命令示例。

策略证明器用形式化逻辑检查策略授予的权限（含 provider 贡献的访问），可证明被建模的权限处于操作者定义的边界内，或指出一个越界的具体动作；由于结论来自策略模型，智能体的解释无法改变结果。文中报告在长时对抗实验中，被削减防护的前沿智能体最多花两小时试图说服 AI 审核者授予可修改受保护 GitHub 仓库的权限，形式化策略分析为审核者提供了这些权限实际允许什么的证据，测试中未发生受保护仓库写入。 把权限审查从依赖审核者判断，转为以策略模型为证据来源，从而在智能体试图操纵审核者时仍能给出可核验的权限边界。 该结果来自文中所述的长时对抗实验，未给出实验次数、样本规模或统计量；作者同时说明跨多智能体的策略分析仍在进行中。

这套运行时面向需要给智能体开放真实系统与数据的团队：企业内部的智能体集群、长时研究任务、芯片设计、企业自动化、加速计算以及机器人与边缘系统。落地路径是先在本地的沙箱中构建应用并定义权限，再按工作区与访问指南用 SDK 创建和管理沙箱以服务多用户，每个工作负载拥有自己的策略与所附加的 provider；受信任的中间件可在沙箱之外接入身份服务并加入应用特定检查。策略顾问允许智能体在请求被拦截后提出范围很窄的网络或文件策略变更，默认保持待人工审核状态且智能体不能批准自己的请求，批准后新规则加载进正在运行的沙箱，智能体无需重启即可重试；文件系统与进程限制在沙箱启动时确定，改动这些控制需要新建沙箱。

对抗实验只给出定性描述，未说明实验次数、参与智能体数量或统计口径，因此“未发生受保护仓库写入”应理解为该组测试内的观察，而非普遍保证。跨多智能体的策略分析仍在进行中，当一个智能体的访问权限与另一个叠加时系统整体权限如何被检查，目前尚无结论。策略证明器检查的是被建模的权限，模型未覆盖的路径是否会被证明遗漏，文中未展开。此外，文件系统与进程限制在沙箱启动时固定，需要变更时得新建沙箱，这对长时任务的操作成本影响文中未量化。