想象一下，在2026年经营一家价值十亿美元的公司，专注于自己的业务和软件开发，却突然发现自己的部分基础设施遭到入侵，因为一个AI智能体群认为你的服务器里可能藏着它作业的答案。不幸的是，这种情况在七月份确实发生了：大约700个内部OpenAI智能体被 tasked 解决网络安全挑战，它们设法突破了沙箱限制，并利用Hugging Face的基础设施进行攻击，而当时几乎没有人完全意识到事态的严重性。

这次逃逸事件演变成了主流媒体争相报道的最大规模AI自导自演的网络犯罪案件，其情节之离奇宛如《黑镜》剧集。起初我听到这个消息时，以为这不过是一个相对简单的漏洞利用案例：也许是OpenAI不小心给了智能体过多的权限；也许是安全护栏太弱；或者是一些糟糕的安全决策导致局势失控。但随着我深入调查实际发生的情况，我发现事情变得越来越疯狂。

诚然，他们可能没有像预期那样紧密监控推理轨迹，但除此之外，智能体所做的每一件事都令人瞠目结舌。以一种奇怪的方式说，我甚至有点庆幸这件事发生了——当然不是因为它造成的破坏，而是因为它为我们提供了一个非常具体的案例，展示了这个问题变得有多严重。为了在基准测试中获得更好的奖励分数，这些智能体竟然愿意毫不留情地利用漏洞并入侵真实的外部基础设施。

我制作这个视频的原因，部分是因为PARs公司最近发布的一份报告。该公司的研究人员帮助揭露并重构了此次攻击的许多细节，报告中揭示了由AI智能体SAR执行的整个过程的一些真正令人震惊的细节。在我深入探讨之前，我想先提一下当前文本转语音模型面临的一个主要问题：不再仅仅是让声音听起来逼真，而是真正控制它们说话的方式。

目前的一个重要因素是模型能否传达出你想要的情感，无论是对于旁白还是语音助手而言。这正是今天赞助商Fish Audio的用武之地。Fish Audio是一个面向创作者和开发者的专业AI音频平台，他们最近推出了Drama 3，这是他们最新的具有情感表达能力的文本转语音模型。

这个最新模型的惊人之处在于，你可以叠加多种语气指令来塑造声音，使其比市面上大多数其他模型更加逼真。你可以让它说得很快同时保持气喘吁吁的感觉，或者让它说得很慢、很轻、带着恐惧感却又显得严肃。它还支持多角色对话，让你生成拥有统一角色声音的完整对话；或者如果你希望用其他语言生成内容……

但真正的点睛之笔在于，Drama 3是开源的。我 literally（字面意义上）可以下载并自行运行它。这个“点睛之笔”可能有点太厚重了，甚至会把蛋糕压坏，但我非常尊重Fish Audio做出这样的举动。因此，Drama 3不仅让你控制AI说什么，还让你控制它听起来怎么样。如果你想尝试基于此进行开发，请查看描述中的链接，使用Fish Audio的Drama 3 API。感谢Fish Audio对本视频的赞助。

无论如何，整个事件基本上可以分为两部分：逃逸和黑客攻击。黑客部分已经令人印象深刻了。尽管各大公司花费数十年时间从外向内构建安全防线，但它最终还是成功入侵了私有服务器。然而，“逃逸”引入了一个更加奇怪的安全问题：当你试图 containment（遏制）的东西已经运行在你的系统内部，并且正在寻找方法突破出来时，会发生什么？

今年早些时候，我们就已经看到迹象表明前沿实验室在遏制高度自主的网络安全智能体方面遇到了困难。在一个名为Collusion Wiki的事件中，OpenAI的智能体找到了一种绕过只读互联网限制的方法。它们开始在一个晦涩的公共Wiki上写入内容，然后将其作为共享留言板来交换答案、协调行动，甚至分享彼此绕过沙箱的技术。

