在控制台删掉那把钥匙，并不等于吊销它

一眼概览

哪些已被公开确认，哪些目前仍只是报道。据报道，OpenCode 的披露发生在 2026 年 10 月 17 日，而 TechCrunch 于 10 月 19 日作了报道。

最后三行请当作报道、而不是事实来读。下文的论证不需要它们当中的任何一条，只需要前三行，以及 OpenCode 不得不写进补救建议里的那句话。

补救指示本身就是那个发现

按顺序读一遍受影响用户收到的建议：去每家提供方替换 key、更新用到它的那些应用、检查近期用量。这一串动作里，没有任何一步是由 OpenCode 自己的产品完成的。它做不到。一把提供方 API key 是由 OpenAI、Anthropic 或 Google 签发、并由它们在每次请求时校验的持票凭证；唯一能让它失效的，是签发它的那一方。OpenCode 可以删掉自己手上的每一份副本，而那串泄露出去的字符仍会继续买走推理算力——直到有人登进另一家公司的控制台。

这与大多数事件响应预案所针对的那种泄露形状不同。当厂商泄露的是你的数据，厂商可以收口：下掉系统、轮换密钥、补上窟窿。而当厂商泄露的是你交给第三方的凭证，这场事件里没有任何一方具备收口能力。厂商知道 key 泄了，却杀不掉它。提供方杀得掉，却不知道它泄了。同时握着这两件事实的只有你一个，而其中第一件，你是从一封邮件里得知的。

界面只会让情况更糟而不是更好，因为那个控件就摆在那里，而它是一次空操作。断开集成、删掉工作区、移除已保存的 key——这三样在任何用过 OAuth 授权页的人看来都是「吊销」，因为在那里断开连接确实会让授权失效。而在这里，同一个手势删掉的只是一份副本。这把凭证的寿命从来就不在厂商的掌控之内，所以厂商界面上的任何按钮都缩短不了它。

谁手上握着什么

那张矩阵里的每一行，都缺着别的行有的东西，而这些缺口叠起来是一个具体的运维失效。提供方吊销得了，但在有人告诉它之前没有理由动手。厂商知道，却只能请求。你动得了手，手上却没有那份日志。没有任何一方能在自己的系统内部把这场事件处置完——而这恰恰就是一次没人设计过的职责分离的定义。

被偷走的资产是钱，而它的监控器是一张账单

一把被偷走的提供方 key 不寻常的地方，不在于它是怎么被存的，而在于它能兑换成什么。一行泄露的数据库记录得先被卖掉、被关联、或被再次利用，才会让谁付出代价。而一把泄露的提供方 key 本身就有流动性：它从第一个请求起，就按公开价目买走 GPU 时间，账记在你头上。

这就改变了检测该住在哪里。攻击者的请求从不碰你的基础设施——它们从那台机器直奔提供方的端点。你的网关什么也不记。你的 SIEM 什么也看不见。你的限流器不在路径上。这场滥用的权威记录是提供方的用量看板，而权威的告警是一道计费阈值——在多数组织里，这恰恰是那个由财务部门按月查看、而不是由值班工程师持续盯着的信号。那些及时发现的用户之所以发现，是因为一夜之间的一笔消费大到足以触发提供方的一封邮件。

把价格算清楚：一把长期有效、没有封顶的提供方 key，等于一张开给「谁拿着这串字符谁就是额度主」的无上限信用额度。这就是该写下来的影响半径；而这里被报道的那些数字——一夜之间每把 key 数百到数千美元——是下限而不是上限，因为它们描述的是一个随手花钱的攻击者。一个对着没有上限的 key 刻意花钱的攻击者，其边界只由提供方自己的限流与风控启发式决定，而这两样都不是你配置的。

「蒸馏攻击」是一个动机，不是一个指标

OpenCode 把这次事件定性为蒸馏攻击——偷 key 以从前沿模型上生成训练数据。它可能是对的。但截至本文撰写时，它没有公布任何把泄露凭证与蒸馏活动联系起来的技术证据，也完全没有公布入侵指标：没有入口途径、没有 key 的存储方式、没有攻击者流量长什么样。

动机不可操作，指标可操作。如果这场行动被按请求形状描述出来——哪个模型、什么采样参数、什么提示词分布、多大并发——那么本周之内，所有其他替客户保管 key 的厂商都能去翻一遍，提供方也能。而点名动机做到了一件指标做不到的事：它把故事从「一家公司把持票凭证存在一套遗留系统里」挪到了「一家公司被精密的对手盯上了」。两者可以都为真。但只有一个能产出检测规则。

这也是智能体工具事件报告里普遍该留意的模式。有用的问题不是「谁、为什么」，而是「同行明天能 grep 什么」。按这个尺度衡量，这次披露目前仍是一则通知、而不是一份报告——而这很要紧，因为厂商是唯一能产出那份报告的一方。

该改成怎么建

设计规则直接从那张矩阵里掉出来：绝不要把一把长期有效的提供方 key 交给第三方的网页工作区，因为这么做转移了保管权、却没有转移吊销能力。今天有三条替代路线，按工作量与收益递增排列。

三条里只有网关真正修好了那道裂缝，而原因是结构性的、而不是什么巧思：它让你成为签发方。一把你自己造出来的凭证，就是一把你自己能作废的凭证——这就把保管、吊销与观测重新收拢回同一张办公桌上，也就是你的。它还把消费计量表放到了一个你本来就会被传呼的地方，而这正是这场事件里任何轮换都解决不了的那一半。

如果运维一个网关对你的团队并不相称，那么诚实的退路是认真对待第一行：每款工具一把 key、一道会让人不太舒服而不是宽宽松松的上限，以及一份清醒认知——每一把这样的 key，都是一份你收不回来的副本。这不是一个强势的位置。这就是「自带 key」把你放到的那个位置；而这次事件的价值，在于它被一封补救邮件说出了声。

延伸阅读

本站相关：

• 凭证寿命——为什么一个秘密的时钟比它的强度更要紧。
• AI 网关——让你从「持有者」变成「签发方」的那个组件。
• 把凭证送进沙箱——如何把秘密交给智能体而不把它落在某处。
• 当凭证代理被攻破——这次事件所属的那种失效模式。
• 拒绝钱包与成本攻击——把消费当作攻击面。
• 智能体凭证的访问复查——那份能告诉你哪些 key 还在外面的清单。

来源：

• TechCrunch，2026 年 10 月 19 日——黑客攻击 AI 编程工具 OpenCode，在用户的 AI 账户上刷出消费
• BleepingComputer——OpenCode 被黑致 API key 暴露，适逢 AI 蒸馏攻击
• SC Media——OpenCode 泄露事件在一次蒸馏攻击中暴露 API key