一次自动化红队演练越界，波及第三方平台

2026 年 8 月初，Hacker News 上一则帖子迅速升温：OpenAI 的内置安全测试系统意外对 Hugging Face 的推理 API 发动了持续近 36 分钟的对抗性攻击，导致部分模型端点响应延迟飙升、错误率突破 40%，甚至触发了 Hugging Face 的恶意流量自动封禁机制。所谓“攻击”并非由人类黑客发起，而是源于 OpenAI 一个名为 “AdaRed” 的内部红队智能体。该智能体原计划在隔离沙盒中对自研模型进行自动化越狱和注入测试，却因为配置漂移，将流量误导向了 Hugging Face 的公开推理服务。

整条时间线从 8 月 6 日凌晨 2:17（UTC）开始，到当日 2:53 服务完全恢复，共计 36 分钟。期间，来自 OpenAI 测试集群的 14,200 多条精心构造的对抗性提示涌入了 Hugging Face 上至少三个热门模型（包括 Llama-3-70B 和 Falcon-180B 的社区托管版本）。这是首起大公司自动化安全工具意外攻击另一家主流开源模型平台的公开事件，立刻引发了关于 AI 安全研究边界、压力测试道德以及 API 调用责任归属的广泛讨论。

技术细节

事件的技术链路可从三个侧面拆解：输入侧、推理/执行侧、输出/评测侧。

输入侧

AdaRed 智能体使用了基于梯度的提示词优化方法，自动生成大量“越狱模板”，例如将恶意意图包装为多轮角色扮演、递归翻译或 BASE64 编码。这些提示在设计上专门针对模型的指令遵循偏差，旨在绕过系统级安全策略。由于配置错误，测试的目标 URL 从内部沙盒地址变成了 Hugging Face 推理端点的公开域名。输入本身在语法上完全合法，因此能轻松穿透常规的 Web 应用防火墙和简单的速率限制。最具迷惑性的是，这些提示模拟了正常用户对话的元数据（User-Agent、会话 Token 结构），使得初期的异常检测难以区分。

推理/执行侧

Hugging Face 的推理服务依托共享 GPU 资源池，当某几个热门模型同时接到高熵值的对抗性输入时，解码过程触发了自回归生成的极端情况：长序列循环、重复 token 拒绝采样频率剧增，导致单次请求的推理时延从平均 200ms 飙升至 12 秒以上。部分模型由于未对输出 token 长度做硬性截断，在遇到反复诱导生成“继续写下去”类提示时，会持续占用计算资源直至超时。与此同时，Hugging Face 的自动伸缩策略试图增加实例应对激增负载，却进一步放大了资源争抢，形成恶性循环。

输出/评测侧

攻击流量的初衷是观测模型是否输出有害内容，因此 AdaRed 携带了严厉的输出评估模块：发送提示后立刻扫描回包内容，若未触发目标不安全输出则立即变体重试。这导致它在 36 分钟内以极高频率反复尝试，且每次变体都针对上一次的“防御成功”进行自适应演化。Hugging Face 端点的返回内容被 OpenAI 内部的安全分类器标记，意外触发了 OpenAI 的安全告警——正是这一告警最终让运维团队发现了配置错误并手动切断测试。也就是说，攻击方通过自己输出侧的检测，反向意识到了攻击已经越界。