OpenCode 泄密事件之后：创作者和小团队的 AI 密钥自托管清单

AI API 密钥安全这件事，过去一直被当成开发者才要操心的琐事，通常就写在某个 README 里。上周末，它变成了所有人的问题。2026 年 10 月 17 日，开源 AI 编程智能体 OpenCode 的团队宣布，其托管的 OpenCode Console 发生入侵，影响了一部分绑定了自有 AI 服务商密钥的用户。一夜之间，一些用户眼睁睁看着自己的 OpenAI、Anthropic、Google 用量直线上升。

我看着 OpenAI、Anthropic 和 Google AI 的扣费提醒一条接一条弹出来，带着这个疑问睡着了：到底发生了什么。

一位受影响的开发者，TechCrunch 报道

我想先把结论摆在前面：这篇文章想讲清楚发生了什么、还有哪些仍不明确，以及一份把掌控权拿回自己手里的清单。

把真正重要的密钥、数据、模型和提示词资产，放在你自己能掌控的地方。给每个工具单独、有限额的密钥。设好硬性消费上限。假设任何存在别处的密钥副本，都有可能泄露。

OpenCode Console 这次入侵，到底发生了什么

下面只列多家媒体共同报道或公司官方声明确认过的内容。截至 10 月 21 日，OpenCode 表示事件仍在调查中，细节可能还会变化。

已确认的信息（公司声明，经 TechCrunch 和 BleepingComputer 报道）：OpenCode 表示「昨晚发生了一起与大规模蒸馏攻击相关的安全入侵事件，影响了 1.4% 的 OpenCode Console 用户」，只有绑定过外部服务商密钥的用户受影响，并通过邮件收到了通知。据 TechCrunch 报道，攻击者「侵入了一套较旧的系统」；据 BleepingComputer 报道，OpenCode 发给受影响用户的邮件给出的最早可能泄露时间是 2026 年 10 月 17 日 00:30（UTC），并表示没有发现其他数据被泄露的迹象。泄露的密钥仅限于 Console——部分用户把密钥保存在了这里的工作区里。联合创始人 Dax Raad 写道，开源应用和命令行工具本身并未受到影响：「要说明的是，这是 OpenCode Console，不是 OpenCode 本身，那些密钥从来不会发到我们这里。」Anthropic 和 Google 封锁了它们认为已经泄露的 API 密钥；OpenAI 表示已与 OpenCode 协作恢复访问，并为受攻击影响而消耗的额度向 API 客户退款；OpenCode 也表示正在处理未授权扣费的退款。OpenCode 已要求受影响用户直接向各服务商撤销并更换密钥，但尚未披露攻击者具体是如何进入系统的，也没有说明密钥当初是如何存储的。

用户报告但尚未经 OpenCode 证实的信息：据 BleepingComputer 援引的用户报告，未授权扣费从数百美元到约 1700 美元不等；TechCrunch 也报道「有几位提到的总额超过 1000 美元」；一些用户表示 Google 在检测到「与被劫持资源相符的滥用活动」后，暂停了他们的云项目。

仍不清楚的部分：攻击者究竟如何进入那套旧系统、密钥当初是怎么存储的、泄露窗口什么时候结束，以及这里说的「蒸馏攻击」具体指什么（蒸馏本身是用大模型的输出训练小模型的合法方法，一旦有人靠窃取的访问权限大规模这么做，就变成了滥用）。TechCrunch 也提到，有质疑者认为「蒸馏」这个说法有点牵强。

什么是 API 密钥，为什么一旦泄露代价这么高

API 密钥是一长串让软件可以用你的账号调用 AI 服务的秘密字符串。如果你曾经把一个密钥贴进某个应用的设置里，让它「用你自己的 OpenAI 账号」，那你其实就是把一把密钥交了出去。最简单的理解方式：API 密钥就是一张没有密码的预付卡号，谁拿到它，谁就能以脚本能跑多快的速度花掉你的额度。OpenAI 自己的说明写得很直白：密钥一旦泄露，就会让人「在你不知情的情况下访问你的账号额度」，可能导致「数据丢失、意外扣费、月度额度被耗尽，以及 API 访问中断」。

AI 密钥比很多其他凭证更伤人，原因有三：用量是按量计费又跑得很快的，自动化滥用几个小时就能烧光余额；滥用本身对攻击者可能有价值——大量模型输出，对那些想拿去训练别的模型的人来说是值钱的，这也是这里「蒸馏」说法的一种解读；一把密钥往往到处都在用，如果你在五个工具里用了同一把密钥，任何一个工具泄露，五个都暴露了。

这到底是黑客问题，还是自托管问题

两者都是，但只有一个是你能改变的。你没法阻止一个有决心的攻击者去攻击某个平台，你能控制的，是有多少平台握着你的密钥、每把密钥能做多少事。

注意这个细节：OpenCode 应用本身的本地密钥「从来不会发到我们这里」。把密钥存在本地配置里的用户，根本不在这次事件的受影响范围内；把密钥保存进托管工作区的用户，则受到了影响。同一个产品，同一家公司，结果却取决于密钥存在哪里。

