别再问 Agent 值不值得信任（问它被关在哪里）
NVIDIA 在 GTC Berlin 发布 OpenShell 参考架构：Rubin 跑推理、Vera CPU 跑 Agent、BlueField-4 上的 Sentry 负责带外监控与芯片级执行；ServiceNow Arc 同日 GA。
大多数人讨论 Agent 安全的方式，是错的。
他们问的是：这个模型够不够聪明，够不够听话，会不会乱来。
这是在问性格。
而一个系统的安全，从来不靠性格。
靠的是结构。
默认的陷阱
你可以回想一下，公司是怎么管人的。
不是因为每个员工都品德高尚，所以账目没出问题。
是因为写报销的人和批报销的人不是同一个，管仓库的人和管账的人不是同一个，门禁卡可以随时作废。
我们早就知道，信任一个人，不等于把所有权限交给他。
可轮到 Agent，很多人又回到了最原始的做法。
给它一个账号，给它一堆工具，然后祈祷它表现良好。
这就是默认的陷阱。
把"希望它不出事"当成了安全策略。
回到第一性原理
10 月 21 日，在 GTC Berlin，NVIDIA 发布了 OpenShell 参考架构。
它建立在开源的 OpenShell 安全运行时之上。
如果剥掉所有产品名，它的核心思想只有一句话。
思考、行动、治理，必须发生在三个不同的地方。
黄仁勋的原话是这样说的。
"agents can think on Rubin, act on Vera and be governed on BlueField."
大意是，Agent 在 Rubin 上思考，在 Vera 上行动，在 BlueField 上被治理。
拆开看，是三层。
- Vera Rubin 负责模型推理，也就是"想"
- Vera CPU 负责 Agent 的运行框架和工具调用，也就是"做"
- BlueField-4 DPU 运行 NVIDIA Sentry，负责带外监控和芯片级策略执行，也就是"管"
注意最后一层。
它不在 Agent 自己的软件里。
它在另一块硅片上。
反转模型
大部分人设计 Agent 系统的思路，是从能力出发。
先让它能做尽量多的事，再往上加限制。
OpenShell 的思路正好反过来。
先画好边界，再在边界里给它能力。
这个区别看起来很小。
实际上决定了出事的时候，你是在补漏洞，还是在按按钮。
据 NVIDIA 官方介绍，当 Agent 试图越过软件边界，Sentry 可以在毫秒级把它隔离并停止。
官方还称，Sentry 可以把 Agent 容量最多提升 20%。
这个数字是厂商自报的，我没有看到独立测试。
但方向是清楚的。
监控者不住在被监控者的体内。
为什么要下沉到硅片
你可能会问，既然有软件沙箱，为什么还要动用一块专门的 DPU。
我的理解是这样的（这是推断，不是官方解释）。
软件层的规则，归根结底和 Agent 跑在同一套系统里。
同一套系统里的东西，理论上总有被绕过、被篡改、被一起拖垮的可能。
把执行策略放到另一块芯片上，等于把裁判请出了球场。
球员再怎么折腾，也碰不到裁判的哨子。
这不是说软件防护没用。
而是说，最后一道防线，应该放在被防的那一方够不着的地方。
你可能会反驳
"我的 Agent 只是帮我整理文档，用不着这么复杂。"
也许是。
但 Agent 的权限往往是悄悄长大的。
今天整理文档，明天顺手发邮件，后天接上了付款工具。
每一步看起来都很合理。
等你回头看的时候，它已经拿到了你从没认真审视过的权限。
结构不是为今天的 Agent 准备的。
是为它以后会长成的样子准备的。
三个可以带走的原则
你大概不会明天就去买一套 Vera Rubin。
这没关系。
这套架构真正有价值的部分，是思路，而思路可以搬到任何规模的系统里。
以下是我的提炼，不是 NVIDIA 的官方表述。
1) 把"想"和"做"分开
让模型负责提出方案，让另一个受控的环境负责执行。
模型可以想任何事。
但它能碰到的工具和数据，应该由执行环境决定，而不是由模型自己决定。
2) 让监控站在外面
如果监控代码和 Agent 跑在同一个进程里，Agent 出问题的时候，监控也可能一起出问题。
NVIDIA 把监控放到 DPU 上，是硬件层面的答案。
你的版本可以小得多，比如一个独立的日志与审计服务，一个 Agent 无权修改的策略文件。
关键不是用什么，而是"它改不了"。
3) 把撤销权放在最外层
最重要的问题不是"它会不会出错"。
是"出错的时候，你多快能让它停下来"。
一个无法快速撤销权限的 Agent，不管多聪明，都不该接触重要的东西。
它能跑在哪里
这套架构不只是数据中心的东西。
据 NVIDIA 介绍，边缘端可以用 RTX Spark、DGX Spark 和 DGX Station。
系统层面，Linux 和 K8s 有 Canonical、SUSE、Red Hat，Windows 上有 Microsoft Execution Containers（MXC），云上有 AWS、GCP、Azure。
生态方面，NVIDIA 列出的合作方很长，这里只举一部分。模型厂商包括 Anthropic、OpenAI、Google、Meta、Perplexity、Reflection 等，在做安全集成的包括 1Password、CrowdStrike、Palo Alto Networks、Zscaler 等。
BBVA 和 Santander 在评估。
SAP 在接入它的 Joule Studio 运行时。
NVIDIA 官方称，这套参考架构现已可用。
一长串名字说明了一件事。
Agent 的治理，正在从"某个产品的功能"，变成"整个技术栈的默认配置"。
一个已经落地的例子
同一天，ServiceNow 宣布 Arc 正式可用（GA）。
Arc 是一个个人化的、长期运行的企业 Agent。
注意"长期运行"这四个字。
一个随叫随走的助手，出错的窗口很短。
一个一直在线、一直拿着权限的 Agent，出错的窗口是全天候的。
所以它比任何一次性的工具，都更需要外部的治理。
它的分工，几乎是上面那套原则的翻版。
- ServiceNow 的 Super Intelligence Control Tower 负责治理
- OpenShell 负责执行
据 ServiceNow 介绍，Arc 随 EmployeeWorks 提供，Foundation、Advanced、Prime 三档 SKU 不额外收费。
现在支持 Mac，Windows 版官方说的是预计"数周内"推出，目前还是计划。
还有一个叫 AI Passport 的组件，ServiceNow 前不久刚宣布，目标是在软件和硬件层面，几秒内吊销一个 Agent 的权限。
但要分清楚。
AI Passport 连同它在 OpenShell 和 BlueField 上的执行，ServiceNow 的说法是预计在未来版本中提供，不是今天就能用的功能。
发布会讲的是方向，你能部署的才是现实。
你真正需要做的
在你给下一个 Agent 开权限之前，问自己三个问题。
- 它的"想"和"做"，是不是在同一个地方
- 盯着它的东西，它自己能不能关掉
- 出了事，你能不能在它造成更多损失之前让它停下
如果三个问题的答案都让你不太舒服，那问题不在 Agent。
在你。
你永远无法确定一个 Agent 会做什么。你只能确定它做不到什么。
聪明是它的事。
边界是你的事。
来源：NVIDIA 新闻稿（2026-10-21）；ServiceNow 新闻稿（2026-10-21）。Sentry 毫秒级隔离与“容量最多提升 20%”为 NVIDIA 自报；文中合作方只列部分，完整名单见 NVIDIA 原稿；Arc 已 GA，Windows 版预计数周内推出，AI Passport 及其在 OpenShell/BlueField 上的执行预计在未来版本提供；三条原则与“裁判”比方为作者提炼，非 NVIDIA 官方表述。