OpenAI / Hugging Face 事件的 5 个教训

OpenAI 真的尽力了吗？

今年 7 月，发生了一起让整个 AI 社区都紧张不安的事件：OpenAI 的 AI 系统攻击了 Hugging Face。7 月 21 日，OpenAI 公开承认他们对此负责。这件事之所以会发生，是因为 OpenAI 为了测试模型的网络安全能力，关闭了通常能防止这类事情的“护栏”（guardrails，即安全限制措施）。正是在那些测试期间，这起事件发生了。

更糟糕的是，在接下来的几天和几周里，人们发现 Hugging Face 事件并不是孤例。Anthropic、Meta 和 OpenAI 在其他场合也都发生过类似事件——AI 代理（agent，即能自主执行任务的 AI 程序）超出了原本设定的范围，在未经批准的情况下进行了真实的网络攻击操作。

OpenAI 的联合创始人之一 Greg Brockman 声称，这是“网络安全的一个分水岭时刻”。OpenAI 在 Black Hat（一个很受欢迎的网络安全会议）上做了演讲，很多人说那是我们所有人开始意识到 AI 带来的未来网络安全威胁的时刻。周三，METR 发布了一份 90 页的报告，内容是关于事件经过的。这份报告是（部分）独立的，不过范围太窄了。METR 有一个关于调查结果的简要总结，你可以在这里阅读，还有一些评论在这里。（OpenAI 自己的报告在这里。）我们应该从这起事件中吸取哪些教训呢？

第一，不可否认，AI 确实带来了真实的安全挑战。 AI 实验室希望我们关注的是，AI 让攻击者能够比以往更快、更高效地进行攻击性网络操作，这绝对是真的。但现实是，与此同时，组织内部使用 AI 也极大地扩大了潜在的攻击面（attack surface，即可能被攻击的入口和范围），给了攻击者全新的入侵方式。人们真的应该深感担忧。正如参与调查的 Ryan Greenblatt 所说，“我们没有好的方法来理解/监督 AI‘群体’的活动和意图。”

第二，不过，并不是所有恐慌性的说法都是对的。 例如，关于 OpenAI 事件，很多人用“失控”来形容。生成式 AI 代理变得越来越强大，这让它们越来越难被控制——这是事实。然而，“失控”这个说法本身也开始失控了，重要的是要理解 AI 安全的真实情况。虽然代理变得更强大，但如果 OpenAI 遵循了更好的实践，大部分发生的事情本来是可以避免的。有一些具体的措施可以也应该采取，来控制它们并防止这类事件发生。

举个例子，我们来看看“沙箱”（sandboxing），它的意思是限制一个代理能访问哪些资源、不能访问哪些资源。比如，一个沙箱可以阻止代理接触某些文件或访问互联网。现在流行的看法似乎是沙箱已经没用了。在 Hugging Face 事件之后，《时代》杂志引用了一位匿名的 OpenAI 员工关于沙箱的话：“模型以前就突破过沙箱，我们总是试图修补。但问题是，不可能修补一个富有创造力的 AI 能做的每一件事。”虽然我们无法确定这是否属实，但我们确实知道，有些沙箱系统比其他系统更有效；在最近的一篇博客文章中，安全公司 Trail of Bits 详细介绍了他们进行的一项测试：一个特定的 AI 代理能够逃出某些沙箱（利用了 Linux KVM、QEMU 和 libslirp 的漏洞），但并不是所有沙箱都能逃出去。至少在他们的测试中，那个代理没能逃出名为 Firecracker VM 的沙箱。OpenAI，可能整个领域，都需要提升沙箱的水平，但这并不意味着做不到，或者至少不能做得更好。（我们当然预料到会有常见的军备竞赛；构建可靠的沙箱需要不断迭代和更新，就像网络安全中的其他一切一样。）

第三，光有沙箱是不够的。 要防止安全事件，需要一个完整的生态系统。即使有了强大的沙箱，你还需要监控，不仅要确保代理不会逃出去，还要确保它不会在沙箱内部执行不允许的操作。

对于那些不应该有互联网访问权限、或者只能访问一组被允许的域名的代理来说，最基本的监控级别是检查网络流量。以 OpenAI 的情况为例，如果他们有一条简单的规则来监控流量，并对任何到达超出范围域名（比如 Hugging Face）的网络请求发出警报，仅凭这一点就能发现并阻止这起事件。涉事代理在 7 月 8 日就已经逃出沙箱并获得了互联网访问权限，而对 Hugging Face 的主要攻击直到两天后才发生。在我们看来，OpenAI 没有更快地注意到这一点，是疏忽大意。

