先把恐慌的边界说清：不是"全军覆没"，但习惯本身被判了刑
10月17日开始的这几天，“GPT、Claude余额一夜清空"的截图在AI编程圈刷屏。但把OpenCode官方声明、创始人Dax Raad的原话和几家安全媒体的报道交叉看一遍，受影响的边界其实很清楚：被入侵的是云端托管的OpenCode Console（工作区面板），受影响的是在Console里存了第三方API Key的约1.4%用户；本地命令行里用 /connect 配的Key，按官方口径没有上服务器。 所以别急着喊"OpenCode完了”，也别急着松口气。这次真正被推上审判席的，不是某个工具，而是"为了方便把API Key交给第三方托管面板"这个习惯本身——黑客拿走的不是你的密码，是你的账单凭证。知乎
被盗的不是密码，是"谁拿着都能用"的账单
API Key和密码是两种东西。密码证明"你是你"，而Key是Bearer Credential（持票人凭证）：谁拿着都能用，不需要登录。这就是为什么事件爆发后"改密码"的攻略全是错的——密码改了没用，Key不吊销，钱就继续烧。
更坑的是计费延迟。云厂商的用量进账单通常有数小时到24-48小时滞后，从Key泄露到被发现的这段时间里，攻击者的调用已经进了计费流水线，删Key也抹不掉，能做的只是"别再烧下去"。 有用户一觉醒来，面对的就是单日超过1700美元的巨额账单。 需要说明：这些盗刷金额多为受害者自述，OpenCode官方没有逐条确认，但方向没有错。知乎36氪
还有个99%的人第一反应搞错的点：Console里设的预算上限，管不住被盗Key的直连调用。Console只看得见经过它网关的请求，黑客拿着Key直接怼厂商官网API，预算面板根本看不到。 这不是OpenCode一家的账单事故。今年3月，一位独立开发者只是开了个测试开关，异常消费就从40美元一路飙到15400美元，而Google账单面板的更新比实际调用晚了约30小时。 事件里的Google Cloud控制台页面也印证了同一条链路：不受限的密钥会被原厂直接标注成额度盗刷风险。无限制密钥+计费滞后，是AI账单时代的组合雷，这次只是雷埋在了聚合托管面板里。知乎36氪
被攻破的还是什么系统？官方自己说了：一台"正准备退役（decommission）的旧服务器"。安全圈老规律——准备下线的机器最没人管，黑客挑的就是这个窗口。36氪
最魔幻的一幕：帮防守方查入侵的AI，中途拒答了
这次事件里社区吵得最凶的，不是Key被盗本身，而是一个新问题：团队在遭遇连续48小时攻击、拿前沿模型帮忙分析入侵过程时，模型"一开始帮了很多，后来开始拒答"——要分析的恶意代码触发了模型的安全过滤。 知乎上围绕这件事的热问下基本分成三派：护栏太死，成了防守方的绊脚石；护栏没出错，它本来就分不清你是谁，分不清的时候宁可拒答；以及微软给出的那句更重的判断——“前沿模型不可信”。 把争议放回数据里看，不对称是真实存在的：攻击者可以用开源模型、无审查模型和倒卖API的灰产干活，防守方用的却是带护栏的商业模型。IBM和Ponemon刚发布的2026年数据泄露成本报告给出了整体底色：AI驱动攻击同比增加56%，超过四分之一的恶意攻击由AI驱动，其中深度伪造冒充占45%、AI生成恶意软件占19%；AI驱动的攻击每次泄露平均多损失100万美元。 报告的总结一句话很扎眼：攻击者正在从"人类速度"转向"机器速度"。防守端反而在护栏上多了一道看不见的摩擦成本，这是行业刚开始面对的问题。知乎36氪知乎
这不是OpenCode一家的事故：凭证集中，就是攻击面集中
为什么盯上Console？因为它"一把钥匙开三家模型"——OpenAI、Anthropic、Google（Gemini）的Key集中在一个托管面板里，撬开一个旧系统，就能拿到成百上千把真实开发者的Key，烧的全是别人的额度。
把镜头拉远，这类风险正在整个AI使用链条上放大。同一份2026年报告里还有几个数字：影子AI（员工绕过管控私自用AI工具）在泄露事件中的占比从20%翻倍到43%。 92%发生AI相关泄露的组织缺乏适当的AI访问控制；勒索软件连续四年上升，已是39%的泄露事件的成因。最近B站和知乎上"ERP被加密停产十多天""备份盘和主数据一起被锁"的讨论，说的就是这39%的另一半故事。知乎
所以下次看到"一键连接你的Claude/OpenAI账号"这种按钮，先停三秒再点。一个不太准确但够用的类比：AI时代，API Key就是你的信用卡CVV——不需要密码，抄走就能刷。
如果你可能存过Key：按顺序做这七步
处置动作别只停留在"删配置"——不管在Console还是原厂后台，真正的动作都发生在密钥管理页：显式地新增一把、把旧的那把删掉或吊销，删了配置不等于吊销。
手输网址登录原厂后台吊销Key，别点邮件里的"一键处理"链接——事件发酵期正是钓鱼链接的高发期；
生成新Key，旧Key显式Revoke：只在OpenCode里删掉配置不等于吊销，要在服务商侧看到旧Key状态变为无效才算；
回查10月16日以来的调用曲线：OpenAI、Anthropic、Gemini三家的用量页都翻一遍；
开消费上限+异常告警，关掉自动充值；
同步替换所有用到旧Key的地方：本地脚本、CI配置、别人转过的代码里只要旧Key还活着，就可能被"你自己"调用，混淆排查；
同一个Key既在本地用过又粘进过Console的，本地那份一起换；
截图保留异常用量、扣费时间和通知邮件，尽快找服务商申诉：退款不是必然的，但报得越快越好——Anthropic已强制注销疑似泄露的Claude Key，OpenAI也表示会协助处理异常额度。知乎
往后怎么和"托管便利"相处：按人群给结论
个人开发者：主Key永远不进第三方，每个工具开一把专用子Key——Cursor一把、OpenCode一把、本地脚本一把。哪个漏了，爆炸半径只有一把。每把Key手动压限额到日常用量2倍，别开无上限。
小团队：共享托管面板确实省了对齐Key的成本，但先回答"漏了谁买单"。Console预算上限管不住直连调用这条机制，意味着团队面板的风险敞口比面板上显示的大。
企业员工：把内部文档、客户资料直接粘进公共AI工具，就是43%那个数字的来源。你交给AI的每一份文件，都按"外面存在第二份"来评估。
值得继续盯三个信号。第一，OpenCode是否公开具体入侵路径和确认泄露的Key数量——官方至今没有公布具体人数、入侵路径和密钥是否全部被滥用，用户只能靠服务商后台的用量曲线反推自己有没有被用狠。 第二，被盗刷账单的退款政策最终收紧还是松掉。第三，"防守方拒答"这类护栏不对称问题，会不会逼出厂商侧的应急响应豁免机制。知乎
这次事件的学费是1.4%的用户交的，但被点名的是所有人的习惯。在"AI替你干活"变成日常之前，先确认你的Key没有替别人花钱。
