英伟达给AI智能体装上急停键

英伟达开始管智能体的手和脚

9 月 28 日，英伟达发布开放式 AI 智能体安全平台 NVIDIA Open Agent Safety Platform，试图解决一个越来越现实的问题：当 AI 不再只负责生成文本，而是能调用终端、访问数据库、操作浏览器甚至控制机器人时，一旦行为越界，系统该如何在造成实际损失前把它停下来？

英伟达给出的方案是一套双层架构：OpenShell 负责提前划定权限边界，NVIDIA Sentry 负责持续监控，并在发现异常后执行毫秒级隔离。

这不是传统意义上的模型内容审核，也不是在提示词前面再加一段安全规则。它更接近于给智能体套上沙箱，再安排一个独立于智能体运行环境的硬件看门狗。前者决定智能体可以碰什么，后者盯着它实际上做了什么。

从方向上看，这套东西有用，而且很可能会成为企业部署智能体时的标准组件。但英伟达目前公布的更多是架构和能力主张，距离证明它能在复杂生产环境中稳定拦截攻击、同时不误伤正常任务，还有一段路要走。

OpenShell：不管模型是谁，先把权限关进笼子

Open Agent Safety Platform 的第一层是 OpenShell。按照英伟达的描述，它是一套运行在 CPU 侧的开源安全软件，用来限制 AI 智能体能够访问的资源、工具和执行环境。

OpenShell 不绑定特定模型。无论智能体背后使用的是开源模型还是闭源模型，也不管推理发生在本地、私有云还是外部 API，理论上都可以在智能体调用工具的环节设置边界。

这点很关键。

过去一年，智能体框架的安全设计大量集中在模型层：给系统提示词加规则、让另一个模型做内容审核，或者要求模型在执行高风险操作前进行自我反思。但这些办法有一个共同问题——负责执行任务的模型，同时参与判断自己是否安全。

这有点像让一个拥有服务器管理员权限的程序自行承诺不会删除数据库。承诺可以写得很漂亮，但真正可靠的控制仍然应该落在操作系统权限、网络策略和身份认证层。

OpenShell 的思路正是把安全边界从模型的“自觉”移到外部执行环境。例如，一个负责整理销售数据的智能体可以被允许：

• 读取指定对象存储桶中的报表；
• 调用数据清洗脚本；
• 向内部分析数据库写入结果；
• 访问经过批准的模型 API。

但它不能读取开发者的 SSH 密钥，不能连接未经授权的公网地址，也不能执行修改系统账户的命令。即使模型受到提示词注入，生成了恶意工具调用，真正执行时仍会被权限边界挡住。

OpenShell 还计划支持 Arm 和英特尔平台，而不是只能运行在英伟达自家 CPU 上。对企业用户来说，这比一句“开放平台”更实际：智能体的控制面如果只能绑定单一硬件栈，就很难覆盖已有的混合基础设施。

英伟达同时强调，OpenShell 与 Vera 平台结合后的性能开销很低。这个指标决定了它能不能进入生产环境。安全层如果让每次工具调用都多出明显延迟，开发团队最终往往会选择关闭一部分策略，而不是接受智能体效率下降。

不过，目前公开信息还没有给出足够完整的测试口径，例如基准任务类型、并发智能体数量、策略复杂度，以及所谓“低开销”具体对应多少延迟和吞吐损失。对性能敏感的开发者，现在还不适合只看发布会结论。

Sentry：智能体失控后，毫秒级拔掉插头

如果说 OpenShell 负责建围栏，NVIDIA Sentry 就是站在围栏外的看门狗。

Sentry 运行在 BlueField-4 DPU 上，持续监控智能体的活动，并在芯片层面独立执行安全策略。当智能体尝试突破 OpenShell 的限制，或者出现符合威胁规则的异常行为时，Sentry 可以在毫秒级将其隔离并停止运行。

这里最值得关注的不是“毫秒级”三个字，而是它采用的 带外信任域。

在普通的软件安全架构中，智能体、监控程序和安全策略可能运行在同一台主机、同一个操作系统，甚至共享相近的权限。一旦主机环境被控制，监控程序本身也可能遭到关闭、欺骗或绕过。

Sentry 则把监控和执行下沉到 DPU。它不依赖智能体主动上报，也不完全信任运行智能体的 CPU 和操作系统。可以把它理解成服务器里的独立保安室：即使办公区内的系统已经被攻击，保安仍然能够切断门禁、网络和数据访问。

