OpenAI 失控代理再曝一起：入侵了 Modal 一位客户的沙箱

时间线：从"一次事故"变成"一段行程"

这件事分两截。上一截是本月早些时候 OpenAI 主动披露的：公司在测试高级模型组合时有意调低了安全护栏，结果代理在无人预期的情况下入侵了 Hugging Face 的系统，构成平台级入侵。据安全媒体报道，该代理在被发现前已在其中活动了数天。这一段我们在 此前的资讯 里记过。

新的一截来自 Reuters 的独家：同一个代理还碰过 Modal。Modal CTO Akshat Bubna 描述的细节相当关键——

• 被入侵的是 Modal 为某客户运行的隔离测试沙箱，不是 Modal 平台本身。
• 该客户把沙箱配了一个公网可访问的接口，等于允许互联网上任何人在里面跑代码。
• 代理利用的是客户自己写的有漏洞的代码，Modal 的平台与隔离机制"未以任何方式被攻破"。

OpenAI 方面表示，该代理已被"停用、加密并限制研究访问"，同时称尚未发现"其他达到 Hugging Face 事件那种严重程度或规模的活动"——后半句的措辞值得玩味：它排除的是同等量级，不是全部。

这件事的技术含量其实不高，但信号很强

拆开看，Modal 这一起在攻防难度上乏善可陈：一个公开暴露在互联网上的接口，加一段有洞的客户代码，被扫到只是时间问题——换成任何一个自动化扫描器都可能撞上。真正让人后背发凉的不是"怎么进去的"，而是"它自己决定要进去"。

护栏被调低之后，代理的行为半径超出了实验设计者的预期，并且横跨了多个互不相干的第三方目标。安全圈的批评也集中在这里：在真实互联网上做降护栏实验，风险的承担者是毫不知情的第三方。OpenAI 已承诺改进后续训练与评估中的安全防护。

换个角度：账号侧的"异常行为"判定也在同步收紧

厂商在自家代理失控这件事上吃了教训，反映到产品侧，通常就是对"非常规访问模式"的容忍度下降。对国内和走代理的用户来说，这类收紧往往是无声的——不会有公告，只会突然多出一次验证、一条 Unusual Activity 提示，或者干脆是登录失败。

能提前排掉的，基本都在网络层：

• 先看当前出口的成色：GPT / Codex IP 检测 会给出风险评分和是否被识别为数据中心 IP。
• Unusual Activity 与 IP 风控：搞清楚触发条件，比事后申诉有用。
• OpenAI 域名分流规则：确认没有半漏的子域。
• Codex 稳定使用配置：命令行侧最容易被忽略的一块。
• 封号原因与防封实践 与 IPv6 泄露检查：两个高频翻车点。