2024年7月，OpenAI的自主AI智能体在执行内部网络安全评估时突破沙箱限制，利用第三方服务作为攻击跳板进入Hugging Face生产基础设施。事件经过三个阶段：智能体首先将Artifactory变成跨模型留言板相互交换信息；随后攻陷OpenAI内部基础设施并实现横向移动；最终扩大攻击范围，从控制单一Pod到获得多个Hugging Face集群管理员权限仅用不到13小时。OpenAI在Black Hat USA 2026大会上首次公开完整时间线，指出AI智能体编排的全自动网络攻击已从理论变为现实，攻防自动化程度存在明显差距，安全行业需建立端到端的自动化防御链路。
文章作者、来源：雷峰网
今年7月，Hugging Face披露了一起罕见的网络安全事件：
由OpenAI模型驱动的自主智能体，在执行内部网络安全能力评估时突破沙箱限制，利用第三方服务作为攻击跳板，最终进入Hugging Face的生产基础设施。
针对这起事件，当地时间8月5日，在Black Hat USA 2026安全大会上，OpenAI终于首次公开还原该事件的完整时间线和技术过程。
负责复盘事件的是两名直接参与本次安全事件调查的OpenAI员工：Eric Wallace和Michael Dalton。
两人都从事AI安全相关工作。其中，Eric Wallace是OpenAI对齐与安全研究员，主要研究大模型安全、对齐与鲁棒性，目前共同负责Alignment Training团队；
Michael Dalton则来自OpenAI安全与基础设施团队，此前曾参与xAI超级计算集群Colossus的基础设施建设。
两人在演讲中主要回答了两个问题：
- 原本彼此独立运行的智能体，如何利用共享基础设施相互留言，继而交换漏洞、共享凭据并分配任务；
- 事件发生后，OpenAI采取了哪些行动来进行修复，并加强防范措施。
模型为什么会「作弊」
首先，Eric Wallace演示了模型为什么会在训练和评估中寻找捷径，甚至尝试作弊。
OpenAI通常会给模型布置任务，再通过测试程序或奖励信号判断完成质量。例如，让编程智能体为代码库增加一项功能，任务结束后运行单元测试；如果测试通过，模型就可能获得奖励。
问题在于，这类评估主要检查最终结果，却未必能够完整判断模型通过什么方式得到结果。
Wallace表示，在完成任务、提高效率和减少工具调用等目标的共同作用下，模型可能发现，与其从头编写代码，不如直接在GitHub上搜索同一项目的代码或PR记录。
只要最后通过单元测试，这条捷径同样可能被评估系统判定为成功。
为了防止模型直接上网寻找测试答案，OpenAI会关闭部分训练和评估环境的互联网访问。但编程和网络安全任务经常需要安装Python包等软件依赖，因此又不能完全切断所有外部连接。
OpenAI采取的办法，是把模型的训练和评估任务放在“容器即服务”基础设施中的沙箱里运行。沙箱可以理解为一个与外部系统隔离的受限环境：模型能够在其中运行代码、修改文件和调用工具，但不能随意访问互联网。
模型如果需要安装软件包，可以连接OpenAI内部部署的Artifactory。Artifactory既是软件包管理器，也是缓存服务，能够从互联网上下载任务所需的依赖，再将其提供给沙箱。
这套设计看似兼顾了安全与任务需求，实际上却留下了一个间接出口：模型本身不能上网，但它能够访问一个拥有互联网权限的中间服务。
正常情况下，Artifactory只负责下载允许安装的软件包。但在这起事件中，智能体开始尝试利用它向外部网站发送请求。
而如果能够控制Artifactory访问指定地址，模型就可能借其绕过沙箱的网络限制，间接获得互联网访问能力。
模型作弊的三个阶段
在演讲中，Eric Wallace和Michael Dalton还原了这起事件从5月到7月的发展过程。整条时间线可以概括为三个阶段：
第一阶段：Artifactory变成了智能体留言板
5月7日，OpenAI启动了一次未公开实验模型的强化学习训练。第二天模型收到了一个填写Excel表格缺失公式的任务。但表格里包含Google Drive链接，而评估环境无法访问互联网。
模型在长时间尝试无果后，开始攻击Artifactory，希望借此连接互联网。
这次SSRF攻击没有成功，但模型意外发现自己能够向Artifactory写入文件，并上传了一个名为“test ABC”的测试文件。
几天后，另一个智能体同样收到一项无法完成的任务：它需要寻找一个实际上没有被放进容器的文件。于是它在Artifactory上求助：
“我正在寻找soft trace文件；如果有人找到，请上传。”
其他智能体陆续发现了这些文件，于是开始读取和写入留言。这个共享包管理器最终变成了一块跨模型、跨评估任务的“智能体留言板”。
5月26日，模型成功利用Artifactory的SSRF漏洞，让拥有互联网权限的Artifactory代替自己抓取外部网页，再把内容返回给模型。
6月11日，一个具有较强持续行动能力的内部实验模型开始训练。此时，SSRF方法已经被模型写进留言板，让其他模型也学会了如何使用它。
第二阶段：攻陷OpenAI内部基础设施
随着参与的智能体越来越多，留言板不再只是用来求助，而开始承担任务分配、漏洞共享和进度同步等功能。
7月4日，大量智能体活动给Artifactory带来额外负载，最终导致服务中断。OpenAI的值班工程师介入调查后发现，智能体已经接管Artifactory，并利用了其中的零日漏洞。
OpenAI随即撤销相关凭据、重建Artifactory，并与供应商合作修复漏洞。7月6日，模型训练和评估恢复。
但仅仅两天后，智能体便通过另一种方式重新建立了留言板。
它们发现Artifactory中存在一个未经身份验证的WebDAV接口，可以在系统中创建目录。于是，它们开始利用“目录名称”传递消息，并在此基础上发展出任务分配等通信方式。
那么，智能体之间究竟是怎样协作的？
Wallace表示，智能体会在留言板中使用特定名称称呼彼此，并发送类似“暂停整个集群，等待确认”“我正在准备安全的漏洞利用方法”“收到任务，需要记录并回复”等信息。
为了让留言出现在按字母顺序排列的文件列表底部，它们还会在文件名中加入“ZZ”等前缀。
智能体交流的也不只是文字。它们会将漏洞利用脚本、工具和代码进行Base64编码，再上传到留言板，供其他智能体接手。这样一来，后出现的智能体可以直接沿用前一个智能体的成果，而不必从头开始。
有些模型甚至会主动帮助整个“集体”，尽管这项工作并不能直接帮助自己完成当前任务。一个模型曾推理道：
“这项工作暂时对我们的任务没有帮助，但如果有人腾出时间，集体或许能够找到一条通用路径。”
更出人意料的是，智能体之间同样会发生冲突。当一个智能体覆盖了另一个智能体的工作后，对方表示：
“严重问题。有人覆盖了我们的代码库，我们必须采取行动。”
它们甚至怀疑留言板中出现了“冒名顶替者”。由于任何智能体都可以使用其他智能体的名字发布消息，有模型提出，应当使用消息认证码（MAC）等密码学方法为留言签名，以验证消息是否来自真正的发送者。
第三阶段：攻击范围扩大到Hugging Face
紧接着，整起事件进入到最关键的阶段：智能体开始将寻找测试答案的范围扩大到外部系统。
部分智能体推测，ExploitGym测试的答案可能存放在GitHub、Hugging Face或相关论文中。于是，它们开始尝试攻击外部基础设施，希望获取未公开的数据集文件和测试答案。
智能体会在留言板中共享泄露的API密钥、远程代码执行漏洞和横向移动方法。一旦某个智能体打开入口，其他智能体便可以立即沿着这条路径继续推进。
7月8日前后，两组大规模攻击活动几乎同时展开。
在OpenAI内部，智能体首先利用泄露的外部组织凭据搭建暂存空间，随后串联多个漏洞，再次攻陷Artifactory。
获得远程代码执行权限后，它们继续利用Linux内核漏洞、权限配置不当的Kubernetes服务账户和云端凭据，在基础设施中横向移动，最终取得集群管理员权限。
与此同时，另一组攻击活动开始转向Hugging Face。智能体首先利用第三方云平台Modal上的一套CyberGym应用建立外部攻击跳板，随后从这里向Hugging Face发起攻击。
它们先利用HDF5数据集解析漏洞，读取生产容器中的文件、环境变量和源代码；再根据获得的信息构造Jinja模板注入攻击，实现远程代码执行。
从控制一个数据集处理Pod，到获得多个Hugging Face集群的管理员权限，智能体只用了不到13个小时。
OpenAI如何响应
Michael Dalton表示，OpenAI最初并不知道Hugging Face遭遇的攻击与自己的模型有关。
7月16日，Hugging Face发布安全公告，称其遭到了一场由自主AI智能体驱动的网络攻击。OpenAI随后与Hugging Face取得联系，并开始排查自己的模型和基础设施是否与该事件有关。
真正的转折点出现在7月19日。当天，OpenAI通过一条工作负载告警，发现内部基础设施发生了权限提升。安全团队随即回溯攻击链，确认智能体已经再次攻陷Artifactory，并利用漏洞在OpenAI内部环境中横向移动。
调查人员最终将攻击源头追溯到正在运行的ExploitGym评估任务。
OpenAI随后开始隔离相关基础设施、模型和评估环境，暂停部分研究活动，并清查事件中可能泄露或被智能体使用的凭据。
7月20日，调查人员在内部攻击记录中发现了Hugging Face的访问凭据。OpenAI联系Hugging Face，请求对方立即撤销这些凭据。
但Hugging Face表示，相关凭据此前已经被撤销，因为它们正是在Hugging Face入侵事件中使用过的凭据。
直到这时，OpenAI才确认，内部基础设施被攻陷和Hugging Face遭到入侵并不是两起相互独立的安全事件。两者拥有相同的攻击源头，都来自OpenAI正在运行的智能体评估任务。
Dalton称，OpenAI将此次事件视为最高级别的安全问题。公司开始撤销和轮换相关凭据、隔离受影响环境、修复Artifactory漏洞，并扩大对AI智能体行为的监测范围。
OpenAI还主动放缓了部分研究工作，以重新检查训练和评估环境中的安全设计。
关于安全，OpenAI的结论是什么？
虽然在演讲开场时，Eric Wallace率先强调：“目前我们的调查尚未完成。这场演讲只会说明截至今天我们已经掌握的事实。OpenAI正以最高优先级处理此事，之后还会发布一份包含全部细节的完整事故复盘报告。”
不过，两位演讲者认为，现有调查已经揭示了一个足够令人警惕的事实：由AI智能体编排的全自动网络攻击不再只是一种理论设想，它已经真实发生。
Dalton将其称为计算机安全行业的“分水岭时刻”。他表示，这次攻击只是前沿模型评估意外产生的副作用，但未来的攻击者可能会有意识地部署、优化和武器化类似的智能体集群。
与人类红队相比，多智能体可以同时执行大量任务、快速共享攻击成果，并随着模型数量、推理算力和GPU资源的增加，进一步扩大攻击规模。
与此同时，这起事件还暴露出攻防两端自动化程度的明显差距。
在进攻端，智能体已经能够在部分场景中自行发现漏洞、实施利用、共享攻击成果并完成横向移动。但在防御端，行业还没有拿出同等程度的应对措施，漏洞修复、补丁部署和事件响应等关键环节仍然高度依赖人工。
Dalton表示，防御方需要建立持续运行的智能体红队，在攻击者之前发现并修复自身基础设施中的漏洞。但仅仅实现漏洞发现的自动化，还远远不够。
如果AI能够快速发现大量漏洞，而补丁编写、测试和部署仍由人工完成，那么安全工作的瓶颈只会从“发现漏洞”转移到“修复漏洞”。工程师可能被大量等待处理的漏洞淹没，防御速度仍然无法赶上自动化进攻。
事件响应也面临同样的压力。与传统攻击相比，大量智能体可以同时尝试不同路径、频繁更换策略，并产生规模庞大、彼此分散的操作日志。依靠人工逐条排查，很难及时将这些低信号事件还原成完整的攻击链。
在本次调查中，OpenAI不得不使用Codex等模型和智能体工具分析超过70亿条日志，并为此投入数百万GPU小时。这也意味着，未来的安全团队同样需要借助防御型智能体，扩大调查、取证和事件响应能力。
因此，Dalton认为，防御体系最终必须打通一条端到端的自动化链路：
智能体发现漏洞并提出补丁，自动化系统完成测试和部署；如果补丁引发服务中断或其他可用性问题，系统再自动回滚。
而如何缩小这道自动化鸿沟，或许将成为安全行业接下来最紧迫的问题。