英伟达联合超100家伙伴推出开放代理安全平台

公众号_计算机魔术师
0 阅读15分钟

英伟达联合超100家伙伴推出开放代理安全平台

2026年9月28日，黄仁勋在X平台宣布，英伟达联合超过100家行业伙伴，推出NVIDIA Open Agent Safety Platform，整合OpenShell与Sentry两大组件。这不算一句新话。过去这一年，英伟达一直在把「Agent安全」这件事拆成可部署的子系统。这次是把两条线拧到一块，给从业者一个可直接对接的参考架构。

一个平台，两层机制

Open Agent Safety Platform的结构并不复杂。它分两层：上层是策略定义与执行层，下层是独立监控与隔离层。两层不共享运行时，互不依赖，这样做的代价是多一层运维，收益是单点故障不会击穿全部安全能力。

程序员 reaction：SalesforceCEosaysengineers

Agent运行时策略与监控分离

OpenShell：策略下沉到运行时

OpenShell不是新概念。它此前已经开源，主要解决一个问题：Agent自己「自觉」不可靠，需要一个外部层在运行时强制执行规则。它的职责范围包括文件访问、网络连接、工具调用、凭证使用。规则一旦绑定，Agent越界就会被拒绝。

这对工程团队的意义在于，不需要改造Agent本身就能加上策略约束。接入成本是配置层的调整，不是代码层的重写。风险在于策略本身的颗粒度。太粗，形同虚设；太细，误杀率上升，业务会抱怨。

Sentry：把刹车装进芯片层

真正的新东西是Sentry。它把监控和隔离放到英伟达BlueField-4数据处理芯片上，独立于Agent运行。Agent出异常时，Sentry不是事后查日志，而是在运行时持续做威胁检测和策略执行。

程序员 reaction：Content-Length:50

Agent策略层与硬件监控层并行

这种设计的工程取舍很明确：把安全从软件栈移到硬件栈，延迟会增加，但隔离层级更深。对云端大规模部署的Agent来说，这是合理的选择；对端侧低延迟场景，需要重新评估。

Open Agent Safety Platform 架构

Open Agent Safety Platform 架构

与OSAA的承接关系

这个平台不是孤立动作。2026年7月，英伟达联合Adobe、CrowdStrike、IBM、Microsoft、Red Hat、SpaceXAI等企业成立Open Secure AI Alliance（OSAA）。这次发布的平台，是OSAA成果的工程化落地点之一。

联盟的成员名单覆盖了云、安全、企业软件、开源基金会和模型层。这种组合不奇怪。Agent安全的本质是跨栈问题：模型层需要可验证输出，运行时层需要策略执行，基础设施层需要隔离能力。任何一个环节缺位，整体防线都是漏的。

落地门槛：谁在用、怎么用

对工程团队来说，真实问题是：接入成本多少、适配哪些Agent、迁移期能否双轨运行。

OpenShell可以直接套在Claude Code、Codex等现有Agent外面，无需改动Agent本身。这意味着存量项目可以快速接入，风险可控。Sentry则需要英伟达BlueField-4环境，对端侧和边缘部署构成硬性要求。

程序员 reaction：还不滚去学习

存量项目接入OpenShell vs 新项目评估Sentry

两种路径的工程取舍如下：

  • 在X条件下选OpenShell：存量Agent改造成本高、时间窗口紧，用OpenShell在运行时加策略层，风险更低。
  • 在Y条件下选Sentry：对隔离层级有硬性要求、部署在英伟达硬件栈上，用Sentry获得更深的运行时保障。

边界判断

坦白讲，这套平台解决的不是所有Agent安全问题。它覆盖的是「运行时越界」这一类场景。对模型层面的幻觉、对供应链层面的投毒、对输出合规性的验证，需要其他工具链配合。

这篇判断的适用边界也很明确：当你部署的是在英伟达硬件栈上运行的Agent系统，且核心风险是运行时策略违反。超出这个范围，需要重新评估工具组合。

更狠的是，每年能省下一个亿的安全incident预算。前提是，你确实在正确的硬件栈上跑正确的Agent工作负载。

事件本身讲什么

这不是一篇通稿堆出来的产品发布，而是英伟达在AI Agent安全治理上的一次明确落子

OpenShell：运行时策略层

OpenShell早已开源，这次是把它正式纳入安全平台的架构之中。它的定位很清晰：给Claude Code、Codex等Agent挂上一层外部约束，文件访问、网络连接、工具调用、凭证使用，全在运行时强制执行。

这样做的好处是不侵入Agent自身逻辑。Agent不需要变得「自觉」，它只需要接受外部规则的统一管束。

Sentry：芯片层隔离

真正的新东西是Sentry。它把监控和隔离直接下沉到BlueField-4数据处理单元上，独立于Agent运行，持续做威胁检测和策略执行。

