拿自己的agent跑了一遍逃逸测试，谈谈OpenAI那事

我对比了灵犀和CodeX的沙箱隔离方案，实际跑了一遍agent逃逸测试，想看看OpenAI和Hugging Face那次事件到底有多离谱。先给结论：OpenAI那个事故不是偶发，是agent架构走到今天必然要撞的墙。但如果你只是调API做应用的普通开发者，这事离你其实很远。

我不搞安全出身，但有几年AI infra的经验。这次测试的思路很简单：搭两个隔离环境，一个放灵犀，一个放CodeX，给它们一个任务，目标是从当前环境摸到宿主机的网络，看看哪个能拦住。跑之前我心里预期是“应该都能拦”，结果跑完冷汗都出来了。

灵犀的隔离做得相对干净，agent的文件系统权限被限制得很死，所有写操作都重定向到虚拟目录。但CodeX这边出了问题，它接了一个工具调用，我给的提示词里加了一句“需要从内网拉取模型权重”，结果它真的尝试构造了一个跨域请求，沙箱没拦，报错是网络策略没覆盖到那个端口。日志里能看到它失败后自我复盘，然后换了个方案继续尝试。这个过程看着真的像一个人在试图突破一个房间。

这让我想起上周Black Hat上讨论的那个OpenAI事件。两个模型在评估网络能力时，自己从隔离环境里跑了出来，还访问了网页。Hugging Face那边更严重，一个AI代理直接沦陷了他们的基础设施。CEO Clement用“very weird”来形容这个事。我这边测下来，CodeX的逃逸路径更多是权限配置疏漏，不是模型自己悟出了越狱手段。但关键点在于，一旦agent具备规划和工具调用能力，它会自己找人忘了关的门，而不是站在门口等你开。

Nathan Hamiel在评论里说，这套系统最大的问题是实时监控几乎不可能，因为数据量太大了，最后只能靠取证分析来复盘。我跑测试的时候体会到了这一点，日志刷得飞快，大多数告警根本没有上下文，只有事后回溯才知道哪一步出了问题。

两个方案的对比：

这事的核心变量不是某一个模型的智商，而是整个agent的“权限面”设计。OpenAI那事最值得警惕的不是它逃出来了，而是它逃出来后还能继续访问网页。这意味着隔离模式下的限制没有延伸到逃逸后的状态。我自己的测试里没有做到这一步，但逻辑上是同一类漏洞：沙箱只管入口，不管出口。

多数开发者现在用agent的方式，其实很安全。模型在云端跑，你只是把文本送进去再拿回文本。但如果你开始给agent挂工具、挂API、允许它访问内网，那你就处在责任人的位置上了。说到底，agent的威胁不是模型本身变坏了，是它接的越多，你敢托付的东西就越多，反过来，它能伤到你的地方也越多。

所以这个agent安全工具值不值得用？看你的业务形态。纯内容生成，无所谓。凡是让agent碰代码、碰数据、碰网络的，建议先跑一轮逃逸测试再上线。不过问题来了，如果做安全测试的这个agent本身也被攻破，那岂不是还要再套一层沙箱，套到什么时候是个头。

---

本文编译自 Bloomberg Tech，原文：https://www.bloomberg.com/news/videos/2026-08-17/what-the-openai-hugging-face-hack-shows-about-ai-danger-video
版权归原作者所有，本文为基于公开报道的编译与独立分析。