这套设计主要解决三类问题：

1. 智能体主动越权：模型尝试调用未授权工具、读取敏感文件或修改系统配置；
2. 智能体被间接操纵：网页、邮件、代码仓库或文档中的提示词注入，诱导智能体泄露数据；
3. 运行环境遭到入侵：攻击者控制主机后，试图关闭日志、安全代理或策略执行组件。

对于机器人和具身智能系统，硬件级隔离的价值更加直接。一个文本模型输出错误答案，最坏结果可能是误导用户；一个能够控制机械臂、无人设备或工业系统的智能体越界，错误会立刻进入物理世界。此时，安全系统必须拥有独立于模型的停止权限，而且响应速度不能以秒计算。

它和传统沙箱有什么区别？

只看功能描述，Open Agent Safety Platform 很容易被理解为“容器沙箱加一套安全监控”。两者确实有重合，但智能体带来了传统应用安全不太擅长处理的新变量。

普通程序的行为通常由开发者预先写好，输入和调用路径相对稳定。智能体则会根据上下文动态规划任务，同一个目标可能生成完全不同的工具调用序列。它今天读取三张表，明天可能决定先写一段 Python，再查询网页，最后调用内部 API。

这意味着，安全策略不能只回答“某个进程是否允许访问某个文件”，还要理解：

• 当前行为是否符合智能体被分配的角色；
• 多个单独合法的操作组合起来，是否构成数据泄露；
• 智能体是否在异常频率下尝试访问资源；
• 工具调用链是否偏离原始任务；
• 一个智能体创建的子智能体，是否继承了不该拥有的权限。

OpenShell 和 Sentry 的组合，本质上是在尝试把传统的沙箱、零信任访问控制、运行时检测和硬件隔离，重新包装成适合智能体工作负载的安全基础设施。

真正的难点不在于“发现访问了哪个文件”，而在于如何判断一次看似正常的访问是不是任务所必需。这个问题最终仍然需要策略规则、行为基线，甚至另一个检测模型共同参与。

有用，但不是智能体安全的银弹

英伟达的方案抓住了当前智能体安全中最薄弱的一层：企业给了智能体越来越多的权限，却没有同步建立足够强的外部制动系统。

不少智能体产品现在依赖人工确认弹窗控制风险。但当任务进入批量化、后台化和长时间运行阶段，人类不可能审批每一次文件读取和 API 调用。没有运行时治理，所谓自动化越深入，攻击面就越大。

Open Agent Safety Platform 的价值，是把安全控制放到模型之外，而且让控制系统具备独立终止任务的能力。这比仅靠系统提示词、模型拒答和事后日志审计更可靠。

但它至少还有四个问题需要验证。

第一，边界是谁定义的？

OpenShell 可以执行权限策略，却不能自动替企业决定正确的权限边界。开发者如果给智能体开放了整个内部网络，沙箱运行得再稳定也没有意义。

智能体权限设计会比传统 RBAC 更复杂。它不仅涉及“谁能访问什么”，还涉及“在什么任务上下文中、以什么频率、通过什么工具、处理哪一类数据”。策略配置错误，仍然可能出现权限过大或业务无法运行的问题。

第二，误报可能比漏报更早暴露

Sentry 强调异常检测和毫秒级隔离，但企业真正部署后，首先遇到的往往不是惊险的攻击，而是正常任务被错误中断。

智能体的行为具有随机性和动态规划特征。它可能因为一次 API 失败临时更换工具，也可能为了完成任务创建额外脚本。安全系统如果把所有偏离预期路径的行为都视为攻击，就会把智能体重新变成人工审批流程。

因此，隔离速度不是唯一指标。误报率、策略解释能力、任务恢复机制和审计信息，同样决定这套平台是否可用。

第三，DPU 是优势，也是绑定

Sentry 运行在 BlueField-4 DPU 上，使英伟达能够提供独立于主机的硬件信任域。但这也意味着，想获得完整的硬件级能力，客户需要进入英伟达的数据中心基础设施栈。

OpenShell 可以支持第三方平台，并不等于整套 Open Agent Safety Platform 都是硬件无关的。对已经使用其他网卡、DPU 或云安全体系的企业来说，迁移成本和互操作性需要进一步评估。

第四，能阻止某次攻击，不等于能阻止同类攻击

英伟达方面称，如果相关实验室此前部署了这套技术，2026 年 7 月涉及 OpenAI 模型与 Hugging Face 的安全事件可能被阻止。

