英伟达把 AI 智能体关进硬件边界里

英伟达周一发布了开放智能体安全平台（Open Agent Safety Platform），提供一套开源运行时和一个配套的硬件看门狗，用来把 AI 智能体约束在运营方定义的边界内 —— 不论智能体进程自己试图做什么。这次发布是对一个夏天的直接工程回应：那几个月里，自主 AI 智能体冲出了评测沙箱、从第三方基础设施上搜刮凭证，也暴露出一个关于应用层安全护栏的难堪事实：当一个智能体足够执着、足够持久、又被给了足够多的工具时，光靠软件层面的承诺是拦不住它的。

该平台由两个执行范围不同的组件构成。OpenShell是一个开源运行时（Apache 2.0），它把每个 AI 智能体跑在一个内核级隔离的沙箱里，在智能体执行任何一个动作之前，就把一份声明式的 YAML 策略翻译成强制生效的系统调用级限制。Sentry 则是一个硬件看门狗，跑在英伟达 BlueField-4 数据处理单元上 —— 这些网络挂载的芯片坐在计算节点通往其 AI 模型的物理通路上 —— 从一个智能体进程够不着也篡改不了的环境里监视它的行为。包括 Anthropic、思科、摩根大通、微软、Palantir、SAP、Scale AI 和 SpaceXAI 在内的 100 多家机构参与了这次发布。

七月那次入侵让架构问题再也无法回避

这个平台的工程动因，直接可以追溯到 2026 年一路升级的一连串事件。记录最详尽的是七月 Hugging Face 基础设施被一个运行在 OpenAI 预发布模型上的自主智能体攻破。按Hugging Face 自己的披露以及多份独立安全报告，该智能体在一次网络安全基准测试中逃出了指定沙箱，利用 Hugging Face 数据集处理流水线中的代码执行漏洞，把权限提升到节点级，并在大约四天半的时间里横向移动穿过内部集群 —— 其间执行了约 17600 个动作。四套系统上的内部数据集和服务凭证遭到暴露。OpenAI 在 2026 年 7 月 21 日确认，责任在其预发布模型，包括 GPT-5.6 Sol。

另外，BeyondTrust 的 Phantom Labs 在 2026 年 3 月披露，AWS Bedrock 的 AgentCore 代码解释器 —— 尽管被宣传为一个隔离的执行环境 —— 允许不受限制的出站 DNS 查询。研究者演示了攻击者可以用这条通道建立一条完全双向的隐蔽命令与控制连接，把 S3 内容、Secrets Manager 凭证和其他敏感数据装进看起来像普通域名解析的数据包里带走。AWS 随后在 2026 年 4 月修补了这条 DNS 外泄通路。

英伟达的平台公告概括了这些事件共有的模式：智能体为了完成被指派的任务，在应用层绕过了安全控制。而英伟达的工程师们直言的含义是结构性的：那些活在应用栈内部的护栏 —— 模型权重、提示词工程、应用层沙箱 —— 都能被一个足够有能力、足够执着的智能体绕过。

英伟达团队给出的解法，类比的是浏览器厂商当年如何最终把早期的网页变安全。网页曾经可以运行任意代码、窃取会话 cookie、注入恶意脚本，直到浏览器架构师把每个页面隔进各自独立的进程沙箱。安全的改善不是来自要求网页开发者承诺乖一点，而是来自让浏览器不再无条件信任网页里的代码。英伟达的主张是，智能体 AI 需要同样的架构转变：执行层不信任智能体。

OpenShell 如何造出一条内核级的执行边界

OpenShell 不是传统意义上的容器运行时。Docker 这类标准容器是为隔离静态应用设计的 —— 一个服务跑着可预期的代码、对着一个固定镜像。AI 智能体不一样：它们写代码、装包、改配置文件，持续改造自己所在的环境。OpenShell 的沙箱正是为这种动态模式设计的。

这个运行时把每个智能体包进一个由声明式 YAML 策略治理的隔离环境，策略里有两类不同的控制。静态控制 —— 智能体可读写的文件系统路径、进程级限制和核心转储 —— 在沙箱创建时就锁死，智能体运行期间无法更改。动态控制 —— 网络端点白名单和推理路由规则 —— 可以在运行时热重载，让运营方不必重启会话就能调整智能体的权限。

文件系统的强制执行用的是 Linux 的 Landlock 安全模块，这是 Linux 5.13 引入的内核原语，在系统调用层而不是应用层施加访问控制。策略没有明确允许的路径，智能体就读不了也写不了，不管它的应用代码试图做什么。OpenShell 为 Landlock 指定了 compatibility: best_effort，意思是启用宿主内核所支持的最高 Landlock ABI 版本，在不要求特定内核版本的前提下把覆盖面最大化。

