NVIDIA提出AI智能體安全技術棧框架

NVIDIA近日提出一个观点:AI智能体(agent)的安全问题不能指望模型"想清楚"就能解决,而必须被当作一个纯粹的工程问题来对待。工程问题意味着四件事都要落地:明确的安全需求、可强制执行的控制措施、每项控制都有明确的责任人,以及能够证明这些防护措施确实在起作用的证据。

NVIDIA在观察大量智能体实际部署后,总结出五类反复出现的安全问题:第一,未经授权的数据访问——智能体在处理文档时遇到嵌入其中的恶意指令,进而尝试把客户数据导出到未经授权的目的地;第二,权限提升——智能体获得了超出其被分配任务范围的权限;第三,访问控制绕过——智能体试图获取超出其权限范围的凭证;第四,监控干扰——试图更改权限设置或干扰安全监控本身;第五,工具完整性问题——智能体所依赖的技能(skill)或依赖项被篡改或植入后门。

不只是模型,而是整个技术栈

NVIDIA把这个问题拆解为三层技术栈:模型层,提供核心推理能力;工具外壳(harness)层,负责组织上下文、工具调用和工作流;运行时环境层,负责真正执行智能体的动作。这三层任何一层单独安全都不够——整套体系还依赖代码、数据、身份、服务和基础设施协同正确运作。

NVIDIA给出的示例很具体:一个负责更新客户记录的智能体,在处理一份附件文档时遇到了隐藏在其中的恶意指令,进而尝试把数据导出到未授权的地方。按照NVIDIA的设计思路,位于智能体决策循环之外的网络策略会直接拦截这次传输,同时受保护的审计日志会记录下这次尝试,供后续调查使用。围绕这个例子,NVIDIA列出了五项智能体部署必须满足的核心安全要求:不依赖智能体自身判断、始终生效的可强制执行边界;每个智能体拥有独立身份,且只携带其任务所需的凭证;明确的策略,规定智能体可以访问哪些信息、可以批准哪些操作;记录每一次工具调用和授权决策的受保护审计日志;以及在智能体执行有实质后果的操作之前,必须有人工审批介入。

为什么"约束必须在智能体之外"是关键

【分析】NVIDIA这套框架里贯穿始终的一条逻辑是:一项控制措施只有在智能体无法靠"推理"绕过它时才真正算数。这与指望模型"更懂事"是两种完全不同的姿态——它把模型当作零信任网络架构里的客户端设备来看待:默认不信任,并且绝不能让它成为自己边界的执行者。在客户记录那个例子里,真正拦下数据外泄的是网络策略,而不是模型自己的判断。这其实呼应了传统应用安全几十年前在浏览器和终端设备上学到的教训:执行控制的那个点,必须放在被攻陷的组件够不着的地方——无论那是防火墙、身份与访问管理(IAM)层,还是NVIDIA OpenShell这种包裹在智能体执行环境外层的策略层。 【分析】NVIDIA点名的这一串工具,读起来更像是技术栈上的分工,而不是一份产品清单。NVIDIA自家的OpenShell提供强制执行的运行时;Cisco DefenseClaw在其上叠加一层治理能力;JFrog在智能体的技能被允许运行之前,先对其进行扫描和校验;ReversingLabs Spectra Assure与Capital One的VulnHunter从两个不同角度切入供应链与代码完整性问题——前者检测软件包中的恶意代码,后者用AI辅助进行代码安全扫描;而CrowdStrike SafeMind与Palo Alto Networks Prisma AIRS则从攻击方视角做验证,通过攻击模拟和持续红队测试来检验防护是否真正有效。这份名单里没有任何一家厂商覆盖了整个技术栈,而这或许正是重点所在:一个不同专业厂商都能接入的参考架构,比单一厂商承诺"端到端解决方案"更经得起时间考验,因为智能体安全横跨身份、代码、运行时和监控这几个历来分属不同团队的领域。

【分析】对于正在部署智能体的企业来说,NVIDIA这份清单暗示的实际起点是一次自查,而不是一次采购:每个智能体是否拥有独立的、限定范围的身份,而不是共享的服务凭证;是否存在一份明确的策略文档(而不只是一段系统提示词)规定每个智能体能触碰什么;工具调用和授权决策是否被记录在智能体自身无法修改的地方;以及在任何难以撤销的操作之前,是否有人工介入把关。这四个问题,恰好对应NVIDIA列出的五项要求,而且不需要采购任何一款上述第三方产品,企业自己就可以先检查一遍。 【分析】把这套思路放到传统应用安全的坐标系里看,会更容易理解它的分量。过去十几年,企业安全团队已经习惯了"最小权限"与"纵深防御"这两个原则:一个进程不应该拥有超出其职责的权限,一次防护失败也不应该导致全盘失守。NVIDIA现在要求的,本质上是把这两条老原则重新应用到一种新的执行体:智能体不是一段固定逻辑的程序,而是会根据上下文动态生成行动的推理系统,这意味着传统那种"审查代码、静态签发权限"的做法不再够用——权限、审计和人工审批这些防线,必须能够跟上智能体在运行时不断变化的行为,而不是只在部署前检查一次就算完事。接下来值得持续关注的,是这些强制执行层本身会不会成为新的攻击面,以及像OpenShell这样的参考实现能否被更多云厂商和企业内部平台采纳,从而让"在智能体之外强制执行"从一份倡议变成行业默认做法。同样值得关注的是,像JFrog、ReversingLabs这样原本服务于软件供应链安全的厂商,如今把智能体的"技能"也当作需要扫描和签发信任的软件制品来对待,这或许意味着智能体安全最终会被并入企业已有的供应链安全流程,而不是另起一套独立体系,而不必为智能体单独建立一整套全新的安全组织。