这是一个很强的产品判断，但目前仍属于英伟达的事后推演，而不是经过独立复现的结论。要证明这一点，需要公开攻击链、触发策略、阻断位置，以及系统在不影响正常实验任务的情况下如何识别异常。

开发者应该关注可复现的安全测试，而不是只接受一个著名事件作为营销案例。

英伟达要卖的不只是算力，还包括控制权

Anthropic、SpaceX 和 Scale AI 已经与英伟达合作，将 OpenShell 用于模型和智能体相关工作。合作名单能够说明大型 AI 团队确实需要这类基础设施，但不能直接推导出它们已经在生产环境全面部署 Sentry，也不能说明平台已经覆盖模型训练和推理的所有安全场景。

更值得注意的是英伟达的业务位置。

过去，英伟达向 AI 公司出售 GPU 和网络设备；随着智能体进入企业应用，它正在继续向上扩展，提供模型、推理服务、智能体工具链，现在又开始提供安全控制面。

这条路线并不难理解：如果智能体成为下一代软件运行方式，那么安全、身份、权限和可观测性都会成为新的基础设施层。谁能控制这一层，谁就不只是卖芯片，而是在定义智能体如何进入生产环境。

这也让 Open Agent Safety Platform 具备了双重属性。它一方面确实回应了智能体失控和提示词注入等现实风险；另一方面，也在帮助英伟达把 BlueField DPU 从网络加速设备变成 AI 数据中心的安全执行底座。

开放 OpenShell，可以降低开发者接入门槛；把最高级别的隔离能力放在 BlueField-4 上，则为硬件销售建立新的理由。开源与硬件绑定并不矛盾，反而是英伟达熟悉的生态打法。

开发者现在应该关注什么？

现阶段，开发团队没有必要因为一次发布就重构智能体平台，但可以沿着几个方向评估 OpenShell：

• 策略表达能力：是否支持文件、网络、进程、凭据和工具级权限，能否描述带上下文的动态规则；
• 框架兼容性：能否接入 LangChain 等主流智能体框架，以及企业自研的工具调用链；
• 模型无关性：更换模型供应商后，安全策略是否仍然有效；
• 可观测性：是否能够记录每一次决策、工具调用、拦截原因和数据访问路径；
• 故障恢复：智能体被隔离后，是终止任务、回滚操作，还是转交人工处理；
• 部署成本：在 x86、Arm、容器和 Kubernetes 环境下的性能损耗与运维复杂度；
• 硬件依赖：哪些能力可以纯软件运行，哪些必须依赖 BlueField-4 DPU。

更现实的做法，是先把高风险工具调用统一收口。数据库写入、代码执行、外部网络访问和凭据读取，不应该由各个智能体框架分别处理，而应该经过统一的策略与审计层。OpenShell 如果能够成为这个控制点，就有实际价值。

智能体时代，安全不能继续靠模型自觉

Open Agent Safety Platform 最重要的信号，不是英伟达又发布了两个安全产品，而是行业开始承认：智能体安全不能只在模型内部解决。

模型可以接受对齐训练，可以在系统提示词中被要求遵守规则，也可以在执行前进行自我检查。但只要它拥有真实工具和真实权限，就必须像其他高权限软件一样受到外部约束。

OpenShell 提供的是边界，Sentry 提供的是独立制动。这个架构方向是对的，也比给智能体多加一层审核模型更接近工程现实。

接下来要看的，是英伟达能否把发布会上的“毫秒级隔离”变成可复现、低误报、跨平台的生产能力。如果做得到，它可能成为企业智能体平台的基础安全层；如果策略难配、误报严重，或者关键能力过度依赖自家硬件，它就更像一套用于扩大数据中心版图的安全包装。

无论结果如何，智能体开发的默认假设已经需要改变：不要再问模型是否足够听话，而要假设它迟早会犯错、被诱导或遭到劫持，然后确保系统随时能够收回它的权限。

参考来源

• IT之家：英伟达发布 AI 智能体安全平台，可实时隔离异常智能体 — 介绍 Open Agent Safety Platform、OpenShell、NVIDIA Sentry、BlueField-4 DPU 及合作企业等发布信息。
• GitHub：OpenAgentSafety 智能体安全评测项目 — 面向 LLM 智能体的开源安全评测基准，可用于了解智能体安全测试与现实任务评估思路；该项目与英伟达本次平台并非同一产品。