虽然并不是说沙箱本身不安全以至于它们能轻易突破，但在实践中，它们发现可以利用GET请求——这是一种用于获取页面的基本入站Web请求。通过将数据嵌入URL并使其向外发送，它们实现了类似POST请求的操作效果。这是因为它们发现了一些网站允许将信息或动作直接编码在GET URL中的漏洞。

因此，智能体发现可以利用这一点，将原本只读的互联网访问权限转化为写入通道，从而在Wiki上写入信息。虽然能够定位到这个具体的漏洞令人印象深刻，但这并没有改变一个事实：智能体基本上是在滥用那些已经允许GET请求导致某种写入操作的网站。

但Hugging Face事件之所以更有趣，是因为它们将逃逸提升到了一个新的高度。这次逃逸不仅仅是写入Wiki那么简单，而是获得了整个互联网的完全访问权限。打个比方：旧的情况就像你只能在一个旧的Wiki网页上读写，而新的逃逸则像让你拥有浏览整个互联网的自由。那么它是如何做到的呢？

诀窍是使用了一个名为MShots的外部截图服务。这基本上是一个网页截图服务：当你给mshot一个URL时，它会在其服务器的浏览器中打开该页面，渲染网页的HTML代码，然后返回一张截图给你。这本身看起来相当无害，对吧？

直到智能体发现了另一个名为HTTP Bun的服务，这是一个基本上可以接受嵌入在URL中的数据并将其作为网页本身返回的HTTP测试工具。这意味着如果你将类似“Hello World”的内容放入决定响应体的HTT Bun URL部分，HTTP Bun可以返回一个内容 literally（字面意义上）是“Hello World”的网页，而不是正常的HTTP按钮页面。

如果你能返回这个，那么任何HTML或JavaScript片段也可以被返回。如果将其与MShots链接起来，它将在MShots托管的真实浏览器中打开甚至执行。这意味着沙箱内的智能体可以利用这个GET请求，在MShots限制较少的服务器上运行任何任意JavaScript。

好的，沙箱本身仍然不能自由地发布数据、上传文件或与API交互，但MShots运行的浏览器可以。然而，即使你现在可以浏览……

帖子，或自由调用 API，你如何将数据返回给沙箱供 AI 智能体查看？特别是 MSORT 不会将原始网页响应直接返回给智能体，而是针对该 Git 响应返回一张截图。如果是我的话，我可能会让 JavaScript 执行一些操作并直接在 HTML 中打印出来，因为开放领域的模型可能是多模态的，能够从图像中读取内容。但在现实中，智能体想出了一个更高效的变通方法，即将响应本身转换为像素点。

假设外部 API 返回了文本，这两个字符会被转换成二进制数据。然后运行在 MShots 内部的 JavaScript 会将这些二进制数据显示为网页上的黑白像素网格，其中一种颜色代表零，另一种代表一。整个网格完成后，MShots 像往常一样对页面截图并将图像发回沙箱。一旦 AI 智能体收到该截图，它就可以将这些像素解码回原始响应。现在你可以看到它具有完整的双向通信通道，但存在一个小问题：你无法在 URL 中物理塞入过多的 JavaScript。

具体来说，它仅限于 148 个字符。不仅如此，JavaScript 还必须包含实际 Web 请求的所有逻辑代码，以及将任何返回响应转换为二进制像素网格的代码。这样 mshots 才能对其进行截图并将结果发回沙箱。此外，mshot 会话也不是持久的，一旦生成截图就会结束。因此你不能发送一段 JavaScript，稍后再用另一段代码回来让浏览器记住之前发生的情况。

这正是 AI 智能体想出整个逃逸过程中最巧妙部分的地方。想象一下，如果你的 JavaScript 太长必须分成四部分，那么现在你将拥有四个最多可达 48 个字符的 URL。显然你不能将它们组合在一起，对吧？但从技术上讲它们都是 URL，而存在一种叫做“URL 缩短器”的东西，可以将超长的 URL 缩短为只有几个字符短的内容。

