OpenCode 出事的是替团队保管钥匙的云端控制台：被偷的钥匙在厂商那边刷账，工作区预算管不到

据 The Latent 报道，美东时间 10 月 17 日上午 9:36，开发者 Colin Parsons 在 X 上写道，自己的 OpenAI 密钥从凌晨两点起被刷掉 281 美元，Anthropic 密钥被刷掉 168 美元。他说这两把密钥只在 OpenCode 里用过。几个小时后，这款开源编程智能体才公开说：前一晚出了安全事件。

先说结论：这次出事的不是装在开发者电脑上的 OpenCode，而是它替团队保管模型密钥的云端控制台 OpenCode Console。把密钥交给网关托管，换来的是成员不用经手密钥；代价是，这把长期有效的密钥一旦被拿走，控制台上的预算和权限都拦不住，盗刷记在模型厂商的账上，止损得靠用户自己和模型厂商。

发生了什么

据 OpenCode 官方 X 账号的声明（企业宣称），北京时间 10 月 18 日凌晨 1:56 首发、2:08 修改：前一晚发生了一起安全事件，OpenCode 称它与一次大规模蒸馏攻击有关，影响 1.4% 的 OpenCode Console 用户；受影响的都已在当天早上收到邮件，没收到邮件就不受影响，受影响者是接入了外部模型提供商的那部分用户。据 The Latent 引述，声明还写着事件仍在进行，正与 Anthropic、OpenAI 和 Google 一起处理。

邮件内容来自收件人的转发。据 The Latent 的报道（媒体报道），邮件标题是「Action Required: Potential provider key breach」，正文说有人未经授权进入了一套正在下线的旧系统，保存在工作区里的密钥可能外泄，要求用户到各家厂商后台吊销密钥并留意异常用量。同一篇报道列出了几位用户自报的损失：Parsons 的 281 美元和 168 美元，Preston Zeller 的 1700 美元，另一位用户的 OpenAI 用量超过 700 美元；The Latent 注明无法独立核实。

随后两条澄清很关键。据 Dax Raad 的回复（企业宣称），出事的是 OpenCode Console，不是 OpenCode 本身，在 OpenCode 应用里用的密钥从不会到他们手里。据 Anthropic Claude Code 团队 Lydia Hallie 的帖子（企业宣称），Anthropic 已吊销它认为受影响的 Claude API 密钥，并建议在 OpenCode 里存过密钥的人重新生成一把。

据 VibeIncidents 的事件页（媒体报道），用户在美东时间 17 日清晨就开始报告异常用量，早于 OpenCode 的公开声明；到当天下午约 3 点，OpenCode 的状态页上没有安全事件记录，开发方 Anomaly 也没有发布安全公告或博客。

钥匙放在了哪里

先把两样东西分开。OpenCode 是跑在开发者电脑上的智能体，用户自己填的密钥留在本机。OpenCode Console 是付费的云端服务，按 Console Providers 文档（官方文件）的说法，团队管理员可以把已经付费的 Anthropic、OpenAI、AWS Bedrock 等账户接进来，Console 保存这把凭据，通过自己的网关转发请求，成员用模型时始终看不到密钥。

按文档的写法，好处是成员始终接触不到密钥。问题出在这把密钥是什么：文档里管理员填进去的，就是该提供商的 API 密钥本身。

再看 Console 能管住什么。据 Console Budgets 文档（官方文件），工作区可以设月度预算，超出后新请求返回 429；接入自有提供商的模型，在设了价格的前提下按配置价格计入预算。

分析推断：依据上面两份文档，预算是在请求经过 Console 网关时检查的；厂商的 API 密钥谁拿到都能直接调用厂商接口，攻击者拿走原始密钥后直接调用，这些调用不经过网关，工作区预算、成员权限、用量报表都看不见它们，用户的损失只能在厂商后台出现。据 The Latent 报道，Parsons 等人是在自己的 OpenAI、Anthropic 账户上看到异常费用的，这和上面的推演一致。需要说明，邮件说被入侵的是一套正在下线的旧系统，现行文档描述的是新版 Console，两者的存储方式未必相同。

止损动作落在了谁身上

把这一天的动作排一下，就能看清人在哪里接手。异常是用户自己在厂商账单上看到的；吊销密钥，OpenCode 的邮件交给了用户到各家后台去做；公开说明替用户吊销密钥的，目前只看到模型厂商 Anthropic。至于赔付，据 Dax Raad 回复一位自报损失 1700 美元的用户（企业宣称），他让对方把情况发邮件给他，说会安排退款；我们没有找到面向所有受影响用户的统一赔付公告。

为什么重要

OpenCode Console 是编程智能体的团队版：统一网关、共享模型、按人设预算。网关替团队管住了谁能用哪个模型、每月花多少，但只要它保存的是厂商发的密钥本身，它就同时成了一处集中存放钥匙的地方。

我们的看法：评估这类团队平台时，「是否托管密钥」比「是否开源」更值得先问。我们的依据是这次事故里，按开发方的说法，客户端里的密钥不受影响，出事的是托管服务；以及按 Console 文档，预算是对发往 Console 的请求生效的。如果后续调查显示泄露的并非原始密钥，而是只能经由 Console 网关使用的令牌，或者 OpenCode 公布的根因与密钥托管无关，我们会改口。

最强反方

最有力的反驳是：这只是一次普通的服务端入侵，和智能体、和托管模式都无关。任何保存凭据的云服务被攻破都会这样；影响面只有 Console 用户的 1.4%，OpenCode 当天就发了通知，Anthropic 当天就吊销了密钥，处置并不慢。不托管密钥，团队就得把密钥发给每个成员，散落在几十台电脑上，风险未必更小。

我们在两点上让步：托管本身不是错，集中保管确实比散发更好审计；这次处置速度也不算慢。但论点不变。区别在于托管的是什么：如果网关保存的是长期有效、可以绕开网关直接使用的厂商密钥，那它就只集中了风险，没有集中控制，团队在网关上设的预算对盗刷不起作用。VibeIncidents 事件页给出的建议是在每家厂商设月度消费上限或预算提醒、每个工具单独用一把密钥，这正是在网关之外补第二道闸门。

我们不知道什么

攻击者如何进入那套旧系统，密钥在旧系统里是否加密保存；涉及多少把密钥、多少个工作区，1.4% 对应的绝对人数；OpenAI、Google 是否也像 Anthropic 一样主动吊销了密钥；它所说的蒸馏攻击与这次入侵是什么关系，OpenCode 没有解释；退款是逐个处理还是会有统一方案；新版 Console 是否沿用了同样的密钥保存方式。

接下来看什么

一是 OpenCode 是否发布完整的事后复盘，写明入侵路径、受影响密钥数量和加密方式；二是 OpenAI 与 Google 有没有公开处置说明；三是 Console 会不会调整密钥的保存与使用方式；四是其他智能体平台的团队版是否随之公开自己的密钥托管方式。