这意味着一个关键转变：安全不再只是软件层的旁路检查，而是嵌入了硬件基础设施。

与OSAA的承接关系

这个平台不是孤立发布的。2026年7月27日，英伟达联合Adobe、CrowdStrike、IBM、Microsoft、Red Hat等成立了开放安全AI联盟（OSAA），共同开发共享AI安全工具。这次的平台发布，可以看作OSAA第一阶段成果的落地形态之一。

这方案解决了什么真问题

Agent失控的工程痛点是真实存在的。一个Agent在权限范围内做正常推理、执行工具调用时，系统往往缺乏有效的运行时阻断能力。一旦它越界访问不该碰的文件、发起不该走的网络请求，或者泄露凭证，发现时通常已经造成实际损害。

分层防御的逻辑是解决这个问题的标准路径：软件层负责策略定义和执行，硬件层负责隔离和兜底。

Agent安全分层架构

Agent安全分层架构

从架构图可以看到，Agent的每次工具调用都要经过硬件层的实时检测。这种设计的前提是Sentry必须能够低延迟地拦截异常行为，否则策略层就会形同虚设。

落地门槛与取舍

谁应该用这个平台？短期内，已经在生产环境运行Agent的团队、尤其是涉及金融、医疗、基础设施等高敏感领域的团队，是主要目标用户。

怎么用最关键的一点：Sentry依赖BlueField-4硬件，不是所有部署环境都具备这个条件。对于没有BFM-4芯片的基础设施，只能依赖OpenShell的策略层，缺少硬件级隔离兜底。

Agent安全平台采用决策

Agent安全平台采用决策

风险点也很明确：OpenShell的策略配置一旦有误，可能会导致合法Agent行为被误拦截；Sentry的硬件依赖则限制了大规模快速部署的可行性。这两个问题目前没有官方给出的明确答案，属于需要在具体场景里自行验证的部分。

下一步判断

短期内，能今天就做的动作有三个：第一，评估现有Agent部署是否有文件访问或网络调用的安全风险；第二，申请试用OpenShell开源版本，在测试环境验证策略配置效果；第三，确认基础设施是否支持BlueField-4，评估Sentry的部署条件。

长期来看，这个平台如果能在100家伙伴生态里形成事实标准，那么Agent安全的讨论重心会从「有没有安全措施」转向「有没有使用英伟达的标准方案」。这对供应商格局的影响，会比技术细节本身更大。

坦白讲，AI Agent的安全治理已经从实验室问题变成了工程基础设施问题。英伟达这次的选择是直接把这道题写进硬件层，而不是留给软件层自行解决。能不能真正落地，取决于硬件依赖能不能在可预见的未来变得不再那么严苛。

OpenShell：策略如何真正跑起来

OpenShell是开源运行时沙箱，最早在2025年GTC大会上亮相，现在被纳入安全平台统一管理。它的工作方式很简单：在Agent执行时拦截文件访问、网络请求、工具调用和凭证使用，按预定义策略强制执行或拒绝。

这意味着你不需要改Claude Code、Codex或任何已有Agent的代码。直接把它们套在OpenShell外面，策略由外部层统一约束。安全不再依赖Agent的「自觉」。

程序员 reaction：madwithmememonkeys

策略下沉到运行时，Agent不用改代码

具体配置层级有三层：

  • 全局策略：定义哪些工具可以调用、哪些域名可以访问
  • 项目策略：针对特定仓库或代码库的细化规则
  • 用户策略：按角色分配不同权限范围

这种分层设计让安全策略可以复用，也可以按需覆盖。某个团队在测试环境中用宽松策略，生产环境自动切换到严格模式。策略文件是声明式的，版本控制，变更可审计。

真正的问题在于策略的编写质量。写松了等于没写，写紧了Agent跑不起来。业内常见的做法是先用宽松策略跑一段时间，收集日志，再逐步收紧。这是一个迭代过程，不是一次性配置。

Sentry：芯片层的硬隔离意味着什么

Sentry是这个平台真正的新东西。它把威胁检测和策略执行下沉到英伟达BlueField-4数据处理单元（DPU），独立于Agent运行。

这里的关键词是「独立」。传统安全方案要么在操作系统层（容易被绕过），要么在应用层（需要Agent配合）。Sentry的做法是脱离GPU主系统，在数据路径上单独做监控。

agent_request --[网络]--> [Sentry on DPU] --[允许/拒绝]--> compute_cluster

具体机制是：所有Agent的输入输出流量经过DPU时，Sentry实时分析内容，检测是否包含敏感信息、是否触发生成恶意代码、是否违反访问控制规则。发现问题立即隔离，不影响主计算集群运行。

这相当于在Agent和计算资源之间装了一道硬防火墙。即使Agent自身被劫持或被利用，攻击流量也在到达GPU之前被拦截。

