OpenCode 是开源 AI 编程代理；它的在线 Console 可以代团队保存外部模型供应商的 API 密钥。官方在 2026-10-17 UTC 的事件公告中称，一次安全事件影响了 1.4% 的 Console 用户，也就是其中在 Console 存过外部供应商密钥的那部分人，官方已发邮件通知；公告还称未收到邮件即未受影响。别把这个范围读成“装了 OpenCode 就泄露了密钥”。
如果 Console 里存过外部供应商的密钥，就得去签发该密钥的模型供应商后台撤销。在 Console 里删连接、卸载客户端、调低预算，都拦不住已经复制出去的那份密钥。
先撤销还是先建好替代密钥再撤，看有没有确认陌生调用；还没确认，再看停服能不能接受。
如果你只是 Console 密钥过期、或者工作区被限制，那属于另一类问题：光看报错说明不了外部密钥已经泄露。
拿不准密钥归属、没有撤销权限，或者换了新密钥还有陌生调用，就先别恢复自动任务，找工作区管理员。
先分清：外部密钥泄露，还是 Console 连接失效
先看这把密钥存在哪里、由谁签发，别从错误码倒推。官方公告覆盖的是曾存进 Console、且由外部供应商签发的那批密钥。Go 密钥失效和工作区受限属于另外两类问题，官方没说它们和这次事件是什么关系，处置方式也不同。
OpenCode 联合创始人 Dax Raad 把 Console 和 OpenCode 本身分得很清：出事的是在线 Console。你只在本机接供应商，不等于把密钥存进过在线工作区。
| 你能确认的情况 | 先做什么 | 常见误判 |
|---|---|---|
| 对应密钥已有陌生调用（无论是否收到通知） | 立即在供应商后台撤销该密钥并记录时间，再排查账单 | 删掉 Console 连接后，供应商那边的密钥照样能用 |
| 收到风险通知，但还没发现陌生调用 | 停服代价大就先建替代密钥、验证通过后再删旧密钥；停服代价小就直接撤销 | 通知本身就是要你换密钥的信号，等到看见异常已经晚了 |
| 密钥在你操作前就已失效，供应商侧显示已被停用或删除 | 先在供应商后台确认密钥状态，再按该供应商指引决定保留还是补删；同时核对用量 | 没人动过也会批量失效，先去供应商侧看状态 |
| 曾在 Console 保存外部密钥，但没收到通知 | 核对工作区、通知邮箱和供应商用量；无法排除暴露时按疑似泄露处置 | 用过 Console 不等于被选中，要看供应商侧有没有异常调用 |
| 只在本机直接接入供应商，未上传同一密钥到 Console | 核对实际连接路径；有独立异常时另查原因 | 本机密钥没进过 Console，就不在这次的范围里 |
只持有 OpenCode Go（$10/月模型订阅）或 Console 签发的密钥，出现 api_key_expired |
检查 Console 账号状态，向支持渠道说明错误与发生时间 | 这是 Console 自己签发的密钥，跟外部供应商无关 |
工作区显示 Workspace access restricted |
由所有者联系支持，保存报错与时间 | 受限可能只是风控，先看支持怎么回 |
部分密钥可能在你操作之前就已被供应商停用。TechCrunch 在 2026-10-19 的报道中称，Anthropic 和 Google 停用了它们认定已暴露的密钥；OpenAI 表示已与 OpenCode 协作恢复访问，并退还了攻击消耗的额度。
这些是媒体转述的厂商动作，你的账号实际状态仍以供应商后台和支持回复为准。
Go 密钥失效和工作区受限这两类故障都有用户原始报告。GitHub #56833的提交者称，自己没有关联外部供应商，但 Go 密钥失效；#56703记录了工作区受限，提交者明确说自己没收到泄露通知邮件。这些都是 2026-10-18 起的个案，和公告那句“未收到邮件即未受影响”并存，官方也没解释两者怎么对上。个案算不出整体范围。
仓库中的支持回复要求账号问题发往 [email protected]，不要在公开 issue 中贴账号或支付资料。
撤销或替换旧密钥，再清理 Console 连接
先核对供应商、组织／项目、密钥名称和末尾那几个可见字符，别删错生产凭据。这把密钥生产环境也在用的，马上叫上服务负责人一起停用和替换。已经确认有陌生调用，就别为了切换平滑继续留着它可用。
已经看到盗刷、一时又找不到撤销入口，先去供应商侧把支出上限压到当前用量附近。Console 的预算管不住绕过网关的调用，供应商那边能管住。
OpenAI 和 Anthropic 的上限会真的把调用停掉：OpenAI 的 hard spend limit 到额度就停止受影响流量（生产实践），Anthropic 把 spend limits 直接列为「针对泄露密钥的保护措施」（官方说明）。
Gemini 那边对应的 Cloud 计费告警只发通知，不会停止调用（密钥文档），挡不住正在发生的盗刷，只能直接撤销。
上限只是临时止血，撤销这一步省不掉。
下表是 2026-10-20 核对官方文档后，Console 目录里最常见三家的处理入口。这个目录还支持 xAI、DeepSeek、Mistral、Groq、OpenRouter，以及 Azure、AWS Bedrock、Google Vertex AI、Cloudflare AI Gateway、Databricks 和自定义供应商（Console Providers 文档）。
这些也在各自后台的 API keys 页面撤销，按钮位置不一样，找的东西一样。
| 密钥签发方 | 官方处理入口与动作 | 做完后记录什么 |
|---|---|---|
| OpenAI | 按官方安全指引，进入 Platform 的 Security settings 撤销疑似泄露密钥，再创建替代密钥 | 所属项目、旧密钥标识、撤销时间 |
| Anthropic | 按官方密钥安全说明，登录后进入 platform.claude.com/settings/keys（API keys 页），点对应密钥旁的菜单，选择 Delete API key |
所属工作区、删除时间；随后检查 Logs 与 Usage |
| Google Gemini API | 先按Gemini 密钥文档确认关联的 Google Cloud 项目，在 AI Studio 的 API Keys 页创建替代密钥；确认可用后，到 Cloud console 的 APIs & Services > Credentials 停用或删除旧密钥 |
项目与密钥 ID，避免混淆不同项目中的同名密钥 |
Google Cloud 的删除会把密钥标记为 DELETED，30 天内可用 UndeleteKey 恢复（Cloud 密钥文档）。
三家官方文档写的顺序不一样。Google 的泄露处置清单是先建新密钥、更新应用，确认能用了再禁用或删除旧密钥，理由是避免应用停服。OpenAI 的安全指引和 Anthropic 的说明都是尽快撤销再替换，没提先验证替代密钥。
Google 那条的前提是不想停服。要是已经在被盗刷、停一会儿也扛得住，先撤销反而更划算——但这个取舍得由工作区负责人拍板。
没权限就找管理员，让对方执行撤销、回传状态和时间。别把完整密钥发给同事、客服或 AI 对话，记密钥 ID 或末尾几个字符就够。
Console 的 Providers 页只有所有者和管理员打得开，普通成员跑完 /connect 只看到已启用的模型（Providers 文档）。找不到入口是正常的，不是你配置错了。
供应商那边撤完，再回来处理 Console 里的旧连接。Console Providers 文档把 Disable 和 Remove 分开了：前者只是把供应商和模型藏起来，设置还在；后者连连接带模型一起删掉。
这两个动作管的是 Console 这一侧。旧密钥还能不能用，只看供应商那边的状态。
查账以供应商用量为准，Console 记录只作对照
被复制出去的密钥能绕开 Console 直接用。所以 Console 里没有对应请求，也不代表没人花你的钱；查账要去供应商那边查，Console 上的余额和预算不算止损结果。
钱只是一部分。Gemini 的密钥文档写得很清楚：密钥泄露后，别人能烧掉项目的配额、刷出意外账单，还能访问私有资源。配额被刷爆，你自己的服务先挂。
2026-05-28 起在 AI Studio 新建的密钥默认是绑定服务账号的 auth key，默认只限 Gemini API，但能碰什么还是看那个服务账号的权限。查用量时把这三样一起看。
按 Console 官方文档，自带供应商的调用由供应商计费，Console 只是按你配置的价格记一笔成本。预算文档里那些限额只约束走 Console 的请求，绕过网关直接打供应商的调用它管不到。
按以下顺序整理证据，不必先等到能算出全部损失：
- 存好通知邮件，把里面给的风险时间窗记下来。时间统一用 UTC，或者每条都标清时区。邮件没写起点，就从最近一次确认正常的用量往回排——官方公告是 2026-10-17 UTC、TechCrunch 报道是 2026-10-19，这两个日期都不是你账号的暴露起点。
- 在各供应商后台查看对应项目／工作区的用量，比较模型、调用时段、请求量和费用变化；后台无法按单个密钥区分时，标记这一限制，向管理员或供应商申请进一步核对。
- 对照团队任务日志、定时任务与其他共用该密钥的应用，列出无法解释的调用。标注“待确认”，不要把所有高峰自动算成攻击费用。
- 保存用量导出或经过脱敏的截图，向供应商与 OpenCode 分别提交各自需要处理的账单或账号问题。是否退款、覆盖哪些费用，以针对该账号的正式回复为准。
可以复制下面的示意记录模板；不要填写完整密钥或支付卡资料：
供应商 / 项目 / 工作区：
旧密钥 ID 或末尾字符：
通知中的风险时间窗及其时区：
撤销或停用旧密钥的时间（UTC）：
无法解释的调用时段、模型与费用：
配额或限流是否异常、私有资源是否被访问：
已排除的合法任务：
用量文件或脱敏截图位置：
支持工单编号 / 负责人 / 下次复查时间：
恢复连接前，先决定新密钥由谁保管
旧密钥停用或撤销后就能恢复业务了，但新密钥能用，不等于这次事件已经结束。OpenCode 在 2026-10-17 UTC 的事件帖里说事情还在处理；状态页只管服务能不能连，2026-10-20 看是 All systems operational。状态页绿了，不等于通报已经收尾。
继不继续把外部凭据托管在 Console，由工作区负责人看后续通报和团队要求来定。
团队不点头继续托管外部密钥，就把 Console 里对应的连接保持停用。同意直接接供应商的，按你所用 OpenCode 版本的官方配置来；只给本机用的新密钥，别再传回那条还没查清的在线路径。本机接入也不等于风险清零，本机的权限和凭据照样要管。
团队批准恢复 Console 的，所有者或管理员按Providers 官方流程把连接里的凭据换掉，成员再跑 /connect 选工作区、用 /models 看模型能不能用。
换之前先看清是哪个工作区、哪个供应商，别连回那条还在用旧密钥的配置。
先拿一个不含敏感数据的小任务试通授权调用，再放开定时和批量任务。同时看三样：新密钥归谁、供应商那边有没有新增用量、日志里还有没有旧凭据的鉴权错误。陌生调用一直有，就停下来继续查；只是工作区受限，交给账号支持，别靠反复新建密钥碰运气。
要重新安排订阅、Coding Plan 和 API 的账单归属，可以看AI 编程产品计费方式对照。不过换套餐是换套餐，旧凭据该撤还得撤。
什么时候可以结束本轮处置
旧凭据撤了或停了、受影响的应用都换过、异常用量也有人接手，这一轮才算完。退款和账号恢复没结清的，工单继续挂着。
- 涉及的供应商和项目都列全了，每个旧密钥的状态和停用时间能复查。
- 用过这把密钥的应用都换过了，没有靠恢复旧密钥来「修好」故障。
- 用量对着供应商记录核过，说不清的费用和数据可见性限制都写下来了。
- 配额、限流和私有资源访问单独看过，不只看金额。
- 新凭据放在哪、谁在用、怎么恢复，负责人点头了。
- 还受限的工作区、还在冒的陌生调用、没结的费用，各自有工单和负责人。