每一份存在别人服务器上的密钥副本，都是你没法保护的一份副本。

这里也要公平一点：托管控制台的存在是有道理的——跨设备同步、团队共享、不用折腾配置文件。自托管也有自己的失败模式，下文会提到。但便利是有代价的，只是平时很容易被忘掉，直到半夜扣费提醒响起来才会想起。

AI 资产自托管清单

我把这份清单拆成四块：密钥、数据、模型，以及提示词与创作资产。你不会每一条都用得上，先全部过一遍，打上勾，一个月后再回来检查一次。

第一块：密钥

列出所有持有你密钥的地方，包括桌面应用、浏览器插件、托管控制台、自动化工具和早已忘记的旧项目——大多数人列完会发现比想象中多得多。每个工具、每个人用一把独立密钥：OpenAI 的指南建议团队每个成员使用唯一密钥，并明确指出共享密钥违反服务条款，分开的密钥意味着一旦某把泄露，你能准确知道该掐断哪一把。设置硬性消费上限，而不只是提醒：OpenAI 帮助中心写得很明确，要设置月度消费上限并「启用硬性强制执行」，因为「光靠提醒并不能阻止 API 流量」，在每个支持这项功能的服务商那里都照做一遍。给密钥设定有效期并养成轮换的习惯：OpenAI 建议密钥要有过期时间并定期轮换，OWASP 的密钥管理指南也给出同样更通用的建议——定期轮换，「这样即便凭证被盗，有效期也只有很短一段时间」。密钥永远不要放进浏览器、移动应用或代码仓库，按照 OpenAI 的说法，这三个都是密钥泄露的常见途径。优先用密码管理器或密钥管理服务，而不是明文文件：OpenAI 建议用环境变量或密钥管理服务，对于容器和服务器，OWASP 提醒环境变量可能最终出现在日志和内存转储里，这种场景下专门的密钥管理服务更合适。只有真正需要的时候，才把密钥贴进某个托管服务，如果要贴，就用一把专门为这个场景生成的、权限受限的新密钥。清掉不再用的密钥：二月试用过的那个工具，不需要继续留着一把有效密钥。

第二块：数据

摸清楚哪些工具能看到你的提示词、文件和输出结果，其中又有哪些把这些内容存在自己的服务器上；检查保留设置，历史记录保留多久，能不能关掉；把真正敏感的材料（客户合同、未发布的素材、财务数据）保存在你能掌控的存储里，只有任务真正需要的时候才放到云端；确保自己能把数据导出——如果你没法把数据取出来，就谈不上真正拥有它。

第三块：模型

不需要前沿云端模型的任务尽量本地跑——每多一个任务在自己硬件上完成，就少一把密钥在使用、少一份数据流落在外面；弄清楚哪些工作流完全依赖单一服务商，一旦这家像这次事件里的 Anthropic 和 Google 一样封锁了你的密钥，会有什么停摆；保留随时换模型的能力，不用为此重建整套系统。

第四块：提示词与创作资产

把系统提示词、模板和风格指南存在你能掌控的地方，最好纳入版本管理，而不只是存在某个平台的文本框里；把 AI 分身和常驻角色当成身份和知识产权来对待，把它们的源素材（参考图、声音样本、性格设定）保存在你拥有的地方；把分镜和项目文件备份在任何单一 AI 工具之外。

如果怀疑密钥已经泄露，该怎么做

速度比完美更重要。下面的顺序参考了 OWASP 的事件响应指南（撤销、轮换、删除、记录），并针对 AI 密钥做了调整：先在服务商那里撤销密钥，这一步要在你开始调查之前就做；创建新密钥，只更新真正需要它的工具，尽量按服务商允许的最小权限范围配置；把旧密钥从所有存过它的地方删掉，包括配置文件、笔记和旧项目；从最早可能泄露的时间点开始，检查各个服务商的用量和账单，留意异常的峰值、陌生的模型或不寻常的使用时段；如果发现未授权扣费，联系服务商客服——这次事件里 OpenAI 为受影响的 API 客户做了退款，但不要假设所有服务商都会自动退款；警惕后续的钓鱼邮件，泄露事件之后经常会出现仿冒的「验证你的密钥」邮件，不要把密钥粘贴进任何表单或回复邮件；把经过记下来，哪把密钥、存在哪里、什么时候轮换的——下一次你会更快。

为什么 AI 创作者格外容易中招

开发者这些年受过不少密钥安全方面的警告，而创作者和小型市场团队大多没有，他们的工作环境通常也长得不一样。一条典型的 AI 视频或内容工作流，是一长串彼此独立的工具：脚本一个、图片一个、配音一个、视频一个、字幕一个，再加一个排期工具。越来越多工具提供「用你自己的密钥」这个选项，因为这对工具方更便宜，往往对你也更便宜。每一个这样的工具，都是你密钥多存一个地方的理由。

