BLOG

技术拆解 029｜NVIDIA OpenShell：给 AI Agent 的安全运行时

Kael Zhang
AIOpenShellsecurity
广告 · Advertisement

一、这是什么

OpenShell 是 NVIDIA 在 2026 年推出的开源安全运行时，专门用来约束 autonomous AI agents。它的基本主张是：agent 可以执行任务，但不能无限制地访问你的文件、网络和凭证。项目仓库位于 GitHub 的 NVIDIA/OpenShell，截至 2026 年 10 月约有 17.7k 星、1.8k fork，协议 Apache-2.0。仓库主体是 Rust，共有 745 个 .rs 文件、约 65.1 万行代码，分 36 个 crate。

它不是一个聊天模型，也不是 agent 框架，而是 agent 下面的“笼子”。你可以把它理解成给 Claude Code、Codex、OpenCode、Copilot CLI 这类 coding agent 套上的一个隔离层。agent 仍然负责推理和调用工具，但能不能读文件、能不能连网、能不能用 API key，由 OpenShell 的策略说了算。

NVIDIA 把它定位为“Open Agent Safety Platform”的软件底座。完整的参考架构还包括 Vera CPU 和 BlueField-4 DPU 上的 Sentry 监控。软件部分可以独立运行在任意 Linux、macOS Apple Silicon 或 WSL2 上；硬件增强部分则需要 NVIDIA 的芯片栈。

为什么现在需要这个？因为 agent 的工作方式正在变化。以前的 AI 工具大多是“一问一答”，现在的 coding agent 可以连续运行几十分钟，调用 shell、读取代码、安装依赖、调用 API。一旦 prompt 被注入或模型产生幻觉，agent 可能把内部代码发到公网、用掉你的云配额、甚至修改生产配置。OpenShell 要做的，就是给这种长时间、高权限的运行提供一个可审计、可强制执行的边界。

从更宏观的视角看，OpenShell 也在回应一个行业焦虑：当 agent 从“辅助工具”变成“自动化员工”时，谁来决定它能做什么、不能做什么？靠模型自身的安全对齐显然不够，因为 agent 的任务本身就可能需要执行危险操作。OpenShell 的回答是：把权限策略外置，用运行时强制执行，让安全团队可以像管理防火墙规则一样管理 agent 的边界。

二、核心机制

OpenShell 的核心架构可以拆成三层：Gateway、Supervisor、Sandbox。

Gateway 是控制平面，负责管理沙箱生命周期、用户认证、策略下发。Supervisor 与每个沙箱配对，运行在工作负载外面，是所有出站请求的必经之路。Sandbox 则是实际运行 agent 的隔离环境。源码里对应的主要 crate 分别是 openshell-gateway、openshell-supervisor、openshell-sandbox，其中 openshell-supervisor/src/lib.rs 超过 7200 行，openshell-sandbox 下的 src/linux/landlock.rs、src/linux/seccomp.rs 负责 Linux 上的内核级限制。

策略用声明式 YAML 书写。一个简单的网络策略长这样：指定哪些二进制可以访问哪些 host、端口、HTTP 方法，读还是写。策略分为静态域和动态域：文件系统、进程身份在沙箱创建时锁定；网络、provider、inference 规则可以在运行时热加载。官方 quickstart 里 examples/sandbox-policy-quickstart/policy.yaml 就是一份完整示例，默认只允许 curl 只读访问 GitHub API。

运行时，OpenShell 在网络路径上做了一次关键设计。agent 发出的每个出站连接都会经过 supervisor 里的 HTTP CONNECT 代理。源码 crates/openshell-supervisor-network/src/proxy.rs 处理这个过程，crates/openshell-supervisor-network/src/opa.rs 则内嵌了 OPA 引擎，把 YAML 策略编译成 Rego，再对每个请求做 Allow / Deny / Route for inference 的判断。OPA 评估被设计为微秒级，不会成为代理瓶颈。

凭证处理是另一个重点。OpenShell 不把 API key 写进沙箱镜像或文件系统，而是通过 Provider 机制在运行时绑定。只有当请求匹配了被策略允许的 endpoint，对应的凭证才会作为环境变量注入。这样即使 agent 被攻破，拿到 key 的路径也少了一条。相关实现在 crates/openshell-core/src/provider_credentials.rs。

最后还有形式化验证层。openshell-prover 把 policy、binary capabilities、credential scopes 编码成 Z3 SMT 约束，在策略变更前检查是否存在越权或数据外泄路径。源码入口在 crates/openshell-prover/src/lib.rs，底层依赖 z3 crate。这意味着在策略生效前，可以先跑一遍证明，确认没有引入新的风险开口。