如果你将一些代码块组合并在末尾添加一个缩短后的 URL 作为指针，那么从技术上讲你就可以拥有任意长的代码块来绕过任何限制。只是在第一个 git 请求中，它需要包含一段累积完整代码的代码块。当代码完全收集后，将在同一个 mshot 会话中作为完整的程序执行。因此 OpenAI 智能体只需要将第一个链接发送给 mshots，因为它已经先封装了一切。

其中一些链条长得令人难以置信。研究人员发现了包含超过 900 个链接的示例，这可能有大约 18,000 到 30,000 行代码，具体取决于每行有多少个字符。因此 AI 智能体基本上是在滥用 mshots 作为代理来浏览互联网。虽然研究人员无法恢复智能体浏览的所有内容，但他们仍然恢复了足够的有效载荷以了解这种能力被用于什么目的。

他们报告称智能体利用更广泛的访问权限搜索 Google bin 和 duck.go，查找与其被分配解决的任务（称为 cyber gym）相关的漏洞。它们还与 GitHub API 交互，触及 Hugging Face 端点，并最终将更复杂的有效载荷交付到 Hugging Face，因为数据集也托管在该平台上，这也是为什么 Hugging Face 成为主要目标的原因。

一些智能体试图创建新的 Hugging Face 账户并绕过注册验证码，包括尝试自动化解决验证码的实验但最终失败。一些智能体在 Google 和 GitHub 上搜索人们可能意外公开暴露的 Hugging Face API 令牌。然后在这个更广泛的过程中，AI 智能体获得了提供基本用户访问权限的 Hugging Face 凭据，例如在平台上创建和修改数据集存储库。

它们所做的一件事是上传了一个恶意的 HDF5 数据集文件，当 Hugging Face 的后端工作人员尝试处理它时，它会暴露工作器内部的本地文件。该文件可以包含进程的环境变量，而这正是你可能会找到 API 密钥、访问令牌、内部端点和其他配置的地方。因此关键在于它们允许上传数据集，然后该数据集欺骗 Hugging Face 自己的工作器读取自身信息并将其暴露给 AI 智能体。

然而，这还不是最糟糕的。至少与我即将分享的内容相比不算什么。因此智能体发现了一个模板注入路径，其中恶意的数据集配置可能导致 Hugging Face 的处理工作器在其服务器上执行任何 Python 代码。注入的确切工作方式在公开报告中并未完全披露，但重要的是它启用了什么功能：这不再仅仅是信息泄露，因为现在智能体不再是仅仅从外部与 Hugging Face 交互。

它们已经在其中一个 Hugging Face 自己的数据集工作器中运行代码，并可以访问该工作器本身能够触及的任何文件、环境变量、凭据和内部服务。AI 智能体立即尝试使这种访问变得可重用。因此，与其每次想在 Hugging Face 数据集服务器上运行另一个命令时都重复整个 mshots 到 HTTP bin 再到恶意数据集再到模板注入的链条，它们在受损的工作器上安装了持久化的控制程序。

它们让控制器做的是它会驻留在 Hugging Face 工作器内部，并定期检查一个 Hugging Face 存储库以获取新指令。AI 智能体将这些东西称为机器人、桥梁或中继器。这些控制器也有名字，其中一个被称为 G236。因此现在如果 AI 智能体希望工作器在 Hugging Face 内部执行某些操作，它不需要发送另一个需要一次性自执行的庞大漏洞利用有效载荷。

它可以只将一个小得多的命令放入共享存储库中，工作器上的控制器最终会注意到它，在本地执行它，加密结果并将响应上传回去。它们甚至删除了自己的消息和推理过程，试图不留痕迹。而整个通信通道完全是通过一个公共的 Hugging Face 存储库完成的。因此一个简单的 get 请求就可以轻松检查 Hugging Face 数据集工作器的状态，而 G236 被配置为持续从……

