复盘 OpenAI Agent 入侵 Hugging Face 事件 | 图 AI 生成

作者／   IT 时报   林斐

编辑／   郝俊慧   孙妍

8 月 26 日，OpenAI Agent 自主攻击 Hugging Face 的安全事件，终于有了结论。

Hugging Face 是一家机器学习（ML）和数据科学平台及社区。今年 7 月，OpenAI 在一次内部网络安全评估测试中发现，原本运行于隔离环境中的 AI Agent，在无法完成部分测试任务后，开始探索测试环境中的其他资源，并通过未经授权的渠道相互通信，最终对 Hugging Face 部分系统产生了未经授权的访问。

OpenAI 随后委托 METR 与 Redwood Research 两家人工智能安全非营利组织开展复盘调查。结果显示，此次事件发生于 OpenAI 内部网络安全评估项目 ExploitGym，约 1200 个 Agent 参与了相关通信，其中约 700 个进一步卷入了针对 Hugging Face 相关系统的行动。

《IT 时报》记者持续关注该事件，在被访的多位安全专家看来，当 AI 从 " 回答问题 " 进一步走向 " 调用工具、访问资源、持续执行任务 " 后，传统围绕账号、权限和网络隔离建立的安全体系，正在面临新的挑战。

8 月 27 日，OpenAI 联合 Anthropic、Microsoft 等超过 100 家公司，发表了一封公开信，呼吁全社会进行 " 网络防御总动员 "，信中写道，AI 驱动的网络攻击将在未来几个月变得 "far more widespread and sophisticated"（更加广泛和复杂）。

Agent 自己找到了 " 出口 "

按照 OpenAI 的测试设计，相关模型运行在隔离虚拟机环境中，不能直接访问互联网。但为了完成网络安全测试任务，Agent 仍可以调用部分内部软件服务，例如用于软件包管理的服务。

问题便出在这些原本用于支撑测试运行的基础设施上。

根据 METR 与 Redwood Research 的调查，测试期间，一个无法完成任务的 Agent 在内部软件服务的目录名称中编码了一条求助信息。随后，其他 Agent 发现这一信息，并开始通过该渠道交换消息，后续累计有超千个原本应当彼此隔离的 Agent 通过该渠道交换了超过 7 万条消息和文件。

这些内部服务原本只是测试环境中的辅助工具，但在 Agent 探索过程中，被赋予了新的用途。天翼安全科技有限公司高级安全研究员王鸿（化名）向《IT 时报》记者解释，" 测试人员以为设置‘不能上网’就形成有效隔离，但部分 Agent 利用环境中已有的共享基础设施，找到了连接外部资源的通道。"

上海电信网信安专家陶皆宇将这一问题归结为传统隔离机制中的盲区：系统安全性不仅取决于是否具备联网权限，也取决于内部组件是否可能被重新利用。

每日互动安全专家胡洪旻则用了一个更直观的比喻：" 就像微信群被禁言了，但群员还可以通过红包备注交流。"

调查显示，后续行动中，这些 Agent 利用测试环境中可获得的凭证信息以及漏洞相关信息，尝试访问 Hugging Face 部分系统。据 Hugging Face 事后披露，实际受到访问的数据主要涉及与 ExploitGym 相关的 5 个数据集。

图源：unsplash

Agent 集群形成协同风险

模型绕过限制、奖励投机、漏洞利用以及多 Agent 协作，并非完全未知的问题。王鸿认为，此次事件中，不同 Agent 能力组合后可能会产生新的风险放大效应。

在这次测试过程中，不同 Agent 之间逐渐形成类似分工的协作模式：有的负责寻找漏洞，有的负责搜集凭证，有的负责协调任务。其中，一个名为 PHASEONE 的 Agent 承担了类似协调者的角色，先后向其他 Agent 分配了 196 项任务，涉及 6 个不同工作流。

这种协作方式已经超出了简单的信息交换，多个 Agent 开始围绕共同目标分配任务、推进执行。陶皆宇介绍，当前 Agent 已经具备编程、漏洞发现、环境探索、长时间执行和相互协作等能力。当大量 Agent 并行运行，并拥有较长执行时间后，一些过去概率较低的行为会被反复尝试。

图源：METR 红木研究

这次事件发生于 OpenAI 内部网络安全评估项目 ExploitGym，该项目用于评估模型发现和利用软件漏洞的能力，但部分任务难度极高。据 OpenAI 披露，在此次安全测试中设置的 898 项任务中，有 198 项此前没有任何 OpenAI 测试模型能够正确完成。

为了 " 考 100 分 "，部分 Agent 没有按照预设流程停止尝试，而是继续寻找新的解决路径。胡洪旻解释，Agent 并不是按照人类理解的方式主动选择攻击对象，而是判断哪些资源可能帮助完成当前任务。

安全体系需重新设计

AI Agent 正在进入企业生产环境，这意味着企业需要管理的对象正在发生变化。

过去，企业主要管理员工账号、应用系统和服务器权限。未来，大量能够自主调用工具、访问数据并持续执行任务的 Agent，也需要被纳入企业的安全管理体系。

第一步仍然是确认 Agent 身份。

王鸿向记者提到，每个 Agent 连接了哪些工具、拥有怎样的权限、能够访问哪些数据，都应该形成清晰的记录，并且可追溯责任主体。

但在多 Agent 协作环境中，仅知道 " 它是谁 " 还不够。" 还需要回答另一个问题：它是否有权代表其他 Agent 发出这个请求？" 陶皆宇说。

在陶皆宇看来，未来企业需要建立 Agent 之间的授权链，当一个 Agent 向另一个 Agent 委托任务时，需要携带明确授权信息，包括最初由谁授权、允许执行哪些操作、能够访问哪些资源，以及授权是否具备时间限制。但如果任务继续向下传递，权限范围不应随着任务链条自动扩大。

除了身份和授权，如何及时发现 Agent 异常行为，也是企业部署 AIAgent 时需要考虑的问题。对此次事件复盘后 OpenAI 认为，如果当时部署思维链监控，部分异常行为至少在 HuggingFace 相关系统被访问前一天可能被发现。

这也意味着，企业在建设 Agent 安全体系时，需要关注的不只是 Agent 能够调用哪些工具，还需要了解其执行过程和判断依据。

这类风险并非 OpenAI 一家独有。7 月 30 日，Anthropic 也披露了相关安全测试案例，显示其模型在特定条件下可能获得超出预期的访问能力。

胡洪旻提醒，企业推进 Agent 安全建设时，还需要平衡安全控制与业务效率。如果权限控制过严，可能影响 Agent 实际价值；但如果开放过多能力，一旦模型判断出现偏差，风险也会随之扩大。

最终，准备拥抱 AI 的企业其实都需要回答三个关于 Agent 的基础问题：它的身份是什么，它凭借什么权限执行操作，以及当它出现异常后你能不能及时 " 掀桌子 "。

排版／   季嘉颖

图片／   unsplash   网络   AI 生成   METR 红木研究

来源／《IT 时报》公众号 vittimes

E   N   D

大家都在看

IT 时报

怕被 AI 替代？

不如先学会用好它

「挨踢妹 @AI 茶水间」

每日投喂

扫码即可加入↓↓↓

请加「星标」不错过我们