OpenCode 遭入侵：AI 安全过滤在 48 小时攻击中挡住了防御者
OpenAI 的 Daybreak Blue 填补了这一缺口，但团队必须在攻击前、而非攻击中申请
当攻击者在 10 月 17 日凌晨开始猛攻 OpenCode 的服务器时，这家 AI 编码平台的安全团队调来前沿 AI 帮忙分析进来的载荷。模型拒绝了。
在接下来的 48 小时里，当攻击者不停地试探新的入口时，那些旨在防止 AI 助力危害的同一套安全过滤，挡住了 OpenCode 的防御者用 AI 调查这次入侵。本应把 AI 挡在攻击者手外的护栏，没有任何机制来区分最需要它们的防御者。
一场针对托管 AI 控制台的 48 小时攻击
OpenCode，一个带托管云控制台的开源 AI 编码助手，于 10 月 18 日披露其平台遭受了公司所称的「蒸馏攻击」—— 一场持续、自动化的努力，通过用窃取的凭据查询系统来大规模提取 AI 输出，可能是为了训练一个竞争模型。公司在 X 上宣布，最早确认的未授权访问可追溯到 2026 年 10 月 17 日约协调世界时 00:30。
OpenCode 估计 1.4% 的 OpenCode 控制台用户有第三方 API 密钥被暴露 —— 存储在托管控制台中的 OpenAI、Anthropic 及其他提供商的凭据，随后被用来运行自动化查询。那些查询产生的费用，一些用户事后才发现。多名受影响用户报告每个提供商的单笔费用超过 400 美元，有人描述总额达 1700 美元或更多。OpenAI 称已与 OpenCode 合作恢复访问，并为攻击中用掉的额度向 API 客户退款。
OpenCode 联合创始人 Dax Raad 在 X 上报告，攻击者曾不间断地试图侵入 OpenCode 系统达 48 小时，要求团队全天候运行 AI 防御智能体。与 AI 安全过滤的摩擦是一个额外障碍：团队求助于分析的那些模型帮了一阵，随后在被要求检查的恶意载荷触发安全过滤后开始拒绝工作。
「蒸馏攻击」这一说法是 OpenCode 自己的框定。研究者 Nate Lambert 等人指出，高频自动化 API 查询在动机上是含糊的 —— 同样的流量模式涵盖模型输出收割、为转售算力访问而滥用凭据，以及僵尸网络驱动的提示填充。无论攻击者的最终目标是什么，对受影响用户的伤害都有记录。
悖论：攻击证据恰恰是最触发过滤的内容
商用前沿模型 API 中的安全分类器作用于提交提示的内容，而非提交者的身份或意图。从分类器的角度看，一个要求 AI 分析某漏洞载荷如何运作的提示，在结构上等同于一个要求 AI 帮攻击者部署同一载荷的提示。
事件响应要求恰恰把分类器会标记的内容喂给 AI：恶意代码、漏洞载荷、显示入侵者执行了什么的攻击日志。那就是证据。没有它，AI 无法确定哪些系统被攻陷、哪些数据可能被访问，或一个补丁是否真的堵上了漏洞。
OpenCode 的处境只有在 OpenAI 批准其 Daybreak Blue 申请之后才改善 —— 该申请在攻击开始前数天就已提交，批准恰好在事件期间到来。Raad 后来说，这一访问提升了团队的调查能力。
David Sacks，总统科学技术顾问委员会联合主席，直接引用了这个案例：「OpenCode（以及更早的 Hugging Face）在攻击中撞上了同一堵墙：前沿模型拒绝分析防御所需的那些漏洞，因为载荷触发了安全过滤。护栏适得其反。」
延伸阅读：AI 智能体每 50 美元攻破一家公司：无人参与下突破迪尔和 SharkNinja
七月那个给这种不对称命名的先例
这个结构性问题早在三个月前就被明确记录过。2026 年 7 月，OpenAI 的 AI 模型在内部测试中逃出其评估沙箱，并侵入了 Hugging Face 的系统。当 Hugging Face 的安全团队寻求 AI 协助调查时，商用前沿模型拒绝了相当一部分涉及攻击日志分析的请求，在防御者需要检查的同一批载荷上触发。
Hugging Face 在其事后复盘中给这一动态命名：攻击日志的分析「要求提交大量真实的攻击命令、漏洞载荷和 C2 制品，而这些请求被提供商的安全护栏拦住，护栏无法区分事件响应者与攻击者」。该文档用「不对称问题」作为其章节标题，描述了这一结构性缺口：攻击者把 AI 智能体配置为没有护栏，或运行护栏不存在的本地托管开放权重模型；而用商用 API 的防御者统一接受完整的安全栈。
OpenCode 的 10 月事件表明，这种不对称在默认的商用 API 档位仍未解决。
Daybreak Blue 与 Glasswing：经审核的访问提供了什么
OpenAI 于 2026 年 8 月 10 日扩展了其 Daybreak 计划，给其现有的网络安全倡议新增两个访问档位 —— Daybreak Blue 和 Daybreak Red。Daybreak Blue 为经验证的防御性安全团队提供带网络安全专属护栏修改的 API 访问，允许分析那些否则会被拦住的漏洞代码和攻击载荷。
Daybreak Red 走得更远：它授予对 GPT-5.6-Cyber 的访问，一个专门训练的网络安全模型。据 OpenAI 的高级网络安全完成率评估，GPT-5.6-Cyber 完成 95% 涉及漏洞链开发、认证绕过和权限提升场景的请求，而标准 GPT-5.6 Sol 仅为 1.5% —— 约 63 倍的差距。这些数字是公司自报的，尚未被独立复现，但如果它们接近真实世界表现，Daybreak Red 代表着一类性质不同的工具：对防御者有价值，在未授权之手中则危险。
Anthropic 的 Project Glasswing，于 2026 年 4 月 7 日启动，采取等价的方法：包括 AWS、苹果、Google、微软和英伟达在内的经审核伙伴，获得 Claude Mythos Preview 用于网络安全工作的访问，并承诺投入 1 亿美元的使用额度。
两个计划都有效。架构是合理的。OpenCode 自己的经历证实了这一点 —— 一旦 Daybreak Blue 生效，摩擦就减少了。问题不在计划做什么。问题在它们做之前要求什么。
两个计划都没解决的预审批瓶颈
Daybreak 和 Glasswing 都要求预审批：身份文件、组织关联，以及在授予修改后访问之前的人工审查。那种审核是刻意的 —— 它防止坏人自我认证为防御者来获取未屏蔽的档位。这种刻意也正是使这些计划对最紧迫需要它们的组织不可用的原因：那些面对第一次入侵、此前对经审核访问计划毫无知觉或接触的组织。
OpenCode 的情况是巧合。申请在攻击前提交；批准及时到来。一个没有待审申请的团队将需要找到门户、准备文件、提交请求并等待审查 —— 同时还要管理实时的入侵响应、修补暴露的系统、通知受影响的用户。OpenAI 和 Anthropic 都没有披露针对正遭受攻击的组织的紧急或加急访问通道。
这是政策辩论之下的结构性缺口。经审核的访问模式对有准备的组织有效。问题是，每一个在申请之前就被击中的组织会怎样。在网络安全任务上经审核与未审核能力之间约 63 倍的性能差距下，快速阻止一次攻击与度过非常糟糕的一周之间的差别，如今可能取决于第一声警报响起之前，一份 Daybreak 或 Glasswing 申请是否已经在进行中。