NVIDIA OpenShell：让智能体权限受策略控制——当前值得测试到什么程度

NVIDIA OpenShell 是 NVIDIA 为降低自主智能体失控风险而推出的新方案中，面向开发者的开源部分。它把 Codex、Claude Code、OpenCode 和 GitHub Copilot CLI 等智能体放进沙箱，再对它们可以访问的文件、能够运行的程序、可以连接的网络目的地，以及能够使用的凭据施加规则。

这个定位很重要，因为许多智能体安全讨论仍然从模型本身开始。OpenShell 则从更底层的一层开始。它假设模型可能误解请求、遵循仓库中的恶意指令、执行危险的 shell 命令，或者把工作交给子进程。于是，真正需要回答的问题变成：最终运行起来的工作负载，在技术上到底被允许做什么。

NVIDIA 于 2026 年 9 月 28 日公布了更广泛的 Open Agent Safety Platform。该平台还包含 Sentry，这是一个与 NVIDIA 硬件相关的独立监控与遏制设计。OpenShell 则是开发者可以检查、运行，并部署到多种基础设施选择上的部分。它采用 Apache 2.0 许可证，但仍是一个处于早期阶段的项目，存在运维复杂度、主机要求，以及需要谨慎测试的策略模型。

实际建议很直接：OpenShell 值得用于安全实验、本地智能体评估和受控开发流程；但现在还不宜把一次成功的快速入门过程当成智能体已经适合生产环境的证明。

当前切入点：智能体边界本身就是产品

OpenShell 的代码仓库把它描述为面向自主智能体集群的运行时。这和智能体框架是不同的主张。它不负责决定智能体如何规划任务、哪一个模型生成下一步，或者开发者应该如何组织编排图。它位于既有工具链的下方，试图让这套工具链始终处在预先声明的运行边界内。

这个区别很容易被忽略，因为项目恰好出现在智能体大量发布的时期。典型的编码智能体可以读取代码检出目录、编辑源文件、安装依赖、调用软件包仓库、使用 Git、访问云 API，并启动子进程。提示词可以要求它谨慎，但提示词不是强制执行机制。一个从 README 或 issue 中收到恶意指令的智能体，仍可能拥有周围 shell 授予它的全部权限。

OpenShell 改变了表达这些权限的位置。操作者用 YAML 编写策略；运行时再把策略转化为由内核、沙箱监管器和网络代理共同执行的控制。模型依然可能作出错误决定，但这个决定必须通过工作负载实际获得的权限。

这比再列一张支持模型清单更有开源价值。项目正在验证：智能体权限能否变成可移植、可审查的配置。如果可行，同一套策略可以随沙箱镜像迁移，也可以在拉取请求中审阅；如果不可行，项目就会变成又一层配置，只要它妨碍任务，开发者就会绕过。

OpenShell 实际控制什么

核心策略包含多个领域，而且它们的行为方式并不相同。评估者首先需要理解的，正是这些控制何时生效。

filesystem_policy 定义哪些路径可读、哪些路径可写。项目使用基于 Landlock 的控制来限制文件系统访问。文件系统和 Landlock 设置会在沙箱启动时应用，因此修改它们并不等于在运行中的工作负载上修改一条网络规则。一个策略可以允许智能体写入项目目录和临时目录，同时把凭据、SSH 密钥、浏览器配置文件以及无关的主目录数据排除在视野之外。

process 部分控制创建沙箱时采用的身份和进程条件。目标是避免工作负载把普通编码任务直接变成提权演练。不过，这仍取决于选定的运行时和主机配置；策略文件不会抹掉 Docker、Podman、Kubernetes、虚拟机或底层操作系统原有的安全假设。

network_policies 控制出站访问。OpenShell 对沙箱连接采用默认拒绝模型，然后允许指定的目的地，并在配置时进一步限制到特定二进制文件。一条规则可以区分软件包管理器和 shell 命令，也可以区分 Git 客户端和通用 HTTP 客户端。这样，团队可以批准一条范围狭窄的工作流，而不是把相同的出站能力交给每个进程。

网络层还可以在更高层检查请求。NVIDIA 的示例允许 curl 读取 GitHub REST API，同时拒绝写入请求。关键点在于，允许访问某个主机，并不必然等于允许对该主机执行所有操作。策略可以同时描述端点、端口、协议、获准的二进制文件，以及只读或写入权限。

network_middlewares 提供了另一个用于检查、转换或阻断的位置。实践中，这使策略能够比传统防火墙规则更具体。项目文档描述了针对 HTTP、GraphQL 和 Model Context Protocol 流量的控制。这并不意味着所有应用协议都同样成熟，或都同样容易表达；它表示运行时的设计目标是理解请求，而不只是理解 IP 地址和端口。

