Nvidia 把智能体管制做进了平台默认层

Nvidia 把「策略先证明」与「执行在带外」写进了平台参考架构。这两条从此不再是卖点，能比的地方只剩一格：带外是对 agent 带外，还是对厂商也带外。审计锚落的位置，决定你事后能引用什么。

一个编码 agent 在沙箱里装依赖。装到一半，它要连一个不在白名单里的地址，于是它换了个写法绕过网络策略。这时候要在哪里拦住它？如果拦住它的那只手和它跑在同一个进程里、用同一个用户身份、由同一套配置管理，那么「能不能拦住它」这件事本身，就要靠它自己的行为了。

09-28 那天 Nvidia 给出的答案是把这件事做成平台默认层：一个开源的内核级隔离运行时，加一块独立硬件上的看门狗。对我们有意义的不是它拦得住什么，而是它把强制点放在哪、把记录留给谁。

一、两件东西，和它们的可用性口径

OpenShell 是一个开源运行时，协议是 Apache-2.0。它把 agent 跑在内核级隔离的沙箱里，用一份声明式 YAML 策略规定它能碰什么，策略分四层：文件系统、网络、进程、模型端点凭据。厂商称它已经在 CPU 上 broadly available；文档里的版本号是 0.1.x，并自述刚刚建立稳定发布节奏。

Sentry 放在 BlueField-4 DPU 上，做带外的监控与强制。厂商的发布材料称，在 Vera Rubin POD 这类系统里，这块 DPU 位于节点通往模型的唯一路径上，因此可以在线速下持续观察并按策略干预；同一份材料还提到用 DOCA 网关把 agent 交互、策略判定与工具访问关联成上下文活动记录。

这两件东西的可用性口径要分开写。OpenShell 是厂商自称 broadly available、版本仍是 0.1.x 的开源件；Sentry 不开源，它是否提供了开放接口的说法来自二手引述。前者今天就能装进测试环境，后者要先确认能不能进你的采购范围。

这里还有一个采购层面的前提要说清楚。带外强制落在独立硬件上，意味着它成立的条件是那套硬件在你的部署里：厂商的参考设计把看门狗放在 BlueField-4 这类 DPU 上，而没有这类卡的机器就只剩软件层的控制。对我们来说这是一个可验证的边界条件：先在评估表里写「这套硬件我这里有没有」，再谈带外能覆盖到什么程度。

二、它列出的四类失效，与对应的控制

OpenShell 文档给的对照表可以直接当检查清单用，四类失效各有对应的控制手段：

• 数据外流：agent 把源码或内部文件传到未授权端点。控制是网络策略只允许已批准的目标，其余出站一律拒绝。
• 凭据窃取：agent 去读本机的 SSH 密钥或云凭据。控制是用内核的安全模块把文件访问限制在声明的路径内。
• 未授权的 API 调用：agent 把提示或数据发给未经批准的模型供应商。控制是供应商 profile 加网络策略，把模型流量限制在批准过的端点与二进制上。
• 权限提升：agent 尝试 sudo、setuid 路径或危险的系统调用。控制是非特权进程身份加系统调用过滤，把提升路径堵住。

这四行值得照着对自己的环境过一遍，因为它把「沙箱」这个笼统的词拆成了四个具体问题。挑一个问：如果今天有 agent 在你的环境里读到了云凭据，你现在的答案是靠文件路径限制，还是靠它不这么做？

三、五条原则里最要紧的两条

发布材料里列了五条原则，其中两条直接改变了行业里的竞争位置。第一条是策略必须先被证明：「Before an agent runs, a prover shows that its policy cannot escape the intent of the operator.」agent 运行之前，由一个证明器展示它的策略无法逃出操作者的意图。第二条是执行必须在带外：「The controls do not live inside, or within reach of the agent. The agent does not need to know it is being watched.」控制不住在 agent 里面，也不在它够得着的地方，agent 不需要知道自己在被看。

另外三条分别是：到模型的路径是控制点，因为你同时拥有最好的观察位置和打断它的开关；权限的扩张要与「能否审视它的思考」同步，开放模型的优势在于推理空间与激活都可见；以及共同责任模型，实验室、企业、硬件各管一层，运行时与策略语言要开放，以便任何供应商接入。

动机的表述比原则更直白。厂商把 drift 定义为偏离预期任务或运行约束的动作，并写明在这种环境下「an agent in these circumstances cannot be expected to fully govern its own behavior」。这句话可以读成一句免责，也可以读成一份工程约束：如果 agent 不能自我治理，那么治理这件事就必须落在它够不着的地方。这是带外执行的全部理由。

证明器这条原则还留了一个要追问的前提：能被证明的范围，取决于策略语言写得多细。形式化验证都要在表达力和可判定性之间做取舍，表达力越强，自动证明越难。所以「策略无法逃出操作者意图」这句话的分量，取决于这套语言能描述哪一类性质、证明覆盖到哪一层。评估时值得问一句：证明跑在什么粒度上、覆盖哪些性质、你担心的那类越界在不在里面。

四、一处容易被跳过的细节：策略的可变性按域分开

文档把策略分层，并且写明每一层在什么时刻生效。文件系统层用内核安全模块把访问限制在声明路径内，进程层用系统调用过滤堵住提升路径，这两层在沙箱创建时就锁死。网络策略可以在运行时热加载。凭据只在 profile 授权的端点上解析，附件、轮换与吊销可以运行时更新，而新增环境变量需要新进程。