从隔离实现看，Linux 上用的是 Landlock 限制文件系统、seccomp 过滤系统调用、namespace 做进程隔离。openshell-sandbox/src/linux/landlock.rs 处理路径允许列表，src/linux/seccomp.rs 处理 seccomp notify，让 supervisor 在用户态仲裁一些敏感调用。这种组合让沙箱不需要完整虚拟机，也能做到比较紧的约束。

计算后端也是模块化的。openshell-gateway/src/lib.rs 按平台条件编译注册不同的 compute driver：Docker、Podman、Kubernetes、VM（libkrun）、Windows MXC。这种设计让同一套策略模型可以跑在不同隔离后端上，开发测试用 Docker，生产可以切到 K8s 或 MicroVM。

二进制身份是另一个容易被忽略的机制。OpenShell 会识别发起网络请求的可执行文件身份，结合进程树和 /proc/<pid>/cmdline 信息，判断某个请求是否来自被允许的二进制。这样即使 agent 通过解释器启动子进程，策略也能追踪到真正的脚本来源。相关逻辑在 openshell-binary-identity 和 supervisor 的 network proxy 中都有体现。

三、技术评估

OpenShell 的技术路线非常清晰：把安全边界放在 agent 外部，用 kernel 和策略引擎做强制隔离，而不是寄希望于模型自我约束。这与传统“容器隔离”最大的区别在于精细程度和凭证模型。

普通容器通常只能做到网络通或不通，而 OpenShell 可以细到 HTTP 方法、路径、二进制身份。例如同一个 GitHub API，它可以允许 GET /zen 但拒绝 POST issue。容器里的 API key 一旦注入就全程可见，而 OpenShell 的 Provider 绑定只在请求命中授权 endpoint 时才注入凭证，缩小了泄露窗口。

从代码规模看，36 个 crate、65 万行 Rust 说明这是一个正儿八经的大型工程，不是概念验证。其中网络代理和 OPA 集成 openshell-supervisor-network 接近 1.5 万行，OPA 引擎文件超过 1.2 万行，sandbox 边界相关代码超过 7000 行，prover 也有几千行。NVIDIA 官方博客给出的 CoreWeave 数据是：Vera CPU 上 sandbox 启动速度比 x86 快 3 倍以上，agentic loop 完成速度快 1.8 倍，单 rack 可支撑超过 11000 个并发 agent 环境。这些数字来自厂商自测，可作为参考，但不宜当作通用 benchmark。

与其他隔离方案相比，OpenShell 的定位介于容器和完整虚拟机之间。Docker 只提供进程级隔离，配置简单但粒度粗；Firecracker MicroVM 提供接近虚拟机的隔离，但启动和集成成本更高；gVisor 在用户态实现系统调用拦截，兼容性好但性能有损耗。OpenShell 选择了一条中间路线：用 Landlock/seccomp 做轻量隔离，用 supervisor 做 L7 代理和凭证管理，用 OPA 做策略表达。这条路在 coding agent 场景下比较贴合，因为 agent 需要频繁文件访问和网络调用，但又不能拥有整个宿主机的权限。

短板也很明显。首先是成熟度，目前版本 0.1.x，虽然 README 已改为稳定发布线，但 Kubernetes 支持仍标为实验性，部分早期宣传页面仍写着 “Alpha software — single-player mode”。其次是形式化验证的覆盖范围，prover 能证明的是策略模型内的性质，而 LLM 的非确定性、提示注入、未被建模的交互路径并不在证明范围内。第三是部署复杂度：要真正跑起来，需要 Docker 或 Podman、 Landlock 支持的 Linux 内核，或者 Vera/BlueField-4 的完整参考架构，普通开发者本地体验可以，但企业生产落地需要不小的集成成本。

生态方面，OpenShell 已经公开了可安装的 agent skills，放在 skills/ 目录，可以通过 npx skills add NVIDIA/OpenShell 安装。这些 skill 教 coding agent 如何写策略、调试 gateway、排查 inference 问题。仓库本身也是用 agent 驱动的工作流开发，.agents/skills/ 里有 triage、security review、spike-build 等自动化流程。

四、价值判断

OpenShell 解决的是一个真问题：当 agent 能写代码、能调用 API、能长时间运行时，怎么防止它“顺手”把内部代码发到外部、把 API key 写进日志、或者因为提示注入去执行不该执行的命令。

它的价值主要体现在三个场景。第一是安全 coding agent：给 Claude Code、Codex 等工具一个受限环境，只能访问指定仓库和 API。第二是去外泄的 inference 路由：把模型调用强制转发到企业可控的 endpoint，而不是让 agent 自己决定连哪个模型。第三是合规审计：所有 allow/deny 都写入 OCSF 格式日志，满足安全团队对可观测性的要求。