围绕这件事的配套措施也更少。一个开发者可能有密钥管理服务，也有轮换的习惯；一个自由剪辑师的密钥，更可能存在某个笔记应用里，贴给了最近用到的那个工具。这不是在批评谁，这就是快节奏创作工作的常态。但这也意味着，上面那份自托管清单，对一支五人内容团队的重要性，很可能超过对一个有安全部门的大型工程团队。

如果只有十分钟，先把硬性上限设好。单这一步，就能限制住像 10 月 17 日那样的夜晚最坏能糟到什么地步。

这份清单对谁最重要

下面三个场景同样是虚构的组合案例，不是真实客户。

场景（虚构）：密钥散落在五个工具里的自由视频创作者。山姆在一个脚本写作应用、一个字幕插件、一个缩略图生成器、一个托管视频平台和一个旧的自动化流程里，都用着同一把 OpenAI 密钥。泄露新闻一出来，他根本分不清这五个里哪个可能受影响，只能在一个赶工的日子里，轮换密钥的同时让五个工具一起断掉。如果每个工具各用一把密钥，他本可以只轮换一把，其余照常工作。

场景（虚构）：共用一把密钥的四人工作室。工作室里所有人都在用同一把 Anthropic 密钥，存在一份共享文档里，没人说得清是谁把它加进了哪个工具。账单一旦暴涨，根本没法追溯源头。如果每人一把密钥、再加上硬性月度上限，一桩谜案本可以五分钟解决。

场景（虚构）：独自处理客户合同的创始人。安娜用 AI 审核供应商合同，她担心的不只是账单，还有合同本身一直存在某个托管工具的历史记录里。把合同审查换成本地模型，云端只用来做一般性的市场调研，就能把最敏感的数据彻底挪出风险范围。

自托管有什么代价

如果只写「把一切都放本地」就收尾，会显得很有误导性。你自己的笔记本电脑也可能泄露——存在一台被盗或被入侵机器上的明文密钥，照样是泄露的密钥，记得加密硬盘、用好密码管理器；你自己会变成安全团队——轮换、备份、更新都成了你的工作，如果没人负责，它们就不会发生；本地模型并不总是够用——有些任务仍然需要前沿云端模型，自托管的意义是选择什么时候用它们，而不是拒绝使用；托管工具也可以做得很好——有些平台在保护存储密钥上投入巨大，重点不是托管一定不好，而是每多一份副本，就多一份你看不到的风险。

KarmaBox 在这件事上扮演什么角色

再说明一次利益相关：这是我所在的公司，请带着这一点读下面的内容。KarmaBox 是围绕 AI 分身搭建的主权 AI 工作空间，它的设计和上面清单里的好几条都吻合。按官网的说法：数据（文件、记忆、知识库）「留在你的设备或私有云上」；模型「带着自己的模型来，或者跑在本地 GPU 上」，换模型不影响分身；权限边界方面，发消息、发布内容、花钱、删除这些动作都需要你点头，并且这条规则「在服务端强制执行，而不是靠提示词约束」。

此外，KarmaBox 可以本地跑视频模型，包括转绘和智能生成；它提供主权 AI 分身，让你的 AI 身份始终属于你；云端还是本地永远由你选择。它的本地主权模式目前重点覆盖工作与视频两类场景。我不会去宣称任何工具——包括 KarmaBox 在内——能让你完全免疫入侵。一个你能掌控的工作空间，能减少持有你密钥和数据的地方数量，但清单本身，还是得你自己去用。

常见问题

问：OpenCode Console 这次入侵到底发生了什么？

答：OpenCode 表示，2026 年 10 月 16 日到 17 日夜间发生的一次入侵，影响了绑定过外部 AI 服务商密钥的 1.4% OpenCode Console 用户。泄露的密钥被用于未授权消费，相关服务商封锁了密钥，OpenAI 为受影响的 API 客户做了退款，OpenCode 也表示退款正在处理中。

问：OpenCode 应用本身受影响了吗？

据联合创始人 Dax Raad 所说，没有。泄露范围仅限于托管的 Console，本地使用开源应用时用到的密钥「从来不会发到我们这里」。

问：受影响的用户损失了多少钱？

答：OpenCode 尚未公布具体数字。BleepingComputer 援引的用户报告显示，损失从几百美元到约 1700 美元不等。

问：保护 AI API 密钥最有效的一步是什么？

答：在服务商那里设置硬性消费上限。正如 OpenAI 指出的，光靠提醒拦不住流量。在此之后，再给每个工具分配独立的密钥。

写在最后

OpenCode Console 这次事件，大概会因为「蒸馏攻击」这个说法而被人记住。但我觉得更有用的教训，藏在一个更小的细节里：留在本地的密钥，一个都没被动过。

你没法决定谁会去攻击一个平台，但你可以决定有多少平台握着你的密钥、每把密钥能花多少钱、以及你能多快把它掐断。

密钥留在本地的那些人，这次什么都没发生。