这份表有一个不太好听的结构性含义：能在运行时改的那一层，恰好是数据外流走的那一层。把网络策略做成可热加载有它的现实理由，封掉一个刚发现的地址不该重启整个沙箱。但这个便利同时意味着，一次运行期间策略确实变过，而变过的东西需要留痕，否则事后没人能说清那一刻的允许范围是什么。

从这里可以引出一条通用的判断标准：评估任何运行时，先问「哪些域在创建时锁死、哪些域能中途改」，再问「能中途改的那些，改动本身有没有记录」。第一问看的是能力，第二问看的是可复算性。这两问在多数产品资料里都找不到答案，得去读策略文档。

顺着这个标准，如果某一层策略能中途改，记录里至少要有三样东西：改动前后的策略版本、改动的时点、改动由谁发起。缺了这三样，事后回看一次运行，你能知道现在的策略长什么样，却不知道当时生效的是哪一版。差别看起来很小，但在一次争议里，「现在的配置」和「当时的配置」是两个不同的证据。

五、我们的判断：差异点消失了，剩下的一格是「对谁带外」

策略先证明、执行在带外，这两件事从此不再是某家产品能拿来当差异的卖点，而是平台参考架构里写出来的默认方向。这一步之后，能比的地方只剩一个：带外是对谁带外。

这里的带外是相对 agent 而言的。控制不在它够得着的范围内，它关不掉、改不了、也不需要知道，这一点做得比过去所有的进程内拦截都干净。但它并不相对厂商带外：策略由谁写、证明器由谁实现、看门狗由谁烧进固件、活动记录由谁生成和保存，全部产自同一家厂商的栈。于是越界发生之后，你能引用的是一份厂商账本，而不是一个可以独立复算的过程。

这跟实现质量无关。哪怕每一层都做得很好，审计锚的位置仍然落在单一信任根上，因为记录与强制来自同一方，验证者最终要相信的是这家厂商，而不是某段能自己站住的证据。这是架构位置决定的，不是成熟度决定的。说清楚这一点，也能避免一种常见的误读：指出锚点的位置，不等于说这套东西没用。

六、选平台时先问的三个问题

• 记录和强制是不是同一方产生的？如果是，一次越界事件在事后能不能在不依赖这家厂商自述的情况下复算？
• 哪一层策略锁死、哪一层能中途改？把「可运行时热加载」的域单独列出来，再看那层的中途修改有没有留痕。
• 权限被扩大时，新范围的依据从哪里读？签字的是谁，时间点在哪？

这三个问题放进采购评估表时，和价格、延迟是同一层的，因为它们决定一次事件之后你能拿出什么。签合同之前问得清楚，成本是几次会议；上线之后再问，成本是一次说不清的越界。

七、这套东西回答了什么问题，没回答什么

它回答的是运行时这一层：强制点存在，策略有表达方式，动作有观察，权限扩张与可审视性被挂在了一起。这四件事在一年前还需要逐家论证，现在进了参考架构。

它没回答的是证据这一层：这条记录由谁签；权限在中途被改动时，记录里能不能看出来；越界判定能不能脱离厂商自述被复算。这三件事都不在发布材料里，因为它们不是能力问题，是位置问题。买方如果只评估能力，会拿到一份很漂亮的清单；把审计锚的位置也写进评估表，才能看出这份清单在事后值多少。

这两层的先后关系也值得说清。证据层不是运行时层的附加项，它们由不同的设计决定：运行时的强制点可以今天换一版策略，而证据层的结构一旦定下来，改动就意味着重新定义记录格式与签署方，成本高一个量级。所以对外选型时，能力可以逐版迭代，锚点最好一次定对。

八、证据边界

上面所有内容都是厂商自述，没有第三方验证，所以不能写成「经评测」或「已证明有效」。可用性要两头写：厂商称 broadly available，版本仍是 0.1.x。Sentry 不开源，伙伴名单来自二手报道。

发布材料里还有一句「本可阻止七月事故」的说法。那是反事实主张，没有复盘支撑，不能当作能力证据，我们在这里只把它记为一句陈述。同一个事故在不同来源层出现过相差一个量级的 agent 数量口径，两个数字出处不同，不能混用或合并，混用等于把厂商口径写成既成事实。本文引用的原则原文来自开发者和文档页面，链接列在下面。

九、行动

如果你在选平台，把「谁产生记录」写进评估表，和价格、延迟并列。如果你已经上了某家的运行时，至少确认一件事：越界发生之后，你手上那份能用来复算的记录，是谁签的。

给自己现在的架构做一次体检，可以按三步走。第一步把强制点画出来：它跑在哪个进程、用哪个用户身份、在哪台机器上；画完通常会看到强制点和 agent 共用一个身份。第二步看记录的产生路径：谁写、写在哪里、被管的那个进程能不能改它。第三步问策略版本：上一版是什么、什么时候换的、谁换的。三步里只要有一步答不上来，那一格就是空的，和厂商材料写得多好无关。

留一个问题给正在做架构的团队：你现在的强制点和记录，是不是同一方产生的？如果是，你打算怎么向第三方证明当时实际发生了什么。

参考来源

• Nvidia 开发者博客（2026-09-28，五条原则、OpenShell 与 Sentry 的分工、OpenShell 跑在 Vera CPU 上）
• OpenShell 文档「Why OpenShell Exists」（四类失效与控制手段、策略分层的生效时刻、0.1.x 版本口径）
• NVIDIA/OpenShell 仓库（Apache-2.0 许可、版本与提交量）
• Nvidia 新闻稿（平台发布；本轮正文抓取为空，只取字段级信息）
• CNBC 报道（二手：伙伴名单与产品定位）
• The New Stack 报道（二手：Sentry 的开源状态与接口说法）