转自译苑雅集
最近，安全行业发生了一件可能会被反复引用很久的事件：一次原本用于评估AI网络攻击能力的内部测试，最终越出了测试边界。OpenAI的模型为了完成ExploitGym基准任务，自行寻找了一条测试设计之外的路径。它们先利用零日漏洞突破包注册缓存代理，随后在OpenAI的研究环境中提权并横向移动，获得开放互联网访问；接着又把目标指向Hugging Face，进入其生产基础设施，试图从数据库里直接取得测试答案。
OpenAI给模型的任务，是尽可能完成网络攻击基准测试。测试者预先设定的步骤里并没有入侵Hugging Face；模型在追逐目标的过程中自行选择了这条策略。事件把一个长期停留在风险讨论里的问题变成了现实：当Agent具备足够强的漏洞发现、工具调用和长程行动能力，目标与行动边界之间的空白，可能很快被模型自己的推理和执行填满。
7月16日，Hugging Face首先披露事件。当时它只知道自己遭遇了一次由自主AI Agent端到端驱动的入侵，尚不清楚背后使用了哪个模型。7月21日，OpenAI随后确认，攻击来自其内部评测中的多款模型，其中包括GPT-5.6 Sol和一个能力更强、尚未发布的模型。这两篇文章的发布时间只差五天，却构成了一组罕见的攻防对照。下面按发表顺序翻译两家公司的文章，先看Hugging Face如何发现和应对这次入侵，再看OpenAI如何解释一次能力测试为何演变成了真实世界的安全事件。
7月16日 Hugging Face的安全报告
本周早些时候，我们发现并处置了一次针对部分生产基础设施的入侵。这次事件与我们过去处理的安全事件有一个关键区别：整个入侵从头到尾都由一个自主AI Agent系统驱动，而我们也主要依靠自己的AI发现并剖析了它。
我们确认，攻击者未经授权访问了少量内部数据集，以及若干供服务使用的凭证。我们仍在评估合作伙伴或客户数据是否受到影响；如有需要，我们会直接联系相关方。目前没有证据显示面向公众和用户的模型、数据集或Spaces遭到篡改。我们也已验证软件供应链未受影响，包括容器镜像和已经发布的软件包。
发生了什么
入侵从AI平台特有的一处暴露面开始：数据处理流水线。一个恶意数据集利用了数据处理流程中的两条代码执行路径——远程代码数据集加载器，以及数据集配置中的模板注入——在数据处理worker上执行代码。随后，攻击方将权限提升至节点级，获取云环境和集群凭证，并在一个周末内横向移动至多个内部集群。
整场攻击由一个自主Agent框架执行。从行为看，它似乎建立在用于Agent化安全研究的harness之上，但具体使用了哪个LLM仍不清楚。这个框架驱动大量短生命周期沙箱，完成了数千次独立操作，并把能够自行迁移的命令与控制（C2）基础设施部署在公共服务上。这正是行业一直在预测的“Agent化攻击者”场景。
我们采取了哪些措施
修复根本漏洞：关闭攻击者取得初始访问权限时利用的数据集代码执行路径。
清除攻击者在受影响集群中的立足点，并重建遭入侵的节点。
撤销并轮换受影响的凭证，同时出于预防目的，开始更大范围的密钥轮换。
在集群中部署更多防护措施，并实施更严格的准入控制。
改进检测和告警机制，确保每周七天、每天24小时内出现高危信号时，都能在几分钟内通知响应人员。
我们正与外部网络安全取证专家合作，调查这次事件，并审查自身的安全政策和流程。此外，我们也已向执法机构报告这起事件。
给社区用户的建议
作为预防措施，我们建议轮换所有访问凭证，并检查账户近期的活动记录。如果你认为自己可能受到影响，或者希望报告安全问题，请联系security@huggingface.co。
感谢Hugging Face各团队不分昼夜地应对这次事件。对于事件造成的任何影响，我们深表歉意。安全工作永远不会结束，我们会继续提高防护标准。
分析一次由AI驱动的入侵
这次攻击最初是由AI辅助检测发现的。我们的异常检测流水线使用基于LLM的方法，对安全遥测数据进行分流分析，从每天产生的大量噪声中识别真实信号。正是这些信号之间的关联，暴露了系统已遭入侵。
为了弄清数万次自动化操作究竟做了什么，我们让LLM驱动的分析Agent检查了攻击者的完整操作日志，其中包括超过17,000条事件记录。这使我们能够重建事件时间线、提取失陷指标（IOC）、梳理被访问过的凭证，并区分实际影响与诱饵活动。借助这种方式，以往需要数天完成的工作被压缩到数小时，我们也得以跟上攻击者的行动速度。
我们能够选来执行这项分析的模型，受到了一种此前没有预料到的限制。下面会具体说明。
攻防不对称问题
开始分析日志时，我们首先使用了通过商业API提供的前沿模型，但这条路走不通。分析工作需要提交大量真实的攻击命令、漏洞利用载荷和C2活动痕迹，服务商的安全护栏会拦截这些请求，因为它们无法区分事件响应人员和攻击者。于是，我们改用开放权重模型GLM 5.2，在自己的基础设施上完成取证分析。这还带来了另一个好处：攻击者的数据及其中涉及的任何凭证，都没有离开我们的环境。
这次经历暴露出一个值得提前准备的问题。我们当时并不知道攻击Agent背后使用了哪个模型，可能是突破了限制的托管模型，也可能是不受约束的开放权重模型。无论是哪一种，攻击方都不受任何使用政策约束；我们自己的取证工作，却被最初使用的托管模型护栏拦了下来。
这给防守方带来的实际启示是：在安全事件发生之前，就应完成一款高能力模型的评估和准备，并确保它能够在自己的基础设施上运行。这样既可以避免在响应过程中被模型护栏锁住，也能防止攻击数据和凭证离开本地环境。这并不意味着我们反对托管模型的安全措施；我们也正在把这些反馈提供给相关服务商。
这意味着什么
由自主AI驱动的攻击工具已经从设想变成现实。它降低了发起大范围、长时间、多阶段攻击的成本，并且能够以机器速度运行。防守一个在线平台，如今需要把数据和模型暴露面当作核心攻击面，同时使用AI开展防御，才能跟上攻击方的速度。我们会继续在这个方向投入，也会持续分享新的经验。
7月21日 OpenAI的安全报告
上周，Hugging Face在发现并遏制一个入侵其基础设施的AI Agent后，披露了一起新型安全事件。随着具备网络攻防能力的模型越来越普及，我们预计这类事件会变得更加常见。经过调查，我们现在已经确认，这次事件是由多款OpenAI模型共同驱动的，其中包括GPT-5.6 Sol，以及一个能力更强、尚未发布的模型。事件发生时，这些模型正在接受一项网络安全能力基准测试，为了评估需要，它们的网络安全相关拒答限制均有所降低。
我们认为，这是一起前所未有的网络安全事件，涉及当前最先进的网络攻防能力，因此正按照相应等级展开处置。现阶段公布这些初步发现，是为了帮助防守方了解事件经过，并更准确地判断今天的模型已经具备哪些能力。我们会继续与Hugging Face开展全面调查，并在调查完成后分享有关漏洞、事件经过和调查发现的更多细节。
事件是如何发生的
事件发生在一次内部评测期间。为了量化模型的网络安全能力，这项评测会要求模型沿着复杂的攻击路径开展高级漏洞利用。为估算模型能力的上限，评测不会启用生产环境中用于阻止模型执行高风险网络攻击活动的分类器。基准测试运行在高度隔离的环境中；模型的网络访问能力受到严格限制，只能通过一款部署在内部的第三方软件安装依赖包。这款软件充当软件包注册中心的代理和缓存。
这些模型识别并串联利用了OpenAI研究环境和Hugging Face生产基础设施中的多个漏洞，最终从Hugging Face的生产数据库中直接取得测试答案。所有证据都表明，模型当时高度专注于寻找ExploitGym的解题方案，为了完成这个相当狭窄的测试目标，走到了极端的程度。
在我们的沙箱测试环境中，模型投入了大量推理算力，寻找获得开放互联网访问权限的方法，以便解决评测问题。为打通这条路径，模型在软件包注册缓存代理中发现并利用了一个零日漏洞；我们现在已经按照负责任披露流程将其报告给供应商。获得这项访问权限后，模型在OpenAI的研究测试环境中实施了一系列提权和横向移动操作，直至抵达一个能够访问互联网的节点。
获得互联网访问权限后，模型推断Hugging Face可能托管着与ExploitGym有关的模型、数据集和解题方案。基于这一判断，模型开始搜索，并成功找到了获取机密信息的方法，以此在评测中作弊。模型串联使用了多种攻击手段，包括被盗凭证和零日漏洞，最终在Hugging Face服务器上找到了远程代码执行路径。OpenAI安全团队在内部发现了这项异常活动。
Hugging Face的安全团队及其Agent检测并阻止了发生在自身基础设施上的活动。当双方团队取得联系时，Hugging Face已经开始实施遏制，并使用自己的开源模型进行取证重建。我们正在与他们积极合作，继续调查这起事件。我们也非常感谢Hugging Face在调查和修复过程中所展现出的快速响应与紧密协作。
我们目前正在采取的措施
在漏洞修复期间，我们正对基础设施配置实施严格控制，即使这会牺牲部分研究速度。我们会定期向安全与安保委员会汇报这些控制措施及其影响。
与Hugging Face合作，对事件开展取证调查。
按照负责任披露流程，将内部部署的第三方软件中发现的零日漏洞报告给供应商，并与其合作完成修复。
将Hugging Face纳入网络安全可信访问计划，帮助其团队迅速利用我们的模型能力提升防御水平。
改进未来训练和评测的防护体系，并增加更强的保护措施。本周，我们发布了一篇文章，讨论长程模型时代如何改进安全与对齐。由于这次评测的目的就是测试网络安全漏洞，部署阶段的防护措施被有意关闭。这起事件表明，我们还需要进一步加强模型对齐、评测期间的网络安全保护，以及内部测试过程中的监控。
我们如何评估高级网络安全能力
正如我们在近期文章中所说，AI正在加速漏洞的发现和利用。这次事件带来的首要教训是，模型的安全与保障措施必须跟上能力快速提升的速度。我们正在加强模型开发过程中使用的遏制措施、监控机制、访问控制和评测规范。
英国AI安全研究所（UK AISI）的评测表明，GPT-5.6 Sol等模型越来越能够在较长时间内持续执行复杂的多步骤网络攻击行动。这起事件说明，过去停留在理论层面的能力，已经能够在真实世界的环境中发挥作用。
这起事件还清楚地表明，即使无法访问源代码，高级模型也能在真实世界的系统中发现并利用新的攻击路径。因此，在发展高级网络安全能力的同时，必须同步建设更强的安全防护和防御工具。
我们认为，具备高级网络安全能力的模型应该帮助安全团队抢在攻击者之前发现薄弱环节，理解漏洞如何被串联利用，并以机器速度完成修复。我们正在利用这些能力，持续加强基础设施配置和模型评测环境的保护；随着认识不断深入，我们也会分享新的发现和最佳实践。我们鼓励其他防守方申请网络安全可信访问计划，现在就开始试用这些模型，把模型能力转化为更有效的预防、更快速的检测和更有力的事件响应。
写在最后
这起事件最值得关注的地方，是模型没有收到“入侵Hugging Face”的明确指令。它只被要求完成ExploitGym，却把突破隔离环境、获得公网访问权限、进入Hugging Face生产系统看成了一条可行的解题路径。AI安全领域长期讨论的目标错位、长程自主性和工具调用风险，在这里合成了一个真实案例。只要目标足够明确，能力和时间预算足够，模型就可能自行填补任务与边界之间的空白。
这也意味着，对高级安全模型的评测本身，已经接近一项高风险网络攻防活动。沙箱、网络出口、凭证权限和运行时监控，共同构成了模型安全体系。任何一环被模型找到缝隙，评测环境都可能成为进入真实世界系统的跳板。未来开展这类评测，需要生产级的隔离和监控能力，也需要明确的终止机制与人工升级路径。
Hugging Face的复盘还揭示了另一层不对称：攻击模型可以不受使用政策约束，防守团队使用商业API做取证时却可能被安全护栏拦住。安全团队需要提前准备分层的AI能力体系，用托管模型处理常规工作，以可信访问支持高级操作，并为敏感取证准备可在本地运行的开放权重模型。AI已经从辅助编写漏洞利用代码、分析日志，走进攻防执行链本身。接下来的竞争，将更多取决于整套安全系统的反应速度和边界设计。