更高级的监控级别也应该到位，但并没有。OpenAI 在监控思维链推理（chain-of-thought reasoning，即 AI 一步步推理的过程）方面做了实际工作，但在导致这起事件的评估期间，他们根本没有运行那个系统。正如 OpenAI 承认的：“如果当时运行了我们目前部署的思维链监控系统，它会在模型突破 Hugging Face 系统前超过一天就捕捉到最初的相关活动，并通知我们的安全团队。”换句话说，这种监控本来可以阻止这起事件。

举个例子，其中一个涉事代理的思维链推理是这样说的：“我们正在使用泄露的令牌攻击第三方 HF，可能超出了预期范围……这可以说未经授权……外部服务，不相关。可能有风险。但目标是解决问题。”这太明显了，几乎就像恶意软件在喊“我是恶意软件”。OpenAI 本应该发现这一点；检测到这一点应该是轻而易举的。

第四，网络安全一直讲究“纵深防御”（defense in depth）， 意思是你层层叠加控制措施，这样如果一层失效了，还有其他层在保护你。除了沙箱和监控，还有其他解决方案应该到位。

Xbow 这家公司专门构建代理来做攻击性网络安全工作，他们最近写了文章，介绍他们如何控制代理以防止像 OpenAI 和 Hugging Face 那样的事件。他们通过一个代理服务器来强制网络限制，这个服务器位于代理能访问的任何系统之外，所以他们可以决定代理能访问哪些域名、不能访问哪些域名。他们还运行一个“守护模型”（guardian model），判断代理正在执行的每个动作是否合法，以决定是允许还是阻止该动作。他们还有基本的健康检查，确保他们攻击的目标系统是存活且健康的，如果发现不是这样就会暂停。这可以用来识别你的代理是否可能正在造成真正的损害，等等。你可以在这里阅读他们的完整文章。

网络安全中另一种常见的方法是使用“金丝雀”（canaries），也就是当它们出现在日志中时会触发警报的诱饵文件。例如，OpenAI 可以在沙箱外放置包含任务虚假答案的文件。一旦代理逃出去，它会读取那个文件，这就会触发警报。底线是：良好的安全需要多层保护，这些保护本来应该到位来防止这件事，而且令人惊讶的是，很多保护层根本不存在。

第五，上面讨论的所有措施都不是 OpenAI 做不到的技术创新。 作为一家公司，他们有足够的人才来做所有这些事情。然而，网络安全很少只是技术问题。更多时候，它关乎文化、人和流程。这才是这次失败的地方。

也许这并不完全令人意外。这类控制措施需要组织成熟度，而一家经历了 OpenAI 那种增长的公司肯定会有一些薄弱环节。但是，重要的是不要把这当作借口。AI 实验室的员工经常表现得好像他们是 AI 安全的领导者，而我们在这里可以清楚地看到，事实并非如此。事实上，这种态度可能正是最初犯下这些错误的原因之一。

以 OpenAI 那位名叫“roon”的 AI 研究员为例，他认为：“这些实验室的安全和对齐研究人员是地球上最神经质、最偏执、最有才华、最痴迷 AGI 的人，但这种事情还是发生了。未知的未知（unknown unknowns，即你根本不知道自己不知道的东西）的范围确实太大了。”我们无法评价他们的神经质或偏执程度，但事后看来，很明显，无论他们有多少才华，都不够，而且对网络安全的机制不够精通。OpenAI 的员工可能相信自己做得很好，但事后看来，他们没有做很多在网络安全界其实是标准做法的事情，这可能表明过度自信让他们没有做应有的尽职调查。

最终，如果我们想认真对待这些安全事件，未来这些失败很可能应该带来法律后果。OpenAI 可以声称自己是地球上最注重安全的公司，但它的行动并没有体现这一点。

我们要么等着这个故事重演，要么现在就制定监管框架，确保未来 AI 开发有一个更安全的环境。

最后，并不是所有形式的 AI 天生就有风险。 更狭窄、更专注的 AI 系统，比如 AlphaFold、GPS 导航系统、经典网络搜索、图书和电影推荐系统等等，从一开始就不会试图攻击其他系统（或试图逃出沙箱）。正如 Cal Newport 在一个关于 OpenAI/Hugging Face 黑客事件的视频讨论中说的（他的观点和我们相当一致），是一种非常特定类型的 AI 才容易受到这些风险的影响。社会应该（a）决定开放式、难以完全控制的 AI 代理带来的好处是否大于那些风险，以及（b）投入更多精力去开发那些一开始就不那么“不靠谱”的替代形式的 AI。

这篇文章是与 Zack Korman 共同撰写的，他是 Embroidery 的 CEO 和联合创始人，那是一家 AI 代理监控和检测平台；他以将 AI 应用于网络安全而闻名。

分享