从适用人群看，最需要 OpenShell 的是那些已经让 agent 接触真实代码库、真实 API、真实基础设施的团队。对于个人开发者，风险敞口小，装不装差别不大；但对于拥有大量私有代码、客户数据、云资源的企业，agent 的一次误操作可能带来真实损失。OpenShell 把这类风险从“不可控”变成“可策略化”。

但边界也很清楚。它不能阻止 agent 在已授权范围内做坏事，比如被允许读取的文件恰好包含敏感内容；它也不能替代代码审查、模型安全测试、供应链安全。换句话说，OpenShell 管的是“能不能做”，而不是“做得对不对”。

另一个需要注意的点是，它的真正威力在组合硬件栈时才会放大。单独的 OpenShell 已经能提供软件边界，但如果搭配上 BlueField-4 DPU 和 Sentry，就能实现硬件级的、agent 无法触及的监控和隔离。对于金融、医疗、芯片设计等高风险场景，这种软硬结合的路径才最有吸引力。

五、如何落地

安装很简单，一条命令即可：

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

然后创建沙箱：

openshell sandbox create --name demo --policy examples/sandbox-policy-quickstart/policy.yaml

沙箱默认几乎不能连外网。要允许 agent 访问某个服务，需要编辑 YAML 策略并执行 openshell policy set 或 openshell policy update。如果想跑真实 agent，可以用 openshell sandbox create -- claude 或 -- codex，OpenShell 会自动识别本地已配置的 ANTHROPIC_API_KEY、OPENAI_API_KEY 等凭证。

Provider 的自定义流程也值得了解。先用 openshell provider profile import 导入一个 provider profile，声明允许访问的 endpoint 和所需凭证；再用 openshell provider create 创建 provider 实例；最后在创建沙箱时通过 --provider 附加。这样沙箱内的 agent 看到的是占位符变量，真实 key 由 supervisor 在请求通过策略检查后注入。

对于想集成到 CI/CD 的团队，OpenShell 提供了 GitHub Actions 示例：在 workflow step 里安装 CLI，用版本控制的 YAML 策略创建沙箱，跑完 agent 后加上 --no-keep 自动销毁。这样安全策略本身也可以被代码审查和审计。

选型建议：如果你已经在使用 Claude Code / Codex / OpenCode 等 coding agent，并且担心它们无限制访问本地文件或网络，OpenShell 值得试用。如果你是普通开发者、只偶尔用用 AI 辅助编辑，那它的收益可能抵不上部署成本。如果你的目标是生产环境大规模 agent 集群，建议等 Kubernetes 支持更成熟后再评估。

六、如何自己做一套类似的方案

如果不使用 OpenShell，想要自己搭一套 agent 安全运行时，可以从这六步开始：

  1. 选一个轻量级隔离后端，比如 Docker、Podman 或 Firecracker MicroVM，给每个 agent 一个独立容器。
  2. 默认拒绝所有出站网络，再用代理拦截所有 HTTP/HTTPS 请求。
  3. 把策略写成 YAML 或 JSON，声明哪些二进制、哪些用户、哪些 endpoint 可以被访问，以及读、写、POST、GET 等权限。
  4. 把 API key 放在沙箱外面，由代理在请求命中白名单时注入，而不是在启动时塞进容器。
  5. 用 seccomp 或 Landlock 限制文件系统访问范围，禁止 setuid、sudo 等提权行为，同时只暴露 agent 真正需要的只读路径。
  6. 记录所有 allow/deny 日志，并定期审计策略变更。

第 3 步最容易被低估。很多团队以为写一个“允许访问 api.github.com”就够了，但真正投产时需要细化到 method、path、binary identity。没有这些维度，agent 仍然可以通过不同的工具或脚本绕过初衷。第 5 步也需要注意：只读路径如果包含 .env 或 ~/.ssh，仍然可能泄露密钥，所以最小权限原则要贯彻到底。

这套方案比不上 OpenShell 的 OPA/Rego 深度、prover 形式化验证和 NVIDIA 硬件生态，但对于中小团队已经能覆盖 80% 的典型风险。

结论

OpenShell 是 agent 安全基础设施里值得认真看的一手棋。它不是模型安全，也不是应用安全，而是把安全边界建在了运行时层。对于要让 agent 真正干活的团队来说，这一步迟早要走。当前 0.1.x 版本适合尝鲜和小范围试点，大规模生产落地建议持续关注 K8s 成熟度和社区生态。

参考来源

广告 · Advertisement

常见问题

OpenShell 和普通沙箱有什么区别？

OpenShell 把策略定义、证明、强制执行分成独立模块，策略可以跨硬件复用。

它能阻止所有 AI 代理风险吗？

不能。它主要解决权限边界和可审计性，模型本身的价值观对齐仍需其他机制。

什么场景下最值得用？

需要让 coding agent 长时间、高权限运行，但又不能让它无限制访问网络和凭证的场景。