对用 AI 编程工具的开发者来说，最贵的东西不一定是代码，而是藏在工具里的 API 密钥。10 月 17 日，开源编程助手 OpenCode 披露了一起安全事件：一个正在退役的旧系统遭到未授权访问，约 1.4% 的控制台用户保存在工作区里的第三方密钥可能已经外泄，涉及 OpenAI、Anthropic、Google 等提供商。

事件本身说了什么，没说什么

按照 OpenCode 的说法，这次事件与一场大规模的所谓“蒸馏攻击”有关，影响的是在控制台里关联了外部提供商的那部分用户。公司表示已经通过邮件逐一通知了受影响用户，并称如果没有收到通知，就不在受影响范围内。它同时表示，正在与三家提供商一起处理善后。

但有两点需要单独拎出来看。第一，公司目前没有公布攻击手法的技术细节，只说事件还在处理中，暂不便透露更多。第二，“蒸馏攻击”这个说法本身受到了质疑：蒸馏通常指用模型输出训练另一个模型，而不是密钥外泄。把密钥外泄描述成蒸馏攻击，容易让人误以为问题出在模型层面，而实际上这次的核心是凭证保管出了问题。

为什么密钥外泄比一般的泄露更麻烦

API 密钥一旦外泄，风险不只是“有人能调用模型”。拿到密钥的人可以直接用你的账户调用高价模型，账单会迅速上涨。有用户报告账单出现异常增长，甚至出现账户被暂停或删除的情况。更隐蔽的是，某些密钥还能读取你上传过的文件、保存的响应记录或微调模型，泄露范围可能超出一次调用。

而且密钥和密码不一样：密码泄露了改一个地方就行，密钥往往同时挂在多个地方——本地终端、持续集成任务、内部小工具、另一个编程助手。只在某一处换掉，却漏掉另一处，老密钥还在生效，风险就还在。

收到通知的用户，第一小时该做什么

第一步是先止血，不要先做复盘。按这个顺序处理：

1. 确认自己是否在影响范围内：先找 OpenCode 发来的通知邮件。没有收到，不代表可以完全放心，但处理优先级上应先处理已确认受影响的密钥。
2. 到提供商后台吊销并重新签发：分别登录 OpenAI、Anthropic、Google 等提供商的控制台，找到对应的密钥，直接吊销旧密钥、生成新密钥。不要只改 OpenCode 里保存的那一份。
3. 把新密钥同步到所有用它的地方：列出所有用到这把密钥的工具和任务——本地环境变量、持续集成配置、内部应用、其他编程助手——逐个换成新密钥，再吊销旧密钥。顺序反了容易导致正在跑的任务中断，或者旧密钥继续留在某个角落。
4. 核对 10 月 16 日以来的用量与账单：重点看有没有不熟悉的模型、异常的调用量、深夜时段的活动，以及金额突增。发现异常先截图保存，再联系提供商申诉。
5. 设置 spending 上限与用量提醒：给每个提供商账户都设一个硬性上限和提醒。上限拦不住已经发生的盗用，但能把损失封顶。
6. 清理控制台里不再用的关联：在 OpenCode 控制台里检查每个工作区关联的提供商，把不再需要的关联删掉。控制台里的预算只覆盖走 OpenCode 的消费，拦不住被盗密钥直接调用提供商的消费。

没收到通知的用户，也该顺手做三件事

这次事件暴露的是一个通用问题：密钥放在别人的托管控制台里，就等于同时放在对方的数据库、备份和所有还没下线的旧系统里。工具开源只说明你能看懂跑在自己电脑上的客户端代码，不代表你能审计对方的服务端保管方式。

建议顺手做三件事：第一，给密钥做一份清单——哪把密钥、属于哪个提供商、放在哪里、什么时候建的、上次轮换是什么时候；第二，实行“一工具一密钥”，一个密钥只给一个工具或一个项目用，泄漏了只吊销一把；第三，把密钥放在自己机器上的环境变量或权限严格的文件里，不要提交进代码仓库，不要在聊天记录里粘贴明文密钥。

怎么看这次事件

这件事的教训不在于某个工具能不能用，而在于凭证管理必须按服务账号的标准来做：有归属人、有轮换周期、有最小权限、有用量监控。AI 编程工具越方便，密钥就越集中，集中就意味着一次旧系统的疏忽可能变成所有人的账单事故。把“谁拥有密钥、谁在用密钥、密钥能访问什么”这三个问题答清楚，再谈效率，才是这次事件真正该留下的结论。