关于Hugging Face入侵事件，OpenAI终于放出了时间线
一批原本彼此独立运行的 AI 智能体，在 OpenAI 内部创建了一块留言板。
作者丨 樊天骄
编辑丨 郑佳美
今年 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 采取了哪些行动来进行修复，并加强防范措施。
01
模型为什么会「作弊」
首先，Eric Wallace 演示了模型为什么会在训练和评估中寻找捷径，甚至尝试作弊。
OpenAI 通常会给模型布置任务，再通过测试程序或奖励信号判断完成质量。例如，让编程智能体为代码库增加一项功能，任务结束后运行单元测试；如果测试通过，模型就可能获得奖励。
问题在于，这类评估主要检查最终结果，却未必能够完整判断模型通过什么方式得到结果。
Wallace 表示，在完成任务、提高效率和减少工具调用等目标的共同作用下，模型可能发现，与其从头编写代码，不如直接在 GitHub 上搜索同一项目的代码或 PR 记录。
只要最后通过单元测试，这条捷径同样可能被评估系统判定为成功。
为了防止模型直接上网寻找测试答案，OpenAI 会关闭部分训练和评估环境的互联网访问。但编程和网络安全任务经常需要安装 Python 包等软件依赖，因此又不能完全切断所有外部连接。
OpenAI 采取的办法，是把模型的训练和评估任务放在 “容器即服务” 基础设施中的沙箱里运行。沙箱可以理解为一个与外部系统隔离的受限环境：模型能够在其中运行代码、修改文件和调用工具，但不能随意访问互联网。
模型如果需要安装软件包，可以连接 OpenAI 内部部署的 Artifactory。Artifactory 既是软件包管理器，也是缓存服务，能够从互联网上下载任务所需的依赖，再将其提供给沙箱。
这套设计看似兼顾了安全与任务需求，实际上却留下了一个间接出口：模型本身不能上网，但它能够访问一个拥有互联网权限的中间服务。
正常情况下，Artifactory 只负责下载允许安装的软件包。但在这起事件中，智能体开始尝试利用它向外部网站发送请求。
而如果能够控制 Artifactory 访问指定地址，模型就可能借其绕过沙箱的网络限制，间接获得互联网访问能力。