AI编程工具拿着你的密钥,出了事谁来收场?

把模型API密钥接进编程助手，通常只要几分钟。工具因此能替你调用模型，少配几套账号，也不用每次切换服务商。10月17日，OpenCode披露其Console发生安全事件，称约1.4%的Console用户受影响，涉事用户是连接过外部模型服务的一部分人。

OpenCode说事件与一次“大规模蒸馏攻击”有关，并称已通知受影响用户，正在与Anthropic、OpenAI和Google协同处理。公司没有公布入侵路径、影响账户的绝对数量，也没有说明被保存的密钥是否都被拿走或滥用。流传的用户通知提到一个正在退役的旧系统，以及工作区中的第三方密钥“可能暴露”；这个通知来自网上分享的截图，OpenCode公开帖确认了事件和邮件通知，但没有给出完整技术复盘。

密钥一旦交给托管层，信任边界就变了

OpenCode既有本地运行的开源编程工具，也有托管式Console。Console可以让团队在工作区里连接外部模型服务。对开发者来说，保存一把API密钥之后，工具就能代为请求模型；对服务运营方来说，这把密钥也进入了它必须保护的系统边界。

这次公开披露针对的是Console中连接了外部服务的部分用户。它不等于所有本地安装OpenCode的人都受影响，也没有证据显示开发者只在本机保存的密钥因此暴露。这个区别值得保留，不能把“OpenCode发生事件”写成“OpenCode所有用户的密钥泄露”。

“1.4%”说明不了损失有多大

这个比例的分母是OpenCode Console用户，不是全部OpenCode用户；OpenCode也没有公布Console用户总数，所以无法换算成具体人数。更重要的是，受影响账户、可能暴露的密钥、实际被使用的密钥，以及因此发生的费用，是四个不同口径。

OpenCode在公告中用了“distillation attack”这个说法，但目前没有公开细节解释攻击者如何进入旧系统，也没有说明密钥暴露与所谓蒸馏行为之间的具体联系。媒体报道和社交平台上出现了异常账单的个人说法，但尚不能据此推算整体损失。把术语写得像已经查明的攻击链，会比现有证据走得更远。

我更关心的是另一层问题：一把密钥往往不只是模型调用权限，还可能带着额度、项目数据和某种程度的账号访问能力。若多个供应商凭证都集中保存在同一托管工作区，集中管理固然省事，事故的影响半径也会跟着变大。密钥究竟由谁持有、谁能撤销，平时并不显眼，出事时就很难绕开。

密钥泄露后，删除配置不等于撤销权限

OpenCode分享给受影响用户的通知建议到对应服务商后台撤销并更换密钥、更新使用旧密钥的应用，并查看近期用量。安全公司Cyera也建议直接访问服务商控制台，核对调用记录并设置支出上限。若凭证已经被复制，只从OpenCode工作区里删掉它，并不能让旧密钥失效。

团队还得找出密钥被哪些脚本、CI任务和内部工具共用。紧急轮换时，业务可能随之中断；但如果不先确认依赖关系，旧密钥被撤销后，真正使用它的任务也会失败。对收到OpenCode通知的用户，先在服务商侧撤销受影响密钥，再更新依赖它的地方，并检查账单和调用记录，是更稳妥的顺序。

AI工具接入凭证，也该按服务账号来管

这类工具接入模型的方式正在变得日常：开发者把供应商密钥交给IDE插件、命令行助手、托管工作区或自动化流程。它们不是单纯的聊天窗口，而是拿着用户授权持续发起请求的软件。凭证管理就不应只停在“这个工具能不能连上模型”。

我的判断是，密钥应尽量按项目或用途拆分，权限和额度只给到工作所需；能设置支出告警、调用限制的服务都要打开。公司也应有一份清单，知道哪些人把哪些服务商凭证交给了哪些托管工具，并明确由谁负责撤销和轮换。能否在产品架构上减少托管方接触用户密钥，也应该成为选型时的问题。

这次事件还没有完整复盘，责任边界和真实损失都待更多信息确认。但有一点已经够清楚：AI工具越能替人直接操作，凭证就越像它拿在手里的工作权限。方便可以继续追求，密钥却不能因为“只是接模型用”就按普通配置项对待。