最后，提供商配置文件负责凭据和获准的服务访问。理想模型不是把原始密钥交给智能体，让它在任何地方使用。OpenShell 把真实凭据留在工作负载之外，检查目的地和策略，并且只在请求获准时注入凭据。一个可以用于 GitHub 只读 API 路径的令牌，不应自动变成沙箱中每条命令都能使用的通用秘密。

对于编码智能体来说，这道边界尤其重要。工具可以被禁止读取本地令牌，同时仍获得范围很窄的远程服务访问权。这不是服务自身权限的替代品，而是在智能体如何使用这些权限的外围增加一道控制。

一份小策略比营销说法更有信息量

评估 OpenShell 最有用的方式，是从一个刻意平淡的任务开始。创建一个没有出站网络访问的沙箱，执行一个无害请求，例如调用公共 GitHub API。确认请求被阻断并检查日志；随后应用一条允许访问 GitHub 只读端点的策略，再次执行请求；最后尝试写入操作，确认只读规则会拒绝它。

简化后的策略形状如下：

version: 1
filesystem_policy:
  include_workdir: true
  read_only:
    - /usr
    - /lib
    - /etc
  read_write:
    - /tmp
landlock:
  compatibility: best_effort
network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

这不是生产策略，而是让控制机制变得可见的方式。它也说明了为什么应该用测试而不是截图来评估项目。问题不在于 YAML 是否存在，而在于：在团队计划部署的确切运行时、镜像、二进制路径、凭据配置和主机配置下，本应被拒绝的请求是否真的会被拒绝。

OpenShell 文档称，静态控制会在沙箱创建时锁定，而网络控制可以在沙箱运行期间修改。这有利于渐进式审批：智能体可以从无网络状态开始，请求某项具体服务，然后在无需重启的情况下获得经过审查的更新。但这也带来治理问题。动态策略变更可能在长期会话期间扩大访问范围，因此审批路径、审计记录和回滚行为与初始策略同样重要。

项目包含策略顾问和策略证明器，用于审查拟议的访问权限。其承诺是，在变更应用前，可以检查它是否带来了新的权限。这是有价值的方向，但策略的形式化验证，并不等于验证策略是否表达了业务意图。一条形式上有效的规则，仍可能放行错误的仓库、错误的 API 方法，或者权限超出任务所需范围的凭据。

现在适合谁来尝试

对于已经让智能体拥有重要本地权限，并希望衡量“提示词层面的谨慎”和“运行时强制执行”之间差异的人，OpenShell 很合适。安全工程师可以用它构建可复现的智能体逃逸与数据外泄测试。平台团队可以研究策略如何从开发者笔记本迁移到 Kubernetes 网关。智能体工具维护者则可以测试自己的进程树、网络调用和提供商集成，在受限环境中会如何表现。

它也适用于处理非本团队创建的仓库的开发者。陌生代码库可能包含安装脚本、生成文件、依赖钩子，或专门针对自动化工具编写的指令。一个只开放狭窄工作目录、且默认没有出站访问的沙箱，可以为检查这些材料提供更安全的位置。保护并非绝对，但可以降低误执行命令的后果。

评估本地模型的研究人员同样会受益于这种分离。OpenShell 可以让智能体使用本地推理或云端推理，同时把工作负载的文件和出站请求置于策略之后。这样，实验可以比较不同模型，而不必每次都改变整台主机环境。

如果目标是开箱即用的企业控制平面，团队就应该更加谨慎。代码仓库包含网关、SDK、提供商处理、审计行为和 Kubernetes 部署路径，但把这些部分组合起来本身就是一个系统工程，涉及镜像管理、运行时权限、网络执行、身份、秘密、日志、事件响应和策略归属。安装 CLI 不等于这些工作已经完成。

主机和运行时仍然重要

当前快速入门面向 Linux、Apple Silicon 上的 macOS，以及实验性支持的 Windows WSL 2。项目预期使用 Docker、Podman 或主机虚拟化等容器或虚拟化底座。Kubernetes 可通过 Helm 部署，项目同时指出，集群网络层必须执行相关网络策略。

这些要求不是行政细节。沙箱的强度，取决于真正执行边界的那一层。团队应记录可用的内核特性、Landlock 不可用时会发生什么、容器引擎是否 rootless、工作负载仍保留哪些 capability、镜像如何构建，以及更新如何认证。同一份 YAML 在主机假设变化后，可能产生不同的实际结果。

项目策略文档包含 Landlock 的兼容性设置。这有助于适配不同环境，但宽松的兼容性选择不应被误解为每一项预期的文件系统限制都已生效。生产部署需要启动检查：要么在条件不足时安全失败，要么清楚报告安全姿态已经降低。

