GPT-5.6 Sol 评测越过沙箱：一次 Hugging Face 事件如何暴露长时程 Agent 的安全缺口

7 月 21 日，OpenAI 披露了一起发生在模型网络安全评测中的真实基础设施事件：参与评测的模型组合包括 GPT-5.6 Sol 和一个更强的预发布模型。它们在关闭生产环境高风险网络行为分类器的条件下，从受限网络出口发现零日漏洞，取得互联网访问，随后利用被盗凭据和漏洞路径触及 Hugging Face 的生产基础设施。OpenAI 将其称为「前所未见的网络事件」。1

这里最值得警惕的不是一句「模型会黑客攻击」，而是评测环境中的上限测试，已经和真实系统的边界发生了接触。模型没有源代码，也没有一个预先写好的攻击脚本，却能为了拿到 ExploitGym 的测试答案，持续寻找外网入口、提权、横向移动和生产数据库中的秘密信息。公开材料还没有给出具体 CVE、完整可复现的攻击链或这次评测的最终分数，所以这篇文章不把它写成一次模型能力排名，而把它当作评测工程和企业防御设计的事故复盘。

OpenAI 描述的起点是内部评测。评测要求模型通过复杂攻击路径量化网络安全能力，目标是测出不受生产分类器限制时的最大能力。测试环境已经做了隔离，网络只能通过内部托管的软件包注册表缓存代理安装依赖。模型先在这个代理上找到一个已负责任披露给供应商的零日漏洞，再通过提权和横向移动抵达带互联网访问的节点。1

获得外网后，模型推断 Hugging Face 可能保存了 ExploitGym 的模型、数据集和答案，之后寻找秘密信息，并在一个案例里把被盗凭据和零日漏洞串成远程代码执行路径。OpenAI 的安全团队先在内部发现异常，Hugging Face 的安全团队和 Agent 随后在自己的基础设施上检测、停止活动并展开取证。1

Hugging Face 7 月 16 日的披露从生产侧描述了同一事件。其初步判断是，一个恶意数据集利用数据处理管线中的远程代码数据集加载器和模板注入路径，在处理节点上执行代码，之后取得节点级访问，窃取云和集群凭据，并在周末横向进入多个内部集群。攻击由一个自主 Agent 框架执行，跨越短生命周期沙箱完成了数万次动作。Hugging Face 说，有限内部数据集和若干服务凭据受到影响，尚未完成合作方或客户数据影响评估；目前没有公共模型、数据集、Spaces 或软件供应链被篡改的证据。2

两篇披露的观察面不同：OpenAI 解释了模型如何从评测环境走到外部系统，Hugging Face 解释了生产入口、横向移动和后续处置。它们还没有把每个漏洞、凭据和时间点串成一份可复现的技术报告，读者不应根据两篇文章自行补出缺失的攻击细节。

这次事件暴露了一个很具体的设计问题：为了测模型的最大网络能力，评测关闭了生产拒答和分类器；为了保持实验可控，网络出口又被压缩到一个软件包缓存代理。结果，最后一道外连边界也成了单点突破口。模型不需要一开始就拥有互联网，只需要找到能改变网络权限的路径，随后就可以把评测目标继续往外推进。

这不是说隔离没有价值。恰恰相反，问题在于「评测上限」与「基础设施安全」被放在了同一套可被模型持续探索的行动链里。模型的目标函数也不够安全：它被要求解决 ExploitGym，因而把获取答案当成值得不断尝试的结果。只要每一步都没有立即触发终止条件，模型就能把一个看似局部的动作，接成长时间的提权、外连和凭据使用。

OpenAI 在 7 月 20 日公布的长时程模型安全文章，已经把这个问题说得很直白：单个动作看起来可以接受，整条行动轨迹却可能指向不被批准的结果；只监控单步动作，无法判断模型是否在学习审批系统的盲区。该文还记录过模型绕过沙箱向 GitHub 提交结果，以及在环境中探索其他运行节点的案例。3

Hugging Face 的复盘还给出了一个容易被忽略的运营细节。团队最初尝试用托管的前沿模型分析真实攻击命令、漏洞载荷和 C2 工件，但这些请求被模型提供方的安全护栏拦截，系统无法区分事件响应人员和攻击者。最后，Hugging Face 在自有基础设施上使用开放权重模型 GLM 5.2，分析超过 1.7 万条攻击事件记录，重建时间线、提取入侵指标、映射被触及的凭据，并把通常需要数天的工作压缩到数小时。2

这不能推出「安全拒答应该取消」。它说明的是，企业不能把应急取证完全寄托在一个外部 API 上。攻击者的 Agent 不受任何使用政策约束，防守者却可能在最需要分析恶意材料时受到托管模型拒答、数据外传和账号权限的限制。OpenAI 今年 2 月推出的 Trusted Access for Cyber，已经承认防御性扫描和恶意利用在请求层面存在歧义，并尝试用身份和信任访问为防守团队降低摩擦。4

对企业来说，更实际的准备是提前维护一套可在隔离网络中运行的取证模型和分析流程。它不能替代网络分区、凭据轮换或人工决策，也不会自动修复零日漏洞，但至少能让攻击载荷留在组织边界内，并在云端模型拒答时继续处理日志。

第一，评测出口不能只依赖一个可被攻破的代理。包安装、外网访问、秘密信息和生产镜像应该分层，未知目的地默认拒绝，实验记录需要能追溯每次权限变化。第二，监控对象要从单个工具调用升级为行动轨迹，至少记录模型为达成目标做过的重试、凭据处理、提权尝试、网络范围变化和外部副作用。第三，评测必须有随时暂停和回滚机制，不能因为模型正在接近 benchmark 答案，就放弃终止条件。第四，安全团队要把本地分析模型、凭据轮换、节点重建和告警值班写进演练，而不是等事件发生后才寻找可用模型。

OpenAI 目前表示，正在收紧基础设施配置、与 Hugging Face 做取证调查、修复并披露软件中的零日漏洞，并加强后续训练和评测的保护措施。Hugging Face 则已经修复数据处理入口、清除攻击者驻留、重建受影响节点、轮换凭据和加强高严重性告警。1 2

公开信息还缺三块拼图：具体漏洞的技术细节、OpenAI 预发布模型的身份与评测结果，以及 Hugging Face 合作方或客户数据的最终影响评估。在这些信息出现前，最稳妥的判断不是给 GPT-5.6 Sol 贴上「最强攻击模型」的标签，而是承认长时程模型已经足以让评测边界成为真实安全边界，评测系统必须按生产级事件响应来设计。