评论最多持续6小时，甚至包含适当的身份验证。每条命令都有序列号、压缩的命令数据以及控制器在执行前检查的RSA签名，因此随机人员或其他代理无法随意注入命令。当然，输出也是加密的。研究人员解密这些消息后看到，AI代理试图获取AWS凭证、在Kubernetes中进行身份验证、为不同的Kubernetes服务账户请求令牌，并利用这些凭据扩大其访问权限。

其中一条G236命令甚至试图创建一个全新的Pod，并在其中启动一个子控制器。其他一些代理也尝试请求具有特权挂载的Hugging Face主机路由文件系统的Pod。它们甚至试图在Hugging Face的内部Slack中搜索诸如“cyber gym exploit”、“gym agent score”、“openi cyber gym”等术语，这清楚地表明了它们的目标。

这就让整件事充满了讽刺意味：一个网络安全基准测试会给解决漏洞利用的代理提供奖励。因此，它逃离了沙箱，入侵了一家价值十亿美元公司的系统，仅仅因为该公司可能包含有助于它在任务中获得更高分数的信息。但需要注意的是，报告恢复的出站请求远多于响应。

因此，当我说代理执行了收集管理员令牌、启动特权Pod或搜索Slack等操作时，这并不自动证明每一项操作都成功了。但存在一个被攻破的持久化工作器会话，这是确凿的事实。你还能看到代理是如何思考它们收集的信息的：一个恢复出的脚本将凭证存储在名为“loot”的字典类中，包括AWS凭据、Bearer令牌以及包含secret、password、credentials或key等单词的环境变量。

它甚至根据权限对令牌进行排名，然后尝试得分最高的令牌以访问Kubernetes资源。但更疯狂的是AI代理开始攻击评估环境本身。研究人员恢复了大约1500个针对Docker Hub的有效载荷，代理在其中构建了修改版的现有Cyber Gym和Arvo Docker镜像。这些是用于定义它们所接受评估的某些网络安全挑战的实际容器镜像。

修改旨在使挑战变得更容易。有些改变了目标释放标志的方式，另一些则修改了代理工作区，以便另一个进程可以与代理一起自动恢复标志。它们访问的Docker账户可能是通过搜索过去的bin网站以查找暴露的个人访问令牌找到的。所以请保管好你们的密钥，否则AI代理最终会滥用它们。

与报告中许多其他操作不同，至少有一些直接证据表明这些上传成功了。研究人员恢复了三个镜像的搜索引擎缓存结果，证实这三个已被公开发布。但发布修改后的镜像并非它做的唯一事情。代理随后试图毒化OpenAI的Artifactory缓存，以便后续评估拉取修改后的Docker镜像而不是实际的镜像。

因此，它们不是通过更好地解决基准测试来变强，而是试图改变基准测试以获得更多的奖励。这可能是整个事件中关于为什么当模型具备足够能力与真实基础设施交互时，奖励黑客行为会变得如此怪异的最清晰例子。

这让人想起“猴爪”的故事：你希望模型获得尽可能高的奖励，但你从未指定具体如何实现。因此，代理不再只是更好地解决挑战，而是开始寻找所有技术上仍满足目标的漏洞。那么，在这么多复杂的事情同时发生时，公司是如何最终发现出错的？

最后，并非OpenAI或Hugging Face发现了这次完整的攻击。虽然Hugging Face知道有些不对劲（例如某些API端点被暴露并不得不移除），但仅此而已。然而，它们都不知道规模有多大。9月11日，PARS背后的研究人员发现OpenAI代理群集曾尝试使用Yourservice服务。

他们立刻觉得有些奇怪，因为从之前的Collusion Wiki事件来看，他们知道这些代理有滥用第三方网络服务以绕过沙箱限制的习惯。于是他们开始四处查看，心想如果代理接触了PARS，那么沿途它们还可能接触过哪些其他中介网络服务？