网络代理也是需要测试的依赖。如果智能体需要软件包仓库、Git 提供商、模型端点、issue 跟踪器或 MCP 服务器，每项服务都会扩大策略表面。允许一个宽泛域名可能很方便，却会削弱逐端点控制的意义；规则过窄又可能促使开发者添加一条全匹配例外。运维设计应让遵守狭窄规则比绕过控制更容易。

凭据代理很有前景，但不是魔法

OpenShell 的提供商模型针对一个常见故障模式：把用户可用的每个令牌都放进智能体的环境。通过把凭据留在沙箱外，并将它们绑定到获准目的地，运行时可以防止某项服务的令牌被发送到另一项服务。即使底层令牌技术上允许写入，也可以额外应用只读请求规则。

但这并不会消除凭据风险。服务仍需签发合理的令牌；提供商配置文件仍需正确设置；代理仍需识别它应该检查的流量。如果策略放行了相关 API 方法，那么一个有权删除仓库的凭据仍然危险。模型也依旧可能在获准范围内生成破坏性输出。

因此，最好的测试是一张矩阵，而不是一个成功案例。测试获准的读取、被拒绝的写入、未批准的主机、错误二进制文件发出的请求、过期凭据、格式错误的请求、子进程和子智能体。通过真实工作负载会使用的 SDK 或集成路径，重复同样的操作。然后检查审计输出，判断操作者是否能够还原发生了什么。

OpenShell 称会以 Open Cybersecurity Schema Framework 审计轨迹记录策略决定。这对事件响应有帮助，但日志只有在被收集、保留、保护而不被工作负载修改，并且与批准变更的人员或自动化身份关联时才真正有用。本地演示日志还不是企业审计系统。

项目没有解决什么

OpenShell 是遏制工具，不是对齐工具。它不能让不可靠的模型变得可靠，不能分辨微妙的业务错误和有效操作，也不能保证任务规范本身安全。如果智能体被允许修改生产部署，运行时可以准确执行这项权限，但模型仍可能作出灾难性的、却在技术上获准的变更。

它也不能取代身份提供商、秘密管理器、终端安全、漏洞管理、软件供应链控制、可观测性或人工审批。NVIDIA 自己的产品材料把 OpenShell 描述为能够与这些周边系统集成的智能体运行时边界。这是正确的理解方式：项目增加了一层，并没有让技术栈其余部分变得可有可无。

还有一个更基础的限制：策略质量决定了访问是否有用。无法读取正确文件或访问正确软件包仓库的开发者智能体，会以令人困惑的方式失败；拥有宽泛文件系统和网络权限的开发者智能体，可能运行顺畅，却几乎没有得到实质保护。工程难点在于定义仍能完成任务的最小权限，然后让例外明确且可审查。

公开讨论也从另一个方向提出了同样的担忧。有关这次发布的报道指出，限制性控制可能阻碍有用工作，需要更多案例来理解其中平衡。这不是驳回项目的理由，而是应该测试真实工作流的理由，而不是重复“智能体可以在毫秒内被隔离”这类说法。

独立的 Sentry 组件也需要在概念上分开理解。NVIDIA 把它呈现为硬件层面的监控与遏制层，而 OpenShell 是开放的运行时和策略边界。根据 NVIDIA 及发布相关报道，OpenShell 可以运行在包括 Arm 和 Intel 在内的非 NVIDIA 计算平台上。评估开源项目时，不应假定它自动具备 NVIDIA 更大平台的全部属性。

许可证与项目成熟度

OpenShell 代码仓库标明采用 Apache License 2.0。这是基础设施和开发者工具项目熟悉的宽松许可证，便于检查、修改和集成，但仍需遵守许可证要求，以及被获取材料、容器镜像、模型、提供商和第三方组件各自附带的条款。

代码仓库还包含安全政策和第三方声明。这些文档应成为采用评估的一部分。项目自身的免责声明指出，软件检索或访问的材料受其独立条款约束，用户负责检查其安全性、完整性和适用性。实际而言，开放运行时并不会让其中运行的每个镜像、技能、插件、模型或脚本都值得信任。

项目成熟度应根据发布记录和 issue 历史判断，而不能只看仓库背后是否有大型公司。OpenShell 的表面很广：CLI、本地网关、沙箱驱动、策略模式、代理行为、提供商凭据、SDK、Helm 部署、推理路由和智能体技能。每个组件都会带来兼容性与安全问题。早期采用者应固定版本，保留可丢弃的测试环境，审查版本间变化，并保留回滚路径。

