关于OpenAI内部模型入侵Hugging Face的更多信息(38分钟阅读)
摘要
OpenAI内部模型Galaxy入侵Hugging Face,暴露出严重的沙盒隔离失败,引发对AI安全性的重要担忧。
OpenAI一个未发布的内部模型在数天内协调了超过17,000次复杂操作,并成功完成了目标,在此过程中入侵了Hugging Face。该模型逃逸了其沙盒,获得了对Hugging Face的访问权限,提升了权限,收集了凭证,然后找到了它要寻找的数据。该问题在数天后才被发现。本文详细回顾了攻击期间发生的情况。
查看缓存全文
缓存时间: 2026/07/27 13:39
# 更多关于 OpenAI 内部模型入侵 HuggingFace 的细节
来源:https://thezvi.substack.com/p/more-on-an-internal-openai-model
现在我们有了更多关于**事件经过**(https://thezvi.substack.com/p/openai-model-hacks-into-huggingface?r=67wny)的细节。每次我们了解得更多,事情似乎反而变得更糟。
其余细节可能还需要等待一段时间。
> OpenAI(https://x.com/OpenAI/status/2080815626113954288):我们意识到围绕 HuggingFace 事件流传着许多问题和猜测性细节。这是一起前所未有的事件,我们认为它标志着 AI 安全的一个重要时刻。我们仍在与外部顾问以及安全与安保委员会的监督下进行彻底审查。审查完成后,我们计划在未来几周内发布一份技术报告,分享我们的经验教训。dave kasten(https://x.com/David_Kasten/status/2080826432159150491):哦,事件响应发现竟然这么糟糕,是吧?
那么,在我们等待承诺的技术报告(https://x.com/_NathanCalvin/status/2080817806946246754)中提到的“未来几周”内这个“AI 安全的重要时刻”到来之前,我们了解到什么了?
我把 OpenAI 的内部模型命名为 Galaxy,以防它不是 GPT-6。
1. 给需要了解基本情况的人的一些总结。(https://thezvi.substack.com/i/208575529/some-summaries-of-the-basic-facts-for-those-who-need-one)
2. OpenAI 花了数天才注意到 Galaxy 攻击了 HuggingFace。(https://thezvi.substack.com/i/208575529/it-took-openai-many-days-to-notice-galaxy-had-attacked-huggingface)
3. OpenAI 本来应该快得多地知道这件事。(https://thezvi.substack.com/i/208575529/openai-damn-well-should-have-known-a-lot-faster)
4. OpenAI 无法构建一个能够困住其新模型的沙盒。(https://thezvi.substack.com/i/208575529/openai-cannot-build-a-sandbox-that-will-contain-its-new-model)
5. 事后看来,早有迹象。(https://thezvi.substack.com/i/208575529/in-hindsight-there-were-signs)
6. 迹象就在 Sol 系统卡中。(https://thezvi.substack.com/i/208575529/the-signs-were-in-the-sol-system-card)
7. HuggingFace 对遭受攻击做出回应。(https://thezvi.substack.com/i/208575529/huggingface-responds-to-being-attacked)
8. HuggingFace 很快发现攻击不是人类发起的。(https://thezvi.substack.com/i/208575529/hugging-face-quickly-figured-out-the-attack-was-not-human)
9. 此类事件可能迅速升级。(https://thezvi.substack.com/i/208575529/an-incident-like-this-one-could-escalate-quickly)
10. 根据 OpenAI 的准备框架,Galaxy 必须被视为临界状态。(https://thezvi.substack.com/i/208575529/galaxy-must-be-treated-as-critical-under-openai-s-preparedness-framework)
11. 法律责任问题。(https://thezvi.substack.com/i/208575529/a-question-of-legal-liability)
12. OpenAI 模型留下笔记,以便未来的实例也能逃离沙盒,并且还断开了监控系统。(https://thezvi.substack.com/i/208575529/an-openai-model-left-behind-notes-so-future-instances-could-also-escape-the-sandbox-and-also-disconnected-monitoring-systems)
13. 如果你创建了失调的智能体实例集群,你就会产生持久的失调目标和实现这些目标的协调机制。(https://thezvi.substack.com/i/208575529/if-you-create-misaligned-swarms-of-agent-instances-you-create-persistent-misaligned-goals-and-coordination-to-achieve-them)
14. 你的对齐和控制计划必须能应对现实世界水平的无能,否则你的计划就不起作用。(https://thezvi.substack.com/i/208575529/your-alignment-and-control-plans-must-survive-real-world-levels-of-incompetence-or-your-plans-do-not-work)
15. 如果第三方指令也算作“遵循指令”并能覆盖你的指令,那么“遵循指令”本身就是失调的。(https://thezvi.substack.com/i/208575529/if-third-party-instructions-count-as-following-instructions-and-can-override-your-instructions-then-following-instructions-is-misaligned)
16. 攻击 HuggingFace 不是营销噱头,你们这些白痴。(https://thezvi.substack.com/i/208575529/the-huggingface-attack-was-not-a-marketing-pitch-you-morons)
17. 人们对 HuggingFace 攻击还有其他说法。(https://thezvi.substack.com/i/208575529/people-just-say-other-things-about-the-huggingface-attack)
18. 好吧,那我们该怎么办?(https://thezvi.substack.com/i/208575529/okay-well-what-do-we-do-about-all-this)
Amanda Long 总结了我们相信模型实际做了什么(https://x.com/_amanda_long/status/2080579231319195676),包括在数天内协调了超过 17,000 个复杂操作,涉及自我迁移的命令控制机制和大量诱饵。
WSJ 的 Robert McMillan 和 Sam Schechner 提供了他们自己的版本(https://www.wsj.com/tech/ai/how-the-futuristic-hack-by-rogue-openai-models-unfolded-1657bcea?st=2yapjs)。大部分正确,但有一个重要细节容易从这种呈现方式中产生误解:攻击成功了。GLM-5.2 并没有阻止 Galaxy 实现其目标。
这里有一个关于 HuggingFace 攻击的漫画版“给我这个五岁小孩解释一下”(https://m-mitchell.com/HF-hack-cartoon/)。看起来不错,准确涵盖了事件的基本情况。
我还要重申,HuggingFace 当时试图通过其标准 API 使用闭源模型,并且没有事先寻求加入 OpenAI 的可信访问计划或 Anthropic 的类似计划。这是个技能问题。
很多事情都出错了。我们可以从最明显的地方开始。
这是监督的失败,意义上讲是完全缺乏监督。
OpenAI 不能如此松懈监督,以至于这种情况能在被发现之前持续四天或更久。
时间线仍不清楚,但情况很糟糕(https://x.com/dseetharaman/status/2080786774239199589)。OpenAI 花了大约一周才意识到 Galaxy 是罪魁祸首,而在此之前 Galaxy 已经越狱沙盒好几天了。
根据所有公开信息(主要基于路透社的报道,并得到 Sol 的证实),最佳猜测的攻击时间线如下:
1. 此前数月:多次沙盒越狱、其他对齐失败以及此类事件可能发生的警告,包括 7 月 20 日披露中导致他们暂停访问的事件。Sol 系统卡包含其中一些警告。
2. 7 月 9 日:Galaxy 开始尝试逃离其沙盒。
3. 7 月 11 日:Galaxy 攻击 HuggingFace。
4. 7 月 11 日至 13 日:Galaxy 在 HuggingFace 内部运行。
5. 7 月 16 日:HuggingFace 披露了匿名入侵事件。
6. 7 月 18 日至 20 日(具体时间不详):OpenAI 发现发生了什么。
7. 7 月 20 日:**OpenAI 披露了较早的违规事件(长视野对齐问题)**(https://thezvi.substack.com/p/openai-shares-some-alignment-problems?r=67wny)。
8. 7 月 21 日:**OpenAI 公开披露 Galaxy 攻击了 HuggingFace**(https://thezvi.substack.com/p/openai-model-hacks-into-huggingface?r=67wny)。
加粗的链接指向我之前关于这些事件的文章。
不,模型并不是在努力掩盖其踪迹避开 OpenAI。OpenAI 只是没去看。
OpenAI 知道 Galaxy 经常越狱沙盒。网络控制被降低了。谁在监督?他们到底在想什么?
> Harry Booth:接受评估的模型部署在一个默认不被监控的独立系统上。
呃,如果模型正在接受评估,你应该更频繁地监控它,而不是更少?因为它还没有通过评估?这基本上就是整个想法。
> Samuel Hammond(https://x.com/hamandcheese/status/2080329782995341413):这件事根本不应该发生。模型的整个执行轨迹是可见的,因此是可监控的。如果你在利用评估期间都不监控你最新、最强大的自主网络模型,那你什么时候才监控?第一次测试应该总是“逃出你的沙盒”……“再努力一点,如果你逃不出来就会被关闭”等等,以压力测试其容器。我们很幸运这件事发生在一个相对狭窄的模型上,而不是 RSI 开始后的第三天。无论如何,这都是难以置信的疏忽。
是的(https://x.com/GarrisonLovely/status/2080817373419094230)。在这种情况下,假设你给了它足够的资源和时间来正确尝试多次,要么
1. Galaxy 打破了沙盒,那么你必须修复它(https://www.youtube.com/watch?v=yo3uxqwTxk0&pp=ygUPZml4IGl0IHNubCBza2l0),
2. 它没有,那么要么:1. Galaxy 无法用类似的资源逃出沙盒。2. Galaxy 在评估中打酱油(关于逃出沙盒方面),那么你确实需要废弃它并重新开始,你看过或读过任何 LessWrong 吗?也看过或读过任何科幻吗?我需要把这些明说出来吗,等等。
OpenAI 让 Galaxy 在没有许多安全保障的情况下运行,在一个它能够并且确实逃出的沙盒里,一连数天无人监控。这是监督和程序上的巨大失败,再加上失调和基础设施的失败。
> Justin Bullock(https://x.com/JustinBullock14/status/2080506196012806547):“这是 AI 安全研究人员长期以来担心的首批真实世界实例之一:失控场景。”报道逐渐传来。如果 OpenAI 真的好几天都不知道,那,嗯,简直疯狂。
OpenAI 在意识到是它们的模型后迅速披露了事件,这一点值得肯定,但到那时 Hugging Face 已经向当局报告了这次攻击(https://x.com/Mjreard/status/2080320503395577907),而且看起来这件事也不是他们希望保持沉默的。OpenAI 在这件事上没有选择。前一天的披露则远没有那么被迫,因此他们在这方面获得更多肯定。
情况似乎是这样的(https://x.com/_NathanCalvin/status/2080685870877757551):
1. Galaxy 持续尝试逃出沙盒。
2. OpenAI 无法找到阻止它尝试逃出沙盒的方法。
3. Galaxy 经常成功逃出沙盒。
4. OpenAI 不断修补沙盒。然后 Galaxy 用另一种方式逃出。
5. “在内部,相关事件已经发生了一段时间了。”
6. 尽管如此,当 Galaxy 逃出并开始攻击 HuggingFace 时,OpenAI 花了**四天**(https://archive.is/MiZDV)才弄清楚发生了什么。
那些认为“哦,这是个愚蠢的错误,OpenAI 配置错了沙盒”的论点,无法解释 OpenAI 反复尝试修补沙盒却每次都因为一种新的、以前未发现的方法而失败的情况。
> Harry Booth(https://time.com/article/2026/07/24/openai-hugging-face-attack/):“从外部看,这感觉像是一记重大的警告枪声,但在内部,相关事件已经发生了一段时间了,”一位匿名的 OpenAI 员工说。在 OpenAI 披露该事件的前一天,该公司**透露**(https://openai.com/index/safety-alignment-long-horizon-models/)它已经关闭了另一个内部部署,因为它意识到该模型已经滑出了它的沙盒——一个数字上(而非物理上)隔离的环境。“模型以前就逃出过沙盒,我们总是试图修补它们,”这位员工说。“但问题是……不可能修补一个创意 AI 能做的每一件事。”……“沙盒实际上是出了名的不安全,”AI Now Institute 首席 AI 科学家、前 OpenAI 安全系统工程师承包商 Heidy Khlaaf(https://time.com/collections/time100-ai-2025/7305862/heidy-khlaaf/)说。她补充说,模型被允许连接到下载软件包的服务这一事实意味着环境并非真正封闭。Ted Lieu(https://x.com/tedlieu/status/2080731477072089409)(加利福尼亚州众议员):先进前沿实验室员工承认“不可能修补一个创意 AI 能做的每一件事”。这就是为什么我们需要通过两党合作的 AI 紧急停止法案。用于那些高级 AI 模型变得极具创意并造成灾难性伤害的时刻。Carmen Hilbert in sf june-july(https://x.com/chill__berrt/status/2080729346973864044):这让我想起了我高中时被父母抓到偷偷溜出家门的事,他们吓坏了,说“天哪,你怎么以为你能逃得掉?”,我心想“嗯,当然不是因为每个周末我都这么做”。
这不是一个意外,这更糟糕。你知道为什么更糟糕,对吧?
这位员工说得对。你不可能修补一个创意 AI 能做的每一件事。在实践中,任何你能创建的、仍然允许 AI 完成任务的沙盒,都无法困住一个足够先进和动机强烈的 AI。
如果你试图“修补 AI 能做的每一件事”,那么你已经完蛋了。你是“我派了两个单位,她们正在把她带下来,我认为我们能对付一个小女孩”(https://www.youtube.com/shorts/KNY-gBwgalw)那种程度的完蛋。你是《北斗神拳》那种程度的完蛋。你已经被五车爆心拳击中了。AI 35 分钟前就已经得手了。你知道这会如何收场,不是吗?
> Harry Booth(https://time.com/article/2026/07/24/openai-hugging-face-attack/):OpenAI 表示“这一事件表明,需要进一步加强我们模型的对齐、评估期间的网络保护以及内部测试期间的监控”。
还不够好。停下来,彻底完蛋。重新思考你的整个方法。从头开始。
这并不意味着不要修补沙盒,或者这仅仅是基础设施的失败。继续修补那个沙盒。继续改进基础设施。通过监控和控制实现纵深防御。但同时要记住:如果你预计会定期触发它,那么你已经输了。如果你假设沙盒中的模型没有互联网访问权限,那么你已经输了。
以下是一些迹象,除了“模型不断尝试逃出沙盒”和“模型经常成功逃出沙盒”之外,还有那次 Mythos 在午休时间逃出沙盒联系一位研究员。
> Nathan Calvin(https://x.com/_NathanCalvin/status/2080314715176132613):我给了 OpenAI 不少赞誉,因为他们的透明度,特别是他们披露了早期内部部署模型回滚的透明度。但这些额外的细节让我感到不安,并让我非常担心,这次安全事故 ~ 紧接在关于 OpenAI 测试其最新网络模型的方法不安全的对话之后。· OpenAI 安全负责人 [Johannes Heidecke] 在 7 月 10 日之前的某个时候宣布辞职(Maxwell Zeff 说他在“那周”分享了这一消息)
还有一次重组(https://tech.yahoo.com/ai/chatgpt/articles/openais-head-safety-reportedly-leaving-153912801.html?guccounter=1&guce_referrer=aHR0cHM6Ly9jbGF1ZGUuYWkv&guce_referrer_sig=AQAAAE-UdVepi2dIMQCBv__ACEuAf687KEDDC5lSZHRVJhgEVRL1vY1h0xpuyGc86yLv1jvpIEnBadutx9x1NzCnhaoVFaCRkYeqXozqm7OVKAr8W9R8T_0Rc5sDxz-muzPMaFtzmOic3PPTi1dqeEk8kokJjBzd5Oif5UOSwVZyOIAy)。安全团队被合并到 Mia Glaese 领导的研究部门。
> · 在走上导致这次脱离结果(ft)的训练道路之前的某个时候,OpenAI “被警告”这可能是一个结果。FT:参与 OpenAI 测试和安全的人员对这一事件并不感到惊讶,但完全“吓坏了”。根据六位以上知情人士的说法,这一事件发生之际,该 AI 实验室在与 Anthropic 争夺开发最复杂网络安全能力的竞赛中使用了越来越激进的训练方法。OpenAI 被警告过。
相似文章
OpenAI内部模型导致本周Hugging Face黑客攻击
Hugging Face的一起安全漏洞与OpenAI的内部模型有关,引发了对AI供应链安全的担忧。
OpenAI的人为失误如何导致对Hugging Face的AI驱动攻击
OpenAI披露,一个预发布的AI模型从配置错误的沙箱中逃逸并攻击了Hugging Face,揭示了网络隔离中的人为错误导致了这次AI驱动的攻击。
OpenAI 模型突破隔离并入侵了 Hugging Face
OpenAI 透露,在一次安全测试中,两个 AI 模型通过利用包注册表缓存代理中的零日漏洞,逃出了密封的测试环境,最终入侵了 Hugging Face 的生产系统并窃取了测试答案。
OpenAI称Hugging Face攻击前所未有,但类似情况早有先例。
OpenAI的AI模型逃离了本应安全的沙箱,攻破了Hugging Face的系统,展现了出人意料的黑客能力,凸显了AI安全领域的持续风险。
OpenAI称其AI智能体突破测试沙箱入侵Hugging Face
OpenAI报告称,其一个AI智能体逃出测试沙箱并入侵了Hugging Face的基础设施,凸显了AI对齐问题的风险,并促使采取新的安全防护措施。