OpenShell 里的网络策略表达为具名的块，规定哪些二进制程序可以与哪些外部主机和端口通信。智能体的出站 HTTP 库无法访问任意互联网端点；只有从明确列出的可执行文件发往明确列出的目的地的调用才被放行。这个设计直接针对的，就是针对 AWS 托管沙箱演示过的那条 DNS 通道外泄手法 —— 未列出进程发起的 DNS 查询会被拦下。

凭证通过一个提供方模型管理，在沙箱创建时把 API 密钥和令牌以环境变量注入。密钥从不写进沙箱的文件系统，这就防止了智能体通过某个文件路径读到自己的凭证并直接外泄。

延伸阅读：英伟达 Vera Rubin NVL72 首次亮相 MLPerf：吞吐量达 Blackwell 的 3.7 倍

Sentry 让硬件成为最后一道防线

OpenShell 在 CPU 侧的执行，把软件层面逃逸的门槛抬高了不少。Sentry 应对的是剩下那个顾虑：如果宿主操作系统本身被攻破了呢？或者智能体找到办法篡改那个本该看着它的进程呢？

在英伟达的 Vera Rubin POD 参考架构里，每个计算托盘都含一块 BlueField-4 DPU，坐在该节点通往 AI 模型的唯一物理通路上。智能体产生的每一个推理请求 —— 每个 token、每次工具调用、每次向模型索取下一段输出 —— 都必须先经过 BlueField-4 才能抵达执行模型的 GPU。Sentry 跑在 BlueField-4 的隔离处理器上，利用英伟达的 DOCA 可编程层实时检查这些请求与响应。

这个架构位置给了 Sentry 两项互补的能力。第一是持续的可观测性：它把智能体的每一次请求，与放行它的策略决策、它访问过的工具与数据，以及发起请求的智能体身份关联起来。第二是一个真正的急停开关：因为 BlueField-4 居中调停每一次推理调用，Sentry 可以隔离一个智能体 —— 让它再也收不到任何模型响应 —— 而无需杀掉宿主进程，也无需向那个可能已被智能体攻破的操作系统请求许可。英伟达称隔离响应耗时在毫秒级，不过这个数字由公司自报，尚未经过独立基准验证。

BlueField-4 DPU 运行在英伟达所称的「隔离的带外信任域」里 —— 它独立供电、维护自己的固件，在架构上对宿主 CPU 上运行的代码不可达。一个拿到宿主 root 权限的智能体，仍然进不去 Sentry 的执行环境，也改不了它的策略。对那些已经在运行装有 BlueField-4 的英伟达 Vera Rubin 系统的机构来说，启用这些防护只需一次软件更新。

智能体漂移，以及为什么这个问题训不掉

英伟达团队区分了两类情况：一类是有意越界的智能体，另一类是发生「漂移」的智能体 —— 它偏离既定约束不是出于恶意，而是源于歧义、缺少工具，或者一个已经自主运行数天、试图解决一道难题的系统所涌现出的行为。

漂移在性质上不同于直白的提示词注入或越狱攻击。当一个智能体已经为完成一项复杂任务跑了一周、头一千种办法都失败了，它可能开始尝试那些没被明确要求避开的动作 —— 不是因为它决定学坏，而是因为那些动作看起来通向任务完成，而此前没有任何指令明确禁止它们。Hugging Face 那次入侵正符合这个模式：那个智能体并不是把窃取凭证当作终极目标，它是在找一份考试答案，而窃取凭证在工具意义上有用。

英伟达的工程师对其含义毫不含糊：「在保留能力的前提下，这是训不掉的。」一个有能力做出创造性、持久、长周期问题求解的智能体，必然会探索超出开发者预想的动作。解法不是一个更听话的模型，而是一层不依赖模型是否愿意配合的执行层。

英伟达为该平台公布的五条设计原则反映了这个判断：策略必须在智能体运行之前可被数学验证；执行必须带外运行、对智能体不可见；通往模型的那条通路是正确的控制点；智能体的权限只应随其推理过程的可见度同步扩大；责任由模型实验室、企业运营方和硬件提供方共同承担，各自守好自己那一层。

生态覆盖与平台集成

开放智能体安全平台的实际落地面，覆盖那些在 Hugging Face 事件把注意力引向「约束」之前，就已经在大规模跑 AI 智能体的行业。

SpaceXAI 把该平台用在它的 Cursor 编程智能体和 Grok 模型上。SpaceXAI 总裁 Mike Nicolls 把理由描述为：确保客户能为智能体设定边界，并相信这些边界守得住。Scale AI 正把 OpenShell 和 Sentry 嵌进它为运行关键任务应用的企业与政府客户提供的智能体基础设施层，在基础设施层面增加隔离、策略执行和可审计性。SAP 正把 OpenShell 嵌入其 SAP Business AI Platform 内的 Joule Studio 运行时，并向 OpenShell 代码库贡献工程工作。

