NVIDIA 的 OpenShell 把 agent 的权限管到了内核里

NVIDIA 的 OpenShell 这个月在 GitHub 上收了大约 8,000 颗星。对一个基础设施项目来说，这个关注度有点反常。它是给自主 agent 用的运行时，用 Rust 写，Apache 2.0，做了一件说起来容易、做起来很难的事：在内核层面强制一个 agent 能碰什么，并且在一条策略变更生效之前对它做形式化验证。

它解决的问题，会在你第一次给 agent 真实凭证的时候出现。一个 agent 只有能读文件、装包、调 API、用密钥才有用。而在那一刻，它同时也是一个拿着你钥匙、连着你的网络的程序。大多数团队用一个容器加一次祈祷来处理这件事。

这个“强制”到底长什么样

OpenShell 把每个 agent 跑在一个隔离沙箱里，并给内核埋点，在运行时检查每一次文件访问、系统调用和网络连接。连接在离开沙箱之前就被检查。凭证根本不会交到 agent 手上：OpenShell 把它们注入到发往已批准端点的请求里，于是一次把 agent 环境全倒出来的提示词注入，拿回去的是空的。

更不常见的功能是策略证明器。在一条策略变更被批准之前，OpenShell 用形式化验证找出这次变更会新授予什么访问权限，比如用凭证去连一台新主机，或者调用一个新的 API 方法。这类变更会等人来审。

这是一个真正的设计决定，而且它把常规流程倒了过来。大多数沙箱工具让你事先写好策略，然后痛苦地发现你漏了什么。OpenShell 让 agent 边干边申请权限，并在生效前把 diff 给你看。这更好还是更差，取决于你有多信任自己周五晚上六点的评审流程。

装上它

快速开始是一行、一条命令：

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh，然后 openshell sandbox create --name demo。安装器会装好 CLI 和一个本地网关。

第一道真正的障碍是环境要求：Linux、Apple Silicon 上的 macOS，或者通过 WSL 2 的 Windows——后者项目自己标为实验性。你还需要有 Docker、Podman 或主机虚拟化可用。如果你的团队在没有 WSL 的 Windows 上开发，这就不是五分钟能装完的东西。另有一条通过 Microsoft MXC 的原生 Windows 路径，文档在侧分支里，有它自己的限制；在你承诺支持 Windows 之前，这一段值得先读。

默认沙箱镜像是一个精简的 Ubuntu，里面没装 agent。要跑点真东西，文档里走了一遍用 OpenCode 对接 OpenRouter 免费模型的流程，包括 agent 撞墙、你批准它需要的新权限那一段。那份演示是整个仓库里最有用的一页，因为它把审批闭环演出来了，而不是描述它。

如果你想从代码里驱动它，也有 SDK：Python 用 uv add openshell，TypeScript 通过 GitHub Packages 安装，另有 Go 和 Rust。还有一套 agent skills，用 npx skills add NVIDIA/OpenShell 安装，教一个编码 agent 去驱动这个 CLI 并写策略。这个细节比听起来有意思。项目指望 agent 帮忙配置自己的笼子，这要么很高效，要么很吓人，取决于策略证明器前面那个审批环到底有没有被用起来。

运维账单

任何给内核埋点的东西，部署故事都比一次 pip install 复杂，OpenShell 对此是诚实的。有一个网关、一个 supervisor，还有沙箱本身。上 Kubernetes，你要用 Helm 部署网关，而你的 CNI 得真的执行 NetworkPolicy——这句话毁掉过很多个下午。如果你集群的网络插件无视这些规则，沙箱边界就是一份文档，而不是一个控制点，而你要等到出事那天才会知道。

版本号说明了它在哪。0.1.x 这条线引入了稳定的发布节奏、新的隔离原语和新的 API，也就是说 API 表面还在动。现在采用的团队应该预期有升级工作。

遥测默认开着。NVIDIA 说它只限于运营类目和计数，不包含沙箱名、主机名、文件路径、提示词、凭证、供应商或模型名，也不包含用户内容。你可以在网关上用 OPENSHELL_TELEMETRY_ENABLED=false 关掉，Helm 安装则用 server.telemetryEnabled=false。在企业评审里，这个开关是第一个会被问到的东西，所以在开会前先知道它在哪。

现在谁需要它

如果你只在自己笔记本上跑一个编码 agent，你不需要 OpenShell。爆炸半径就是你自己的机器，而你在装那个 agent 的时候已经接受了这个风险。

如果你跑的是一群 agent，它们会碰生产数据、客户记录，或者一个挂着真实账单的云账号，算法很快就变了。让安全团队睡不着的失效模式，不是一个模型说了难听的话。是一个拿着有效 token 的 agent，在一个“它被告知的内容”受了它读过的一个网页影响的环境里，精确地照吩咐做事。

OpenShell 和一个普通 Docker 容器的区别，在信任边界的位置。容器限制 agent 能看见什么。OpenShell 限制它能做什么，在网络边缘做检查，并把凭证放在 agent 够不到的地方。这是一个明显更强的位置，代价是你要运维一个网关、维护一份策略文件，外加一个半夜可能把你叫起来的东西。

值得盯的那一点

我会盯的是形式化验证这一块。如果策略变更能在生效前被检查，那有意思的问题就变成这个检查在实践中是否有用：它能不能抓住要紧的那些变更，同时会不会对不要紧的保持安静。一个什么都报的证明器会被一路点过去，一个什么都不报的证明器则是装饰。

NVIDIA 有信誉也有动机把它维护下去，而 agent 安全这个市场足够大，它不会只有这一个选项。就现在而言，如果你正在做 agent 产品里“决定它被允许碰什么”的那一部分，这是你能读到的最具体的实现。哪怕你从不安装，读一读它的策略模型也值得花一个小时，因为它逼你回答一个大多数 agent 项目跳过的问题：这个东西到底被允许做什么，以及是谁决定的。