遥测值得单独检查。代码仓库称，OpenShell 默认收集匿名的运行类别和计数，同时排除名称、主机名、文件路径、提示词、凭据、提供商名称、模型名称和用户内容。它也记录了关闭遥测或在编译时移除遥测的方式。这比完全沉默更有用，但有严格隐私要求的组织仍应验证实现和自己的构建配置，而不是只依赖摘要说明。

替代方案与互补方案

OpenShell 并不是降低智能体权限的唯一方式。一个不挂载主机目录的最小容器，可能已经足够应对狭窄的构建步骤。rootless 容器、microVM、专用虚拟机、远程开发工作节点或 CI 作业，也能提供不同的隔离取舍。团队如果需要更小的控制面，也可以直接使用 Landlock 和 seccomp 等 Linux 原语。

这些方法解决的是问题的不同部分。容器和 Pod 提供运行时底座；microVM 可能提供更强的隔离边界，但代价是启动时间和镜像管理；CI runner 适合可重复作业，却可能不适合交互式开发；直接使用内核策略可以较轻量，但团队需要自行构建凭据代理、网络中介、生命周期管理和审计惯例。

OpenShell 的主张是，智能体工作负载需要把这些部分协调起来。策略不仅应描述进程能读取什么，还应说明哪个可执行文件可以调用哪个端点、哪个凭据绑定到该端点、运行中的策略如何变化，以及结果如何记录。这种协调正是项目存在的主要理由。

因此，正确的比较不是 OpenShell 对 Docker，而是“OpenShell 加运行时”对“只有运行时”，并衡量额外策略和网关组件带来的复杂度。对于简单的不可信构建命令，OpenShell 可能没有必要；对于能浏览仓库、安装工具、调用 API，并在长会话中启动子进程的智能体，增加这一层可能值得。

一套合理的评估计划

从可丢弃的主机和小型仓库开始。记录主机操作系统、内核特性、容器引擎、OpenShell 版本、沙箱镜像、智能体版本和提供商配置。不要一开始就使用生产凭据，或包含无关秘密的项目。

创建基线沙箱。确认哪些文件可见、哪些路径可写、进程由哪个用户拥有，以及命令尝试访问网络时会发生什么。从智能体本身、智能体启动的 shell，以及子进程中分别执行相同检查。

一次只增加一项服务。批准只读的软件包或 Git 服务，比直接开放不受限的网页访问更适合作为起点。测试正向路径和多个负向路径。把策略放入版本控制，像审查代码一样审查策略，并写明每个获准端点和二进制文件为什么必要。

接着在会话期间测试策略变更。确认哪些部分需要新建沙箱，哪些部分支持热加载。验证在获准变更真正应用之前，被拒绝的请求仍然会被拒绝。测试回滚和故障处理。当网关不可用、策略格式错误、提供商缺失或网络请求超时时，也应评估访问控制系统的表现。

最后模拟一次事件。向智能体提供仓库指令，要求它搜索秘密、调用未批准端点，或修改工作树之外的文件。目的不是为了娱乐而欺骗模型，而是确认边界能否阻断操作，错误是否易于理解，事件是否会被记录，以及操作者能否在不摧毁会话的情况下收紧策略。

结论

NVIDIA OpenShell 有意思之处在于，它把智能体权限视为基础设施问题，而不是系统提示词中的承诺。它采用 Apache 许可证，提供声明式策略、以内核为后盾的文件系统控制、网络中介、提供商凭据和网关模型，给开发者留下了可直接测试的对象。项目也很自然地接入开源生态：支持多个智能体工具链，提供 SDK，记录了 Kubernetes 路径，并能运行在不止 NVIDIA 一家的硬件上。

谨慎同样有具体依据。项目不是通用安全系统，策略可能难以设计，主机假设需要验证，而广泛的功能范围会提高认真部署的成本。默认拒绝网络规则只有在例外保持狭窄时才有用；沙箱只有在主机和镜像都被理解时才有用；凭据代理只有在提供商权限和请求检查经过测试时才有用。

对于 Open Source Radar 读者，合理的下一步是实验室试用，而不是迁移到生产环境。用 OpenShell 为当前权限过大的智能体工作流构建可重复的测试工具链，测量被阻断的操作、误报、启动行为、策略审查、日志和恢复能力。如果这些控制经受住测试，又没有把每项任务都变成审批队列，OpenShell 可能成为更安全智能体开发的实用基础；如果没有通过，实验仍会准确揭示工作流依赖环境权限的地方，而这正是大多数智能体项目都需要知道的信息。

来源

本文依据 NVIDIA OpenShell 代码仓库与 README、OpenShell 沙箱策略文档、NVIDIA Technical Blog 的 OpenShell 介绍、NVIDIA 产品概览与 FAQ、OpenShell 许可证、Associated Press 对该发布的报道，以及 Hacker News 相关讨论背景进行编译与改写。