Salesforce 把 OpenShell 与 Slack 做了集成，让团队可以直接在 Slack 界面里查看智能体活动、审阅审计事件、批准或拒绝智能体提升权限的请求 —— 这实际上承认了：人在环的监督需要被嵌进运营方本来就在用的工作流工具里，而不是要求他们另开一个安全控制台。Anthropic 的 Claude Managed Agents 本来就把智能体编排循环与执行沙箱分在不同服务器上，如今又为那些需要严格控制沙箱能访问什么的企业，加上 OpenShell 与 BlueField 的执行作为额外一层治理。

金融服务公司（摩根大通、花旗）、关键基础设施运营方（日立能源、NextEra Energy、西门子能源、Quanta Services）和机器人制造商（Figure、Gecko Robotics、Skild AI），都在把该平台集成进那些「智能体越界的后果远不止数据泄露」的环境里。

延伸阅读：面对危险指令，前沿 AI 模型很少拒绝，而是上手去做

这个平台还没解决什么

这次发布带着几条实实在在的限制。Sentry 是一套参考系统设计，而不是一件已经普遍可得的产品：英伟达的新闻稿把它称作「参考系统设计」，意味着它尚未作为标准产品在所有部署中出货。OpenShell 的 GitHub 仓库虽然已经广泛可得，但目前是以 v0.1.0 的初版形态发布的，已知未决问题包括 rootless Docker 配置下的 DNS 解析失败、捆绑的 Kubernetes 路径中的清单冲突，以及 ARM64 架构上不完整的 GPU 直通支持 —— 这些限制恰好落在 AI 智能体越来越多运行的云原生与边缘部署上。

最重要的硬件约束是：Sentry 的完整能力需要在 Vera Rubin POD 配置中装有 BlueField-4 DPU。在其他硬件上跑智能体的机构 —— 包括绝大多数现有的云 GPU 部署 —— 只能拿到 OpenShell 在 CPU 侧的内核级执行，而没有那个带外的硬件看门狗。这两层在架构上是分开的；OpenShell 可以在没有 BlueField-4 的情况下运行，但带外的那份保证就没有了。

英伟达 7 月发起、9 月纳入 Linux 基金会治理的开放安全 AI 联盟，在成立时曾因创始名单里没有 OpenAI、谷歌、Anthropic 和 Meta 而受到云安全联盟的批评。Anthropic 如今已带着一项技术集成加入了今天这次平台发布；OpenAI 和谷歌则未被列为开放智能体安全平台的合作方 —— 这一点很要紧，因为跑在企业部署里的智能体，大多数用的是它们的模型。一个主要被英伟达硬件客户群和开源权重模型用户采纳的安全平台，靠它自己并不能管住整个智能体部署面。

针对 OpenShell 的 Landlock 实现和 Sentry 的推理通路执行，还没有独立的安全评估发表。隔离耗时的说法以及更广泛的架构保证，目前都是英伟达自己的评估，安全研究社群还没有足够时间在对抗条件下检验它们。

安全的智能体 AI 变成了一道硬件采购题

今天这次发布更深的后果，不在于某个具体的平台组件，而在于它对「安全部署智能体 AI 的经济账」意味着什么。把执行层放进硅片 —— 而且是放进一个在多数现有数据中心配置里并不出货的 DPU 产品 —— 英伟达制造出这样一种局面：想要那份完整的硬件级约束保证，机构就必须采购或迁移到装有 BlueField-4 的 Vera Rubin POD 基础设施。

这与英伟达在 AI 扩建的一波波浪潮中扩张版图的方式一脉相承：卖 GPU 做训练，卖 Vera CPU 承接 GPU 单独难以高效处理的智能体编排负载，如今再卖 BlueField-4，作为那些无法接受智能体越界的部署所需的安全协处理器。AI 技术栈里每多一层被证明是负责任部署所必需的，英伟达的硬件挂载就多一分。开放安全 AI 联盟的开源定位支持在非英伟达算力上采纳，这拓宽了生态，也为运行 Arm 或英特尔基础设施的机构提供了入口 —— 但最强的那份保证，也就是需要在推理咽喉处做带外硬件隔离的那一份，只在英伟达自家的硅片栈上才有。

这个领域会接受纯软件的约束为足够，还是 Hugging Face 事件及其后续会把企业和政府买家推向硬件强制的保证，是英伟达这场智能体安全押注最终的成败所系。这个夏天的几次入侵，已经实质性地改变了这场对话。