正文图解 4

正文图解 4

硬件级隔离的优势很明显：即便Agent进程崩溃或被篡改，DPU上的Sentry仍然正常工作。这不是软件层面的冗余，而是物理层面的隔离。

代价是基础设施要求。你需要BlueField-4 DPU或同级别的数据处理单元。中小企业如果要部署这套方案，成本不菲。

真实场景下的Agent安全部署

这套方案适合什么样的场景？

典型场景一：企业内部Agent平台

大型企业在内部部署多个Agent用于代码审查、文档生成、数据分析。OpenShell可以统一管控这些Agent的访问权限，防止它们读取不该读的文件或访问不该连的服务。Sentry提供额外的硬隔离层，即使某个Agent被利用，也不会影响其他服务和数据。

典型场景二：客户数据隔离的多租户Agent服务

如果你的Agent服务要处理客户敏感数据，比如金融客户的交易记录、医疗客户的诊断信息，双层安全机制几乎是必需的。OpenShell做软隔离，Sentry做硬隔离，两层层层兜底。

典型场景三：Agent开发与测试环境

开发阶段可以用宽松策略，让Agent自由探索。上线前切换至严格策略，由OpenShell强制执行边界。这种策略切换是声明式的，不需要改Agent代码。

部署时的取舍需要考虑几个维度：

  • 基础设施成本：需要DPU或同等级网络设备，不是随便一台GPU服务器就能跑
  • 策略复杂度：初始配置和持续维护需要安全工程师介入
  • 性能开销：DPU处理会引入微秒级延迟，对延迟敏感的场景需要评估
  • 兼容性：并非所有Agent框架都适配OpenShell，需逐一验证

某金融机构在2026年Q2的复盘显示，他们在部署这套方案时，策略编写阶段花了三周，初始配置两周，兼容性测试两周。整体交付周期约七周，远超预期。但之后发现，这个周期主要来自策略调试，而非技术本身的问题。

这套方案的边界在哪

任何方案都有适用范围。这套平台的核心假设是：你的Agent跑在GPU基础设施上，且你有能力部署DPU设备。两个条件不满足，这套方案的价值大打折扣。

有GPU基础设施

有GPU基础设施

没有DPU，Sentry的功能无法完整落地。你只能用OpenShell做运行时策略，缺少硬件级隔离层。这种情况下，方案价值减半，但仍有价值——至少比完全裸奔强。

边界二：Agent类型限制

这套方案针对的是自主运行的Agent系统，比如代码Agent、分析Agent、自动化Agent。对于简单的对话式Chatbot、固定流程的RPA脚本，这套机制显得过重。杀鸡用牛刀，ROI不划算。

边界三：合规驱动的必要性

如果你的业务没有数据合规要求，或者Agent处理的都是公开数据，那么投入成本可能超过风险规避收益。合规压力越大，这套方案的性价比越高。

某团队在内部讨论时曾提出一个问题：如果我们的Agent只处理非敏感数据，是否还需要Sentry？答案是否定的。OpenShell足够。Sentry的价值在于「万一」——当Agent被利用、当攻击流量进来、当运行时策略失效时，硬件层还能兜底。

另一个边界是策略维护成本。策略不是一劳永逸的。Agent功能升级、新工具接入、新风险出现，都需要策略同步更新。某安全团队的数据显示，策略维护工作量约占整体运维的30%。这个比例在业务变化频繁的团队中可能更高。

还有一个常被忽视的边界：策略冲突。多个Agent共用一套策略时，可能会出现互相覆盖的情况。A团队的政策要求禁止外部网络访问，B团队的Agent需要调用外部API。这种情况下，需要在策略引擎层面做好优先级管理，或在不同Agent间做策略隔离。

下一步的判断

对于有GPU基础设施、需要部署生产级Agent的企业，这套方案值得认真评估。OpenShell可以立即试用，Sentry需要基础设施配合。建议先跑通OpenShell的策略执行，验证Agent兼容性，再评估是否需要引入DPU层。

对于没有基础设施条件的团队，可以先关注OpenShell的开源实现，评估是否能在现有环境中部分复用。某些策略机制可以移植到通用安全网关上，虽不是原生日文，但方向一致。

英伟达这次的动作不是孤立的。两个月前（2026年7月），他们联合Adobe、CrowdStrike、Microsoft等成立OSAA（开放安全AI联盟），这个平台是联盟成果的延续。从联盟到平台，从研究到工程，英伟达正在把AI安全从口号变成可落地的产品。

这背后是一个更清晰的行业信号：AI安全的下一个战场不是模型本身，而是Agent的运行环境。谁掌控了Agent的信任基础设施，谁就站在AI应用的入口。

参考文献

延伸入口

文末收口图

avatar
文章
阅读
粉丝