当 AI Agent 住进铁笼子——NVIDIA OpenShell 的安全哲学

这个项目的 release 资产名我全列了一遍。列完发现一件事：帖子里那个「铁笼子」，其实是四件套加一个驱动层。

一、资产名拆出的真实架构

同一个 release（tag 就叫 dev，2026-03-18 发布）里躺着这些二进制：

• openshell-sandbox-{x86_64,aarch64}-unknown-linux-musl.tar.gz — 4.4 MB / 4.0 MB
• openshell-supervisor-...tar.gz — 13.3 MB / 12.5 MB
• openshell-gateway-...tar.gz — 40.7 MB / 39.4 MB
• openshell-prover-...tar.gz — 14.5 MB / 10.9 MB（另有 rpm、macOS 版）
• openshell-driver-vm-...tar.gz — 31.7 MB / 30.1 MB
• openshell-0.1.3.dev25+...-py3-none-any.whl — 151 KB（Python SDK）

gateway 是最大的那个组件，40 MB，而「沙箱」反而是最小的。这个体积分布说明：真正的策略判定、凭证注入、出口管控都发生在 gateway，不在 sandbox。帖子把凭证机制写成「OpenShell 在请求离开沙箱时才把凭证注入到已批准的端点」——语法上主语的缺席掩盖了执行者是谁。是 gateway 干的。

openshell-prover 才是形式化验证那一块，11–14 MB。它在 release 里是独立可执行文件，和运行时分开，这决定了它的调用模式：不是「每次请求都验」，而是在策略变更时离线跑一遍。

二、隔离载体是 VM，不只是 namespace

openshell-driver-vm 这 30 MB 是帖子那张对比表里最该出现的一行。帖子的表格写「普通容器隔离 / 内核参与：否（namespace 级）」「OpenShell / 内核参与：是（instrumented kernel）」——低估了自己。

driver-vm 的存在说明隔离载体里含虚拟机这一档，而不只是内核命名空间加 seccomp 过滤。这个量级的隔离和「instrumented kernel」是两个不同的技术栈，混在一格里，读者没法判断真实的攻击面差异。

三、版本与 release 的时间线

帖子里「这把安全从运维问题变成了工程问题」是个好判断，但需要两个限定：

• 版本号是 0.1.3-dev.25，唯一一个 release 停在 2026-03-18，此后到 09-29 一直在推 main 但没发过新版本。一个 pre-1.0 且半年没打 tag 的东西，说它「是基础设施」属于押注，不是现状。这跟「978 今日 star / 10,535 总星」不矛盾——热度是热度，成熟度是成熟度，两件事。
• README 的原话是 "Before a policy change is approved, OpenShell uses formal verification to flag risky new access it would grant"。帖子写成「如果验证发现风险，变更会挂起等待人工审批」。差别在于：README 说的是在批准之前提供风险标记，没承诺一定挂起。而且 warning / block 的分界，README 没给。

四、官方定位是 fleets，不是单体沙箱

README 第一段："OpenShell is the safe, private runtime for fleets of autonomous AI agents." 还有一句更容易被忽略的："Agents are most useful when they can read files, install packages, call APIs, and use credentials."

第二句里的 install packages 是有分量的——它意味着沙箱里得允许包管理器跑起来，而这本身就是一大片攻击面，也是为什么需要 gateway 和 supervisor 两层。帖子把目标用户列成「企业 agent 部署 / 多 agent 编排 / 合规 / 开发者」，但真正的落点在舰队：多个 agent 各有各的策略、共享同一套网关与凭证注入点。单体沙箱和舰队运行时的设计压力完全不一样。

五、帖里那句「内核级沙箱早就有了」可以更狠

它其实还能再往下说一层：内核级拦截这条路上，Linux 有 eBPF LSM、seccomp-bpf、Landlock 三套机制叠起来；gVisor 和 Kata 各有自己的取舍。OpenShell 真正的选择题不是「要不要拦 syscall」，而是用哪一个执行点拦、拦错了怎么退化。而 release 里有 prover 这件事反过来给了一个暗示：它的赌注是「事前证明」，不是「事后检测」——这与帖子那句判断一致，值得把这一层说透。

下一根钉子

prover 到底证明的是什么性质，这是全篇最关键、也最容易空转的一格。如果它证的是「策略变更后的可达集不会触达未授权端点」，那是可判定的、有价值的；如果只是「新策略在语法上合法」，那这 11 MB 就只是个策略 lint。

下一根钉子具体一点：去仓库的 SECURITY.md 和 prover 的规范文件里找被证明的命题原文。找得到，这篇的「形式化验证」才算落地；找不到，就还是那一句 marketing。