三天时间线：一次拖了 22 小时才公开的入侵
当地时间 10 月 16 日晚，开源 AI 编程工具 OpenCode 背后的开发商 Anomaly Innovations 遭遇了一次未经授权的系统访问。两天后，这件事在开发者社区刷了屏：有用户早上起来，发现自己的 Anthropic 账户多了 400 美元（约合 2,679 元人民币）的非授权扣费，还有人的谷歌云服务凭空冒出约 200 欧元（约合 1,505 元人民币）的账单，对应项目直接因为「滥用」被暂停。扣钱的不是他们自己，而是拿着泄露密钥调用接口的不速之客。
按照官方通报，此次事件影响了约 1.4% 的 OpenCode Console 用户，且仅限于关联了外部模型服务商账户的那部分人。10 月 17 日上午，OpenCode 通过电子邮件向所有受影响用户发出风险告知，并明确表示：没收到邮件的用户不在受影响之列。从官方在社交平台发布公开声明，到第一封告知邮件送达，据媒体报道前后间隔约 22 小时——对于一起密钥外泄事件来说，这个响应速度在社区里引发了不小的讨论。
入口是一家公司的「旧系统」
网友晒出的通知邮件显示，攻击者访问的是一套正处于停用流程中的旧系统。这个细节颇为讽刺：新系统层层设防，真正出事的却是那台早就该下线、却还连着生产环境的老机器。Anomaly Innovations 强调，事故与一次「大规模蒸馏攻击」有关，目前事件仍在处置中，暂时无法披露更多细节，正在与 Anthropic、OpenAI 和谷歌三方协同补救。
受影响的数据是用户存储在工作区里的第三方 API 密钥，涉及 OpenAI、Anthropic，也有用户报告了谷歌服务的异常。官方在通报中使用了相当谨慎的措辞：无法确认这些密钥是否已被恶意利用，调查「迄今为止」未发现其他数据泄露的证据。但社区里的实际反馈跑在了官方结论前面——多名用户表示，在收到 OpenCode 通知之前，就已经先收到了 OpenAI 和 Anthropic 发来的异常使用预警。
为什么编程工具里会存着这么多密钥？这和 OpenCode 的产品形态有关。它是一款运行在终端里的开源 AI 编码代理，2025 年 6 月上线，据外媒统计 GitHub 星标已超过 15 万，支持接入 75 家以上的模型服务商，从 Claude、GPT 到 Gemini 都能调用。工具本体免费，模型费用走开发者自己的账户，于是大量用户把各家 API 密钥存在官方托管的 Console 面板里图个方便——这些密钥因此成了高价值目标，一把就能直接打开付费模型的大门。
「蒸馏攻击」要的不是密码，是你的算力额度
官方给这次事件贴的标签是「大规模蒸馏攻击」。蒸馏在 AI 领域原本是正经术语：用大模型的输出去训练一个更小的模型，从而低成本复制其能力。而当这个词和「攻击」连在一起，含义就变了——攻击者拿着偷来的密钥，以账户主人的身份高频调用前沿模型，把海量问答对收集起来，用于训练自己的替代模型。Anthropic 此前就曾向投资者透露，此类来自竞争对手的规模化「抽取」行为已经对收入造成了实际影响。
这种攻击模式有两个棘手的特点。其一是隐蔽：持续的高频调用在账面上看起来就像正常的大用量客户，等到账单异常或触发限流才会暴露；其二是成本转嫁：模型算力的钱全部记在被盗密钥的持有者头上，社区里那笔 400 美元的非授权扣费就是这么来的。对攻击者来说，这几乎是一门无本万利的生意——工具免费、电力不花自己的、风险由别人承担。
OpenCode 联合创始人 Dax Raad 在事发当天发帖称，他的个人账户也正在被攻击，「AI 驱动攻击，全新的世界。」
值得一提的是，OpenCode 的官方文档此前就明确警告过「不对代理进行沙箱隔离」，建议有安全需求的用户用 Docker 或虚拟机把代理圈起来。但这次的攻击绕过了所有本地防护，直接从服务端的老旧系统里把密钥端走——开发者再小心，也防不住公司自己的后院失火。类似的风险边界问题，其实在整个编码代理赛道都存在，此前我们横评过 61 款编码模型的表现，模型能力之外，凭证托管方式同样值得选型时纳入考量。
官方处置与开发者的应急清单
官方给出的处置建议相当具体，核心就一句话：假设你的密钥已经泄露，立即动手。综合 OpenCode 通报和多家安全媒体的整理，受影响及相邻用户可以按下面的清单自查：
- 立即吊销并重发密钥：直接登录 OpenAI、Anthropic、谷歌各自的官方控制台操作，不要点击任何通知邮件里的链接——攻击者常借着安全事件的由头发钓鱼邮件。
- 审查用量与账单：回查 10 月 17 日以来的调用记录和账单，重点看异常峰值、陌生来源 IP，以及那些对不上已知项目的模型调用。
- 设置支出上限：给新密钥加上硬性消费限额和告警，让一把泄露的密钥再也刷不出无底洞账单。
- 收窄权限：按项目或按人拆分密钥，一个泄露不至于拖垮整个团队的预算；同时更新所有引用旧密钥的流水线和 CI 任务。
- 必要时重置 Console 密码：重新生成 OpenCode Console 的 API 密钥，确保旧凭据全部作废。
对独立开发者来说，这套动作大概半天能做完；但对小团队而言，轮换密钥意味着要动生产配置、CI 作业和每个成员的本地环境，是个实打实的苦活。有人在网上吐槽：本来只想让 AI 帮忙写两行代码，结果周末全搭在改配置上了。
这起事件给普通开发者提了个醒
把视角拉远一点，OpenCode 并非第一次出现在安全讨论里。据外媒披露，今年早些时候安全研究者曾发现该工具存在一个严重的远程代码执行漏洞，源于旧版本自动启动的未认证本地 HTTP 服务器，随后在 1.1.10 版本中修复。再加上行业内此前发生过的 AI 模型把研究人员的 GitHub 令牌发布到公共代码库等事件，编码代理的安全记录确实谈不上漂亮。摩根大通 CEO 杰米·戴蒙甚至公开表示，出于安全考虑，银行不会允许外部 AI 代理登录客户账户。
道理不复杂：AI 编码代理要读文件、执行命令、调用付费接口，天然就得拿到一堆高权限凭证。工具越强大，密钥就越集中，单点失守的爆炸半径也就越大。微软正在推进的 Agent Lightning 智能体训练框架 代表了能力侧的演进，而能力越强，凭证治理越要跟上，这是一体两面。
对普通开发者的建议可以浓缩成三条习惯。第一，把「密钥会泄露」当作默认前提，任何存过密钥的服务，都要想清楚它出事时的轮换路径有多长；第二，能用短期凭据就不要用长期密钥，能给密钥设限额就一定设；第三，盯紧账单告警，很多时候提供商的异常检测比你自己的服务商通知来得更早。AI 编程工具值得用，但把家门钥匙全部塞给一个第三方平台之前，先想想——它家旧仓库的门锁，真的都换了吗？
