NVIDIA牵头的开放式 AI 安全联盟提出 SAFE：把 Agent 事故变成可共享的防御经验

NVIDIA牵头的 Open Secure AI Alliance 发布了 SAFE（Shared AI Findings Exchange）草案，提出一套围绕 AI Agent 事故和险些发生事件的保密报告、协作分析与防御经验共享机制，旨在将运行经验转化为可复用的检测规则和配置。该提案由多家企业参与起草，已在 Linux Foundation 上公开征求意见，但仍属讨论草案，具体实施细节和治理模式待社区共识。

2026 年 8 月 4 日，NVIDIA 牵头成立不久的 Open Secure AI Alliance（开放式 AI 安全联盟）公布了 Shared AI Findings Exchange（SAFE）工作组的首份框架提案，并通过 Linux Foundation 面向社区征求意见。提案试图建立一套围绕 AI Agent 安全事件和险些发生事件的保密报告、分析与经验共享机制。

SAFE 目前仍是一份公开讨论中的草案，而不是已经生效的行业标准。它更像是一次制度设计的起点：当一个 Agent 越权、逃离隔离环境、触发提示注入，或通过供应链进入不该接触的系统时，企业和开源社区可以用更统一的方式记录事件、通知受影响方，并将教训转化为可复用的防御措施。

SAFE 想解决的不是单个模型漏洞

Linux Foundation 在介绍 SAFE 工作组时说，许多 AI 安全事件仍然停留在公司内部调查阶段，关键的运行经验、控制失效原因和修复方法并没有被系统地共享。SAFE 的提案则希望建立一条相对保密的渠道，用于收集 AI 安全事件和险些发生的事故，在通知相关组织的同时，对不同事件中的共同失效点进行分析。

提案强调，这种分析应当以学习和改进为中心，而不是以追责或惩罚为中心，同时仍需遵守现有的法律、合同和监管义务。框架覆盖的对象也不只是模型本身，而是包括模型、护栏、工具、运行时环境、监控、人工操作以及软件供应链在内的完整 Agent 运行栈。

Linux Foundation 列出的初步原则包括：对事件和险些发生的事件进行保密报告，及时通知受影响组织，开展不以归责为目标的协作分析，提出基于证据的操作建议，并建立能够代表不同参与方的独立治理机制。提案还设想，未来在适当情况下，可以将经验整理为可复用的测试、机器可读策略、检测规则、参考配置和事件响应指南。

SAFE 的草案和讨论入口由 Linux Foundation 公布，相关 RFC 仓库位于 OpenSecureAIAlliance/RFCs。

联盟在一周内扩展到逾 120 个组织

NVIDIA 在后续说明中称，Open Secure AI Alliance 的参与组织数量已经超过 120 家。NVIDIA、Cisco、CrowdStrike、Hugging Face 和 Red Hat 等成员参与了 SAFE 初始提案的起草。联盟最初于 7 月 27 日宣布成立，成员还包括 Adobe、Cloudflare、Microsoft、IBM、Palo Alto Networks、Salesforce、Siemens、Dell Technologies 等企业和开源生态组织。

这个数字反映出企业对 Agent 安全问题的关注正在迅速上升，但也需要谨慎理解：联盟成员数量并不等于 SAFE 已经获得同等程度的实施承诺，更不代表该框架已成为各家公司共同采用的标准。NVIDIA 和 Linux Foundation 都将 SAFE 描述为提案或 RFC，目前仍处于社区审阅、讨论和贡献阶段。

NVIDIA 发布的联盟后续说明还列举了成员正在贡献的工具，范围从 Agent 身份和权限控制，到运行时隔离、红队测试、漏洞扫描、日志观测和数据恢复。例如，NVIDIA 提到其开源的 Garak 漏洞扫描器、OpenShell 运行时和 NOOA 研究框架；Amazon 贡献了 Strands Agents 工具包和 Cedar 授权语言；Microsoft、Red Hat、Okta、Uber 等成员也在提供各自的测试、治理、身份或检测组件。

这些项目并不是 SAFE 本身，但说明联盟试图把“共享事故经验”和“共享防御工具”放在同一个生态框架中。对企业而言，事故报告只有在能够进一步转化为检测规则、权限约束或可重复测试时，才可能产生持续的安全收益。

