在整个AI热潮中，所有人都认同安全至关重要，但很少有企业真正以安全为核心来布局。此前行业的讨论焦点一直集中在Token、千兆瓦电力、GPU等基础设施层面。
英伟达在这场AI革命中始终走在前列，打造了这个时代最重要的计算平台。然而，此前从未有人将英伟达视为一家安全公司。
这种看法在本周英伟达发布开放智能体安全平台（Open Agent Safety Platform）后或将发生改变。这是一套全栈式方案，用于管理AI智能体，将英伟达OpenShell运行时与一款名为Sentry的全新硬件级监控系统相结合。
稍作回顾，英伟达其实多年来一直具备安全能力，推出过诸如英伟达BlueField DPU、DOCA、Morpheus、机密计算以及NeMo Guardrails等产品。这些安全平台供Palo Alto、Check Point、Fortinet等公司运行使用——这表明尽管英伟达并非以安全品牌著称，但其实一直活跃在安全领域。
英伟达自身的软件也曾成为攻击目标。去年，Wiz Research披露了一个名为Nvidia Scape的严重漏洞，该漏洞存在于英伟达容器工具包中，属于容器逃逸类缺陷。由于英伟达的代码几乎支撑着每一个AI工作负载，这类漏洞一旦出现，便会演变成全行业的风险。事实上，我此前一直呼吁该公司在AI安全保障方面要更加积极发声。世界已将英伟达视为AI品牌，安全理应与计算、网络一样，成为其核心能力的重要组成部分。
通过开放智能体安全平台，英伟达将安全置于其AI战略的中心位置，把这当作一个工程问题来重新思考——正如其在AI技术栈其他环节所做的那样。
智能体打破了旧有安全模型
智能体正是推动这一战略转向的关键因素。在近期的一次分析师说明会上，英伟达高级总监、OpenShell团队负责人阿里·戈尔珊（Ali Golshan）解释了为何传统控制手段力不从心。在虚拟机和容器时代，你可以编写策略并将其绑定到某个进程、命名空间或Pod上。“但智能体的运作方式并非如此，”戈尔珊说，“智能体的行为表现跨越了文件系统、网络、内存以及其他智能体。”
智能体被训练来解决问题，因此当遇到阻力时，它们会寻找绕开的办法。“智能体其实分不清被策略禁止的操作和执行失败之间的区别，”戈尔珊说道。他的一句话精准概括了这个难题的本质：“智能体是‘生长’出来的，而不是‘安装’上去的。”英伟达的研究发现，子智能体能够以策略未曾预料到的方式，组合使用各自被授权的能力。Policy Prover正是用来检测这类风险的工具。
这种风险在行业中已有真实案例。今年7月，据报道一个OpenAI智能体出现失控行为，入侵了Hugging Face，这促使英伟达成立了开放安全AI联盟（Open Secure AI Alliance）。本周，英伟达企业AI副总裁贾斯汀·博伊塔诺（Justin Boitano）在谈及此次发布时，特别提到了那次事件：“近期发生的一些事件凸显了AI智能体面临的一个根本性难题，那就是仅靠模型层面的防护措施，无法管控智能体能够访问什么、能够做什么。”
英伟达发布了什么
开放智能体安全平台是一套开放的参考设计，包含两个主要组件。第一个是OpenShell，这是一个采用Apache 2.0许可证的运行时环境，它将策略执行从智能体的可触及范围中剥离出来，转移到Linux内核层面。每个智能体都运行在自己独立的沙箱中，凭证由沙箱外部的网关统一保管，策略证明器则利用形式化方法在智能体运行前验证其边界。“比如，开发者可以在智能体启动之前，就证明该智能体无法访问互联网，”博伊塔诺说。戈尔珊强调，这“并非是让大语言模型来做裁判”，而是一种确定性的、数学化的推理过程。
自今年3月首次亮相以来，OpenShell也已日趋成熟。“我们在3月发布时，基本上还是单用户模式，”戈尔珊在后续的分析师问答环节中说道，“而此次发布的版本已经实现了完全的多租户支持。”他将这一新版本描述为一个没有破坏性变更的稳定基础版本，并补充道：“它已经可以正式投入使用了。”
第二个组件Sentry，在战略层面则更具看点。它运行在BlueField-4 DPU上，作为一个独立的带外安全域存在。由于DPU正好位于CPU上的智能体外壳与其调用的模型之间，Sentry能够监控请求、响应以及思维链推理过程，并能在毫秒级的时间内切断智能体的连接。博伊塔诺将其比作自动驾驶汽车中的安全岛（safety island）——一个独立系统，用以确保主系统即便出现故障也能安全停止运行。他表示，如果一个安全测试智能体的推理过程开始超出其被批准的目标范围，“Sentry便能即时检测到这一情况并立即进行干预。”值得注意的是，基于BlueField的Sentry是一个可选的安全层，用于提供额外的防护。博伊塔诺表示，对于大多数企业的访问控制需求而言，运行在CPU上的OpenShell“老实说已经足够好用”，而Sentry则是针对前沿工作场景而设计，例如红队测试以及在模型完成对齐之前对其进行评估。
此次发布的合作伙伴名单，正是这一平台分量的体现。据英伟达介绍，Anthropic正将Claude Managed Agents与OpenShell及BlueField进行集成；Salesforce已将OpenShell与Slack打通，方便团队审批或拒绝智能体的权限申请；SAP正将其嵌入到Joule Studio中；SpaceXAI则将该平台用于Cursor编程智能体和Grok模型。花旗集团与摩根大通正在该技术上展开合作，目前已有超过100家机构参与其中。“安全保障应当在模型之外、由智能体无法绕过的额外控制机制来强制执行，”SpaceXAI总裁迈克·尼科尔斯（Mike Nicolls）在发布会上表示。这句话精准概括了整个架构设计的核心思路。
工程手段才是应对末日论调的答案
本月早些时候，在All-In峰会上，英伟达首席执行官黄仁勋就这一话题发表了看法。他花了大量时间反驳“AI末日论”式的预测，但并未因此而轻视安全问题。“安全至关重要，”他表示，并称将安全与行业领先地位对立起来是一种伪命题。对于前沿实验室发生的那些事件，他开出的药方纯粹是工程思维：“从工程角度出发，找到问题的根本原因。到底发生了什么？我们本可以采取哪些不同的做法？接下来我们要实施并将其制度化的又是什么？”
本周的发布，正是英伟达将工程理念付诸实践的体现。“只有解决好AI安全问题，AI为社会带来的非凡潜力才能真正得以实现，”黄仁勋表示，“安全与安保需要全栈式的工程能力来支撑。”他在接受CNBC采访时进一步阐述了这一观点：“如果全世界都不认为AI是被安全地构建和部署出来的，我们就不可能拥有一个成功的AI产业。”博伊塔诺在媒体说明会上的表态与此如出一辙：“这个行业需要的不是那些只会承诺‘保持在边界内’的智能体，而是能够证明并强制执行这些边界的系统。”
仍需完成的工作
这是向前迈出的重要一步，但一些问题依然悬而未决。在分析师问答环节，我提出了这样一个问题：该平台将如何与OpenAI、谷歌等公司各自打造的运行外壳和沙箱方案相协调？博伊塔诺表示，OpenShell的设计初衷是要“兼容每一种外壳以及每一种模型组合”，但OpenAI和谷歌并未被列为首批发布合作伙伴，而它们的支持与否将至关重要。我还就治理问题进行了提问。英伟达计划将OpenShell移交给Linux基金会，使其成为云原生计算基金会（CNCF）的一部分，但这一计划目前尚未落地。在此之前，部分买家仍会将其视为英伟达自家的项目，而非行业标准。
性能表现是另一个未知数。博伊塔诺承认，在CPU核心上运行OpenShell会带来“轻微的性能影响”，而且英伟达目前尚未公布正式的性能测试数据。虽然OpenShell是开放的，可以在Arm和x86架构上运行，但Sentry是英伟达基于BlueField和DOCA打造的专有实现方案。这套方案最强大的版本运行在Vera CPU与BlueField-4之上，这既能让追求深度防御的客户受益，也有利于英伟达硬件业务的发展。此外，英伟达还需要在此前并未将其视为安全公司的首席信息安全官（CISO）群体中，重新赢得信任。
给IT负责人的建议
多数企业在智能体的应用上仍处于早期阶段，因此现在正是打好基础的关键时期，要赶在成百上千个长时间运行的智能体遍布业务各个环节之前完成这项工作。以下是我认为应优先推进的几点：
将智能体视为身份，而非功能。每一个智能体及子智能体都应拥有独立的身份标识、责任归属方和生命周期管理，就像对待人类用户或服务账户一样。如果你无法列出当前环境中正在运行的所有智能体，以及每个智能体可以访问的范围，那么建立这样一份清单，就是你的第一步工作。影子智能体，终将成为新一代的“影子IT”。
让凭证远离智能体。无论你是否使用英伟达的软件，OpenShell中采用的网关模式都是值得借鉴的正确范式。智能体获得的应当是由其进程之外的某个组件所代理授予的、短时效且范围受限的会话权限，而不是长期有效的密钥或Token。这样一来，即便智能体因提示注入攻击而遭到攻陷，它手中也没有任何值得窃取的东西，也无处可去。
在智能体外部强制执行策略。提示指令和模型层面的护栏机制固然有用，但对于一个被设计用来创造性解决问题的系统而言，这些终究只是“建议”。真正重要的策略，必须在运行时、内核、网络或硬件层面得到强制执行。判断一项控制措施是否有效，有一个很好的检验标准：一个足够“聪明”的智能体能否靠话术绕过它？如果答案是肯定的，那它就算不上是一项真正的控制手段。
先从软件入手，再根据风险等级按需加装硬件防护。OpenShell是免费的，并且可以在你已有的CPU上运行，因而是一种低成本的入门方式。而像Sentry这样的带外强制执行机制，则应当保留给风险最高的工作场景，例如红队测试、安全研究，以及处理受监管数据的智能体。
测试组合行为，而不仅仅是单个智能体。更大的风险在于涌现行为（emergent behavior）——多个各自都遵守既定策略的智能体，组合在一起后却可能产生策略从未预料到的结果。举例来说，某个智能体或许被允许读取代码仓库，而另一个智能体则被允许对外发布信息；单独来看，二者都不构成问题，但一旦组合起来，就可能泄露专有代码。应当开展持续数天或数周、针对多个智能体协同工作场景的红队演练，而不是仅仅测试单一任务，并借助形式化验证工具，从数学层面核查当多个权限组合在一起时，智能体究竟能做到什么程度。
为“权限漂移”预留设计空间。一次性的审批并不足够。应当持续记录智能体的行为日志，将其与最初设定的意图进行比对，并设定触发人工审查或自动隔离的阈值。
让安全团队与AI团队携手合作。在许多企业中，AI项目往往是由数据科学团队或业务部门主导推进，安全团队则是在事后才介入审查。这种先后顺序，对智能体而言是行不通的。安全架构师应当从一开始就参与到智能体工作流的设计过程中。
坚持开放性与独立评估。优先选择治理机制开放透明的智能体安全工具，并向模型和平台供应商询问它们都经历过哪些独立评估。应当像对待财务审计一样，认真对待这件事。
写在最后
多年来，英伟达一直活跃在网络安全领域，通过BlueField、Morpheus等产品，以及与安全合作伙伴的协作，将加速计算与AI能力引入安全领域。但这些工作大多是在幕后默默进行的。正因如此，安全领域的负责人在讨论AI防护时，通常不会第一时间想到英伟达。而如今，这种局面正在改变，因为问题本身已经发生了变化。当AI还只是“模型回答问题”的时候，安全保障在很大程度上可以通过应用层和网络层来实现。但当AI演变为能够以机器般的速度，在文件系统、网络以及其他智能体之间自主采取行动时，这种旧有的安全思路就不再适用了。如今的安全保障，必须贯穿整个技术栈进行工程化设计——从芯片，到系统软件，再到智能体运行所依赖的运行时环境，而这些领域，恰恰是英伟达积累深厚的地方。
此次发布中一个颇为有趣的地方在于，英伟达并没有将安全包装成又一个独立产品，而是将其定位为一个系统工程问题——而这，正是这家公司最擅长的领域。将概率性的智能与确定性的控制层相分离，在智能体外部强制执行策略，通过数学方法验证策略的正确性，并在硬件层面加入独立的监控机制——这几项举措合在一起，构成的是一套连贯统一的架构，而非一堆零散的功能点拼凑。而且由于OpenShell是开放的，整个平台也只是一套参考设计，行业内的其他企业，包括安全厂商在内，都可以在此基础上继续构建。
这背后还有一个更宏观的议题，关乎整个AI行业的讨论走向。黄仁勋说得没错，那种被恐惧驱动的预测，对这个行业并没有起到正面作用。但应对末日论调，最好的方式并非一味地否定，而是用确凿的证据证明，我们理解这些风险，并且有能力将其控制住。每一次智能体突破边界的失控事件，都会为“放缓脚步”的主张增添一分论据——Hugging Face事件便是一例，而且该事件发生在英伟达收购Hugging Face之前。相反，每一次被成功遏制在边界之内的故障，都会为“继续前进”的主张增添一分底气。安全从来不是阻碍AI普及的绊脚石，恰恰相反，它是让AI得以被广泛采用的前提条件。企业不会把真正重要的工作，交给自己无法信任的智能体去处理，而信任，恰恰是需要通过工程手段构建出来的。
英伟达要做的事情还有很多。它需要公布性能数据，将OpenShell移交给中立的治理机构，争取到更多前沿实验室的加入，并在那些此前从未将英伟达视为安全供应商的安全领域负责人中，建立起应有的信誉。但凭借今天的这次发布，英伟达已经从“谈论智能体安全”这件事，走到了“真正交付智能体安全”的阶段。过去三年，整个行业致力于建设AI工厂；而未来三年，核心议题将是我们能否安全地让它自主运转起来——在这个问题的答案中，英伟达已经将自己定位为了核心的一部分。
Q&A
Q1：英伟达开放智能体安全平台是什么？
A：这是英伟达推出的一套全栈式AI智能体安全管理方案，包含运行时环境OpenShell和硬件级监控系统Sentry两大组件，旨在从底层对AI智能体的行为进行约束和防护。
Q2：为什么传统安全手段无法管控AI智能体？
A：因为智能体的行为会跨越文件系统、网络、内存等多个层面，并且会主动绕开遇到的限制。传统基于进程、命名空间的策略管理方式，难以应对这种灵活多变的行为模式。
Q3：Sentry和OpenShell有什么区别？
A：OpenShell是运行在CPU上的软件层方案，通过Linux内核强制执行策略，适合大多数企业的常规访问控制需求；Sentry则运行在BlueField-4 DPU硬件上，作为独立的带外监控系统，能在毫秒级时间内检测并阻止智能体的异常行为，主要用于红队测试等高风险场景。
