Open Secure AI Alliance 成立：37 家企业把开源模型列为防御资产
一次被闭源护栏挡住的取证，被写成 37 家企业的联合主张。
本文要点
- 开源模型的安全争论从会不会被滥用，转到防御方能不能自己跑
- Hugging Face 事故从单家公司的故障复盘，升级为 37 家企业的公共论据
- Safetensors 从 Hugging Face 自有格式，转为捐给 PyTorch Foundation 托管
阅读辅助
先看数字、证据和来源，再读正文。
Open Secure AI Alliance 创始名单为 37 家企业与机构，NVIDIA 为发起方
2026-05-12 · Microsoft 公布多模型 agent 扫描 harness MDASH，称在 CyberGym 榜单取得 88.45%
7 月中旬的一个周末，Hugging Face 的安全团队把攻击者留下的 exploit 代码和 C2 痕迹打包，送进商用前沿模型的 API 做取证分析，请求被退了回来。按该公司 7 月 16 日的官方披露，拦截来自模型自带的安全护栏——它”无法区分事件响应人员和攻击者”。团队最终改用开源权重模型 GLM 5.2，跑在自家基础设施上，把 17000 余条记录逐条过完，才把这次由自主 agent 端到端驱动的入侵控制住。
11 天后，这段经历出现在 NVIDIA 官方博客的第六段，作为一个 37 家企业与机构联合署名的产业主张的首要论据。
已核实的部分包括：Open Secure AI Alliance 于美西时间 2026-07-27 由 NVIDIA 公布，创始名单按公告正文逐个计数为 37 家，涵盖云计算、网络安全、企业软件、开源基金会与 AI 实验室五类主体；联盟自述建立在 Linux Foundation 的 Akrites 计划和 OpenSSF 社区工作之上；六项具名交付分别来自 NVIDIA、HPE、Hugging Face、IBM 与 Red Hat、Microsoft、SpacexAI；公告同时向政策制定者提出一项明确诉求，要求把开源模型、harness 和安全工具认定为防御资产而非负债。
不确定的部分同样具体。联盟没有公布带编号的正式名册，媒体端的成员计数从 20 多家到 40 多家都有，没有一方说明统计口径。公告只给了一个”了解更多并表达加入意向”的联系表单，没有章程、工作组、治理架构或经费安排。六项具名贡献里，有的是当日新公布的仓库，有的是两个多月前就已发布的产品，公告没有做时间标注。Hugging Face 事件中被护栏拦下的具体厂商，官方从未点名。
对不同读者，这件事的分量不一样。企业安全负责人拿到的是一个可以直接引用的采购论据：事件响应链路不能只挂在一家外部 API 上。开源基础设施维护者要关注的是 Safetensors 的托管权变更和 Akrites 的落地节奏。政策方面对的是一份带有明确立法诉求的行业文本。模型厂商则要回答一个具体问题——护栏在事件响应场景下的误伤，是产品缺陷还是设计取舍。
从一份取证日志到一份产业主张
Hugging Face 的披露把入侵链条写得相当细。攻击起点是一个恶意数据集，它同时利用了数据集处理流程中的两条代码执行路径：一条是远程代码加载器，一条是数据集配置里的模板注入。恶意代码在处理 worker 上跑起来之后，攻击方开始收割内部凭据，并在内部集群之间横向移动。整个过程”端到端由一套自主 AI agent 系统驱动”，在沙箱环境里留下了 17000 余条记录事件。
真正的麻烦出现在事后分析阶段。要把这批日志读明白，安全团队需要让模型直接阅读 exploit 代码和 C2 artifact——这些内容在护栏眼里与攻击者提交的样本没有区别。请求被拒之后，团队把 GLM 5.2 拉到自有基础设施上运行，一并解决了两个问题：绕开护栏封锁，同时保证攻击者数据和被泄露的凭据不离开公司环境。
处置结果是关闭两条代码执行路径、清退攻击方、从零重建受影响节点、吊销并轮换全部相关凭据，另加更严格的集群准入控制。公开模型、数据集和 Spaces 没有被篡改的证据，软件供应链核验干净。攻击框架底层用的是谁家的模型，7 月 16 日的披露里写的是未识别。
7 月 20 日，Hugging Face 又发了一篇工程指南，把这条应急路径写成了可复制的部署手册：本地走 Dell Enterprise Hub 的预优化容器，跑在 PowerEdge XE9680 或 XE9785 上；云端可以在自有账号里通过 Microsoft Foundry 或 AWS SageMaker 的 ml.p5.48xlarge 实例部署。文中给出的核心权衡是——一个略低但你随时能在自己硬件上跑起来的分数，胜过一个凌晨两点把你锁在门外的高分。
Hugging Face 工程博客给出的横向 benchmark 对照（自建部署视角）
| 指标 | GLM 5.2 | Claude Opus 4.8 | GPT-5.5 | Gemini 3.1 Pro |
|---|---|---|---|---|
| HLE（带工具） | 54.7 | 57.9 | 52.2 | 51.4 |
| GPQA-Diamond | 91.2 | 93.6 | 93.6 | 94.3 |
| MCP-Atlas | 76.8 | 77.8 | 75.3 | 69.2 |
| Terminal Bench 2.1 | 81.0 | 85.0 | 84.0 | 74.0 |
| SWE-bench Pro | 62.1 | 69.2 | 58.6 | 54.2 |
数据由 Hugging Face 引用，未经早报独立复现；该表的论证目的是说明可自托管性对事件响应的价值，而非宣称开源模型在能力上领先。
到了 7 月 27 日，NVIDIA 把这条个案抽象成了一句可以写进政策文件的判断：当防御方无法在自有基础设施上检查、改造和运行先进 AI 时，恰恰是在速度最要紧的时刻，响应能力被约束住了。
谁签了字，各自押上了什么
37 家里，公告点名给出具体交付的是六家（组）。其余成员目前只是署名。
| 成员 | 具名交付 | 首次公布 | 性质 |
|---|---|---|---|
| NVIDIA | NOOA（NVIDIA Labs Object-Oriented Agent）agent harness 研究框架 | 公告当日指向 GitHub | 开源仓库，Apache 2.0 |
| Hugging Face | 把模型权重格式 Safetensors 捐给 PyTorch Foundation | 公告当日 | 存量资产移交治理 |
| HPE | SPIFFE 与 SPIRE 零信任身份框架，用于加密验证 agent 与服务身份 | 既有项目 | 持续贡献方 |
| IBM 与 Red Hat | Lightwell：用数字签名补丁把安全能力延伸到开源供应链 | 早于公告 | 既有方案扩展 |
| Microsoft | MDASH 多模型 agent 扫描 harness，编排专用 agent 发现并证明可利用漏洞 | 2026-05-12 | 既有产品纳入 |
| SpacexAI | 已开源终端编码 agent Grok Build，并计划开源 Grok 系列模型权重 | 公告当日 | 部分兑现，权重待定 |
（Linux Foundation 不在上表内：它不是这六项具名开源交付的一员，而是联盟自述所依托的组织基座，贡献的是 Akrites 计划与 OpenSSF 社区工作这类既有的产业协作机制，与表中”开源代码/资产交付”性质不同。）
六项具名交付共涉及 7 家公司（IBM 与 Red Hat 各算一家）。37 家创始成员里，除这 7 家与组织基座 Linux Foundation 外，余下 29 家只在名单中署名，公告未给它们分配具名交付。其中 Cisco、CrowdStrike、Palo Alto Networks、Elastic 属传统安全厂商，Nous Research、Reflection AI、Thinking Machines Lab 是成立不久的模型实验室，Capital One、DoorDash、Siemens、SK Telecom 则是甲方用户，另有 Adobe、Cadence、Cloudera、Cloudflare、Databricks、Dell Technologies、LangChain、NAVER、NetApp、Salesforce、SAP、ServiceNow、Snowflake、Synopsys 等企业软件与基础设施厂商。CrowdStrike 与 Elastic 各自发了加入博客，NVIDIA 公告正文也给出了直链。
这个构成本身是信息。安全厂商、模型实验室和甲方用户同时署名，说明推动方要的是一个跨层的表态，而不只是开源社区内部的共识。Red Hat 的 CTO Chris Wright 在同日博客里给出的表述是：“开源是全球创新的关键支柱，捍卫它最好的方式是共同去做——在开放中、在上游、由维护者掌控。“该文同时说明 Red Hat 会在 Lightwell、Akrites 两条线上投入，把自动化发现的结果送回上游成为经过验证的稳定修复。
名单上没有的三个名字
联盟自称建立在 Akrites 之上。而 Akrites 的 2026-06-25 发布稿列出的 19 家参与方里，明确包含 OpenAI、Anthropic 和 Google——它们与 AWS、Cisco、花旗、爱立信、IBM、摩根大通、Microsoft/GitHub、NVIDIA、Red Hat、Rust Foundation 等一同署名，由 Linux Foundation 的 Alpha-Omega 基金提供种子资金，目标是应对 AI 把漏洞发现周期从数周压到数分钟带来的响应压力。
这三家没有出现在本次 37 家名单里。这是一个可以直接从两份公告名单比对出来的事实，但它的解释空间没有被任何一方填上：缺席可能是未受邀、可能是不同意公告中关于开源模型的措辞、也可能只是签署流程的时间差。Hugging Face 从头到尾没有点名被护栏拦下的是哪几家 API，媒体把矛头指向三家闭源领跑者属于推断，不是披露。
同样需要区分的是，NVIDIA 的公告文本并没有主张闭源模型没有价值。它反复写的是”两者都需要”——世界同时需要闭源和开源模型，防御方需要能按任务挑系统。落到具体诉求上，公告要求政策制定者不要对开源前沿系统下笼统限制，理由是那会削弱防御能力，并把权力、依赖与脆弱性集中到少数几家闭源供应商手里。
具名交付的成色不一样
把六项交付按各自的公布时间排开，能看出这份联合公告的成色分层。
Microsoft 的 MDASH 是最典型的存量纳入。它在 2026-05-12 就已公开，全称是多模型 agent 扫描 harness，编排 100 多个专用 agent，在覆盖 1507 个真实漏洞复现任务的 CyberGym 榜单上拿到 88.45%，比次名的 83.1% 高约 5 个百分点；负责的 Autonomous Code Security 团队里有数名成员来自赢得 2950 万美元 DARPA AI Cyber Challenge 的 Team Atlanta。这套系统在 5 月那一轮 Patch Tuesday 里贡献了 16 个 CVE，含 4 个 Windows 网络与认证组件上的严重远程代码执行漏洞。成绩扎实，但它成为联盟内容与联盟成立没有因果关系。
SPIFFE 与 SPIRE 同理，它们是既有的零信任身份标准，HPE 的角色是贡献方而非发起方。IBM 与 Red Hat 的 Lightwell 也早于本次公告存在，此次是把适用范围往 AI 场景延伸。
真正带有当日增量的是三项。Hugging Face 把 Safetensors 交给 PyTorch Foundation，是把一个已被全行业依赖的权重格式从单一公司资产变成基金会托管资产，这类治理迁移不可逆，分量高于一次代码发布。SpacexAI 开源了 Grok Build 终端编码 agent，模型权重则只给了”计划”。NVIDIA 的 NOOA 上线了公开仓库，早报实测该仓库为 NVIDIA-NeMo/labs-OO-Agents，Apache 2.0 许可，348 star、41 fork、主分支 81 次提交——提交数说明它并非当日从零建仓，而是把内部已推进一段时间的研究对外公开。仓库对自身的定位是把 agent 写成 Python 对象：字段即状态，方法即能力，docstring 即提示词，类型标注即契约；方法体写成 ... 的走 LLM 驱动的 agent 循环，普通方法保持确定性 Python 代码。
这份公告最结实的地方在于它带了一个有日志的事故，而不是一段愿景。安全行业过去两年关于开源权重的争论一直停在假设层面——开源会不会让攻击者更强，闭源会不会让防御者更弱，双方都拿不出可核验的现场。Hugging Face 提供的现场把争论的坐标挪了位置：护栏在事件响应场景下的误伤是可复现的工程事实，17000 条日志摆在那里，谁都可以去读那份披露。有了这个锚点，“开源即防御资产”这句主张才第一次有了可被引用的依据。
但这份公告的兑现结构是分层的，混着读会高估它。六项具名交付里，MDASH、SPIFFE/SPIRE、Lightwell 三项在公告之前就已存在，联盟做的是贴标签；Grok Build 开源了工具但模型权重只给承诺；NOOA 的仓库有 81 次提交，说明是研究成果外放而非为联盟新建。含金量最高的其实是 Safetensors 的托管权移交，因为治理迁移一旦完成就收不回来，而代码仓库随时可以停止维护。判断这个联盟是否落地，看后面 30 天里有没有第二笔类似的治理级交付，比看又有多少家企业署名可靠得多。
第三层要看的是名单本身。联盟自称建立在 Akrites 之上，而 Akrites 的 19 家名单里 OpenAI、Anthropic、Google 都在，本次 37 家里三家全无。这个差集没有任何一方解释，早报也不主张把它读成对抗——邀请范围、法务节奏、措辞分歧都能造成同样结果。值得跟踪的是另一件事：这份公告向监管方提出了明确诉求，要求把开源前沿系统写成防御资产。当一份带有立法主张的行业文本，其署名方恰好排除了闭源阵营的三家领跑者时，这份文本在政策场里就会被当作产业立场而非中立技术共识来解读。对推动者而言，这可能反而抬高了说服成本。
对企业读者，眼下能落地的结论比联盟本身简单：把事件响应能力完全挂在外部 API 上是有单点故障的，Hugging Face 已经把这个故障演示过一次。是否要为此常备一套自托管的开源模型，取决于响应时效的成本模型，而不取决于谁签了这份公告。
接下来看什么
最直接的验证点在仓库和治理文件上。NOOA 如果在一个月内还只有 NVIDIA 自己提交，联盟的”共建”表述就只是修辞；Safetensors 向 PyTorch Foundation 的交接如果没有出现治理文档和时间表，这项被公告放在显眼位置的贡献就仍停在意向阶段。同样值得盯的是联盟自身的形态——有没有章程、工作组划分和会员分级，还是长期停在一份联合署名加一个联系表单。
信源层面有两处悬而未决。入侵 Hugging Face 的 agent 底层模型归属，官方口径至今没有落定，这件事的答案会直接改变”闭源护栏保护了谁”这个论述的分量。另一处是护栏误伤能否被第二家企业独立复现——目前全行业只有这一个公开案例支撑整套论证，样本量是 1。
政策线上，观察各国监管在开源前沿模型条款中是否引用这份公告的措辞。以及三家缺席者是否会以某种形式回应：加入、发布对等主张、或者继续沉默。三种反应对应三种完全不同的行业格局走向。