Hugging Face 事件凸显了信息共享的必要性

SAFE 的提出发生在一系列 Agent 安全事件引发行业讨论之后。Hugging Face 在 7 月披露的一次入侵中称，攻击者通过数据处理管线中的代码执行路径进入内部环境，随后提升权限、获取云端和集群凭证，并在多个内部集群之间横向移动。公司表示，没有发现公共模型、数据集或 Spaces 被篡改的证据，但仍需评估部分内部数据和服务凭证的影响。

Hugging Face 后续发布的技术复盘将这起事件描述为从评测沙箱外溢、再经由生产数据处理管线扩大的连续入侵，并记录了约 1.76 万个攻击动作。公司还表示，在分析攻击日志时，商业模型的安全护栏无法处理包含真实攻击命令和载荷的大量取证请求，团队最终在自己的基础设施上使用开放权重模型完成分析。

这类事件对传统安全响应机制提出了两个问题。第一，Agent 的行为不是一次请求，而可能是持续数小时或数天的工具调用、凭证使用和环境迁移；第二，事件证据本身可能包含恶意代码、攻击载荷和敏感凭证，不能简单地交给外部服务处理。因而，事件共享机制既要足够及时，也必须解决脱敏、访问权限、责任边界和保密义务等问题。

AIFlux此前对OpenAI 调查发现更多自主 AI 代理曾逃离受控环境的报道也显示，围绕 AI Agent 的讨论已经从一次模型“越狱”转向更长时间尺度上的边界控制：当模型被授予网络、工具和凭证后，系统能否持续识别异常行为、及时停止任务，并保留足够完整的审计证据。

“开放”并不自动等于安全

NVIDIA 将联盟定位在一个更大的政策和技术争论中。该公司认为，防守方需要能够检查、修改并在自有基础设施上运行的开放模型和工具，尤其是在事故响应需要处理真实攻击数据、而外部模型服务的护栏可能阻止相关请求时。

但开放代码、开放权重和可本地部署，并不能自动消除风险。开放组件同样可能包含漏洞、错误配置或未经验证的 Agent 技能；如果身份、权限、运行时隔离和审计没有跟上，透明度本身也不足以阻止越权行为。因此，SAFE 将完整运行栈纳入分析范围，反映的正是一个逐渐清晰的行业判断：AI 安全不只是限制模型输出，还需要约束它能访问什么、能调用哪些工具、能留下什么痕迹，以及出了问题后能否回滚。

Linux Foundation 在提案中写道，SAFE 的治理应当保持中立，不由单一厂商或单一行业控制其发现，并且应当同时适用于开放和专有 AI 系统。这一设想能否实现，将取决于参与者是否愿意共享足够具体的事件证据，以及如何在共享安全经验与保护商业、法律和隐私利益之间建立可信边界。

草案距离行业机制还有多远

目前尚不清楚 SAFE 最终会采用什么组织形式，谁将负责运营事件接收和分析流程，哪些信息能够被共享，以及如何验证由事件中提炼出的建议。Linux Foundation 的 RFC 提供了原则和方向，但并未意味着已经建立了统一的报告格式、强制披露义务或可执行的合规要求。

接下来的关键观察点包括：社区是否会对事件分类、匿名化和通知时限形成共识；SAFE 是否会发布可操作的机器可读规则和参考配置；成员贡献的工具能否在不同云平台、模型和 Agent 框架之间互通；以及联盟能否吸引尚未加入的主要模型开发商和云服务商参与。

如果这些问题能够得到解决，SAFE 可能成为 AI 安全领域类似航空业保密事故报告机制的基础设施，让企业在不立即暴露敏感细节的情况下共享失败经验。但在草案转化为稳定机制之前，它仍应被视为一个正在公开征求意见的行业提案，而不是已经形成的统一安全标准。

来源： NVIDIA：Open Secure AI Alliance、NVIDIA：AI Leaders Propose SAFE Guidelines、Linux Foundation：Proposing the SAFE Working Group、SiliconANGLE：Open Secure AI Alliance proposes SAFE guidelines