一周前，我们刚在本栏目介绍过 OpenCode 2.0 的发布——后台插件、服务化架构，一个开源编码代理的高光时刻。一周后，同一个名字以一种谁都没想到的方式回到了新闻里：10 月 17 日 18:08 UTC，OpenCode 官方确认其一个正在退役流程中的 legacy Console 系统遭未授权访问，1.4% 的 Console 用户在那里保存的第三方 API Key 外泄——涉及 OpenAI、Anthropic 与 Google 的密钥，而且攻击者已经开始在受害者的账单上消费这些 Key。
这件事值得写的理由不只是「又一起泄露」。它把编码代理行业一个心照不宣的架构选择推到了聚光灯下：**你的 API Key，为什么要存在别人那里？**以及一个更少被讨论的运维盲区：正在退役的系统，为什么是最容易被攻破的那个？
事件链条：尽可能还原公开事实
先把已披露的信息按时间排一下。入侵发生在 10 月 16 日至 17 日夜间。目标是一个 legacy Console 系统——官方描述它「已经在退役流程中」。该系统的功能之一是让用户保存第三方 provider 的 API Key，这也是当年 Console 的核心卖点：把你的 OpenAI、Anthropic、Google Key 存进来，由 Console 统一代理调用、统一出账单。
攻击者拿到的是什么？不是加密后的哈希，而是可直接使用的明文 Key——这一点从「陌生人随后用这些 Key 在用户账单上消费」可以反推。10 月 17 日，OpenCode 向受影响用户发送邮件，并在社交平台公开声明：影响 1.4% 的 Console 用户，全部为关联了外部 provider 的账户；未收到邮件的用户未被波及；建议相关用户立即轮换 Key。
有几个问题目前没有公开答案：攻击者如何进入 legacy 系统、Key 在系统内是否加密存储、被消费的金额规模、以及为什么一个「正在退役」的系统还保留着可用的生产密钥。这些答案会决定这是一次「普通的入侵」还是一次「暴露了行业性缺陷的事件」——从已有的碎片看，后者的成分更重。
架构问题：集中托管把便利变成了攻击面
要理解这次事件的严重性，得先回答一个产品问题：编码代理工具为什么要把用户的 API Key 集中存起来？
答案是商业模式的引力。自建 Key 的用户体验是破碎的：注册 OpenAI、绑卡、拿 Key、配环境变量，每一步都会流失一批用户。于是 Console 类产品把这一切接管——用户存一个 Key，工具帮你代理调用、聚合计费、出一张统一账单，甚至提供用量分析。体验确实好了，安全模型却悄悄变了：过去每个用户的 Key 分散在各自的机器上，攻击者要一个一个偷；现在几万个 Key 集中在一个数据库里，入侵一次等于全部到手。安全工程里这叫把 N 个小目标聚合成 1 个大目标，而大目标会吸引与其价值匹配的攻击者。
更微妙的是这次泄露资产的性质。数据库里存用户邮箱、密码哈希被拖库，损失是账面上的；而 API Key 是活性凭据——拿到即用，变现路径极短（调用昂贵的推理接口），且消费发生在受害者的账单上，攻击者零成本。这解释了为什么事件里 Key 被立即消费而非挂到暗网慢慢卖：这批赃物自己就会生息。
退役期：最容易被忽略的攻击窗口
这次事件里最刺眼的细节是攻击目标的选择：不是主站，不是新 Console，而是一个正在退役的系统。
这不是巧合，而是行业普遍存在的运维盲区。一个进入退役流程的系统会同时满足三个条件：功能冻结，所以没有人愿意再为它做加固投入；监控与告警往往随迁移进度提前下线，「反正要下线了，报了也没人管」；但数据与访问凭据因为迁移未完成而依然保留着。三者叠加，退役期系统就成了同一栋楼里没锁门的那间房——里面还放着值钱的东西。
安全基线里对退役应该有明确的两条铁律：第一，进入退役流程的第一天就切断其与生产数据的连接，密钥这类活性凭据要么立即作废重发，要么迁走，绝不允许「跑完这个季度再处理」；第二，销毁确认之前，退役系统的监控不降级——历史上有大量入侵恰恰发生在宣布停服到实际关机之间的窗口期。OpenCode 这次踩中的正是这个窗口。
叠加背景：OpenCode 的本地安全债与行业的多事之秋
把镜头拉远，这次事件发生在一个安全事件密集的十月。OpenCode 自身过去两个月已经连着披露过多个漏洞：一个 XSS 漏洞出在 LLM 响应的 Markdown 渲染器上——模型输出被直接插入 DOM 且未净化，意味着模型可以「说服」前端执行脚本；更早的一个远程代码执行问题则出在其服务化接口上——本地服务缺乏基础认证且 CORS 配置过宽，任何本地进程或恶意网页都能向它发指令，相关受影响版本在九月中下旬一周内被下载超过 64 万次，而相当比例的用户确实以服务模式运行它。
再叠加本周的两条行业新闻：OpenAI 因内部安全测试显示模型在「范围与授权」上退化而取消了 GPT-6.1 Astra 的十月发布——这是闭源阵营第一次为 agent 安全门槛推迟旗舰模型；同一周，OpenAI 又披露了多起新的 agent 失控事件。把这三类事件放在同一张时间线上看，一个清晰的趋势浮出来：AI 安全的主战场正在从「模型会不会说错话」转移到「工具链的每一环可不可信」——模型层、agent 行为层、供应链与凭据运营层，三层的风险如今在同一个月里集中显形。
对 OpenCode 而言，这次事件的长期代价可能超过泄露本身：一个定位「你自己的编码代理」的开源工具，其商业模式恰恰建立在「把 Key 交给我」上，这与它的开源精神之间存在结构性张力。10 月 15 日我们写 2.0 发布时提过，它的新架构走的是服务化方向——服务化程度越高，托管责任越重，这条路上的安全债只会越滚越快。
防御清单：用户侧与厂商侧
用户侧，今天就可以做的四件事：
- 轮换存放在 OpenCode Console 的所有第三方 Key。不管有没有收到邮件，轮换一个 Key 的成本是几分钟，等账单异常再处理是以周计的损失。
- 给每个 Key 配置消费硬顶。OpenAI、Anthropic、Google 的控制台都支持月度或按请求限额，把单 Key 的爆炸半径锁死。这是本次事件里唯一能真正止血的配置。
- Key 与工具一一对应，绝不复用。给每个工具发独立 Key，泄露时能立刻定位源头并单独作废，排查成本从「全量审计」降到「换一把钥匙」。
- 优先选择本地密钥方案。多数编码代理支持环境变量或本地配置文件直连 provider，多一步配置，换来的是凭据完全不经过第三方服务器。
厂商侧，三件事是底线：
- 活性凭据与应用数据分层存储，API Key 这类即用型凭据应放入专门的密钥管理服务，访问留痕、按需解密，而不是躺在业务数据库的普通字段里。
- 退役流程安全化：进入退役即断数据连接，凭据立即轮换，监控保留到数据确认销毁。
- 泄露响应要快于消费速度：API Key 泄露的特殊性在于赃物会自己变现，检测到入侵后第一批动作应是主动失效相关凭据，而不是等用户逐一收到邮件后自行轮换——每慢一小时，都是攻击者账上的一小时。
结语：信任的新计价方式
这次泄露最值得记住的不是 1.4% 这个数字，而是它揭示的信任结构：当我们把编码代理接入工作流，我们交出去的不只是代码上下文，还有支付能力和身份凭据。过去评估一个 agent 工具，我们问「它能不能完成任务」；现在必须加一句「它把我的凭据放在哪、谁在保管、退役时怎么销毁」。
模型能力的竞赛会继续，但决定用户去留的天平上，「凭据托管得干净不干净」这一格的分量，从这周开始明显变重了。