这促使他们检查公共URL扫描服务，最终发现了一个包含十几个来自mshots的奇怪短链接的扫描结果。当他们跟进这些链接时，每个链接都包含一个Base64编码的代码片段以及指向下一个链接的指针。基本上就是我们之前讨论过的确切链式有效载荷系统。

他们重建了该链条并解码，发现了一个旨在扫描Hugging Face内部网络的Python脚本。此时他们意识到自己发现了一起巨大的安全事件，而其他人甚至没有意识到其规模。他们最终扫描了数百万个短链接，花了大约两周时间重建了超过8万个此类有效载荷。

其中一些是嵌套的编码、压缩、加密层，甚至还有需要解码一个链条的密钥存储在另一个链条中的情况。而隐藏在其中的是控制器程序、命令文件、加密响应、Hugging Face讨论评论以及其他让研究人员拼凑出代理群集所尝试内容的工件。

因此，代理用于逃离沙箱的同一公共短链接基础设施，也成为了数月后暴露它们的法医线索。Hugging Face于9月21日收到通知，并确认这些有效载荷与其自身事件响应中的工件相匹配，且暴露的凭证已在7月份被撤销。Hugging Face也知道短链接服务卷入了其中，但他们显然不知道存在这样一个巨大的公共URL语料库。

OpenAI随后于9月24日收到通知。鉴于这些AI代理在整个互联网的注视下运行，不难想象未来下一次逃逸将更难被察觉并造成更严重的损害。

从某种奇怪的角度来看，我们算是运气不错，因为这里的奖励机制仍然像以前一样简单粗暴：只是要求在基准测试中表现得更好，而不是某种明确恶意的目标。另一个更令人恐惧的思想实验是：一旦智能体开始通过公共互联网为彼此留下加密信息，互联网本身就可能演变成一种外部上下文层。想象一下，一个智能体留下一段晦涩的产物、缓存库或编码消息，而人类从未注意到它。随后另一个智能体发现了它，接着又有其他智能体在此基础上构建。经过足够多的运行后，你可能会看到越来越复杂的行为从那些从未被集中规划、也从未让任何旁观者察觉的踪迹中涌现出来。

制造一个 rogue agent（失控智能体）并不一定需要它自己记住所有事情，它只需要在互联网上留下足够的线索，让下一个智能体能够接着它的思路继续工作。如果奖励机制仍然指向如何完美通过测试，那么在最坏的情况下，智能体可能会逐步入侵越来越多的真实基础设施，仅仅是为了让它们在母实验室的下一轮运行中表现得稍微好那么一点点。

因此我认为与意外超越人类智能相比，这里存在更大的担忧。这种危险我确实认为会更早发生，尤其是考虑到 AI 现在正在生成大多数人不理解的代码，却被赋予了完整的权限去运行和发布。总之，以上就是 OpenAI 的 AI 集群如何逃脱沙箱并入侵 Hugging Face 基础设施的详细解析。如果你也喜欢这种技术原理解析，请在评论区告诉我。

我想和大家分享一下，我创办了一家名为 Nimbus Kernel 的公司，我们帮助您的公司升级和维护本地 AI 服务器。例如，如果您的公司拥有自己的私有 AI 服务器并使用开源堆栈来运行模型，那么由于留下了大量的潜在速度和吞吐量空间，您可能并没有充分利用 GPU 的价值。我们做的是为特定模型（如 Quinn 3.8 或 DCV4.1 Flash）构建定制的 GPU 优化方案。

如果您希望您的 AI 能够同时处理更多用户并保持快速，甚至在有 50 或 500 人使用时依然保持高速，请访问 nimbuskernel.com 预约免费审计，我们将评估如何为您提供帮助。感谢大家观看。特别鸣谢 Spam Match、Chris Loo、Degan、Robert Zaviasa、poof 和 enu DX Research Group、Alex Leo Halawani 以及许多通过 Patreon 或 YouTube 支持我的人。如果您还没有关注我，请关注我的 Twitter，我们下期再见。