API Key 泄露后的 30 分钟应急清单

为什么先讲处置顺序

Key 泄露的处置有三个动作：禁用、核查、更换。

顺序错了会付出代价：

• 先核查后禁用 → 核查期间对方还在刷你的额度；
• 先更换不核查 → 你已经换了，但日志没拉，事后无法判断泄露规模与路径，也不知道要不要再加固别的地方；
• 只禁用不更换 → 如果泄露路径没堵住，新 Key 会以同样方式泄露。

正确顺序：禁用 → 核查 → 更换 → 加固。

三十分钟清单

第 0–2 分钟：禁用

立刻在站方后台禁用该 Key（如果它支持临时禁用而不是删除，用禁用 —— 这样日志还留着）。

如果站方没有禁用功能，直接删除。

同时：如果你的代码里有环境变量引用它，先不管 —— 代码会报错，但那比继续扣费好。止血优先。

第 2–10 分钟：核查规模

拉调用日志，看三件事：

1. 时间范围：异常调用从什么时候开始；
2. 调用特征：请求的模型、prompt 长度、调用频率；
3. 来源 IP（如果日志里有）。

判据：

• 调用特征与你自己的模式完全不同（比如大量长 prompt、深夜高频）→ 确认是被盗用；
• 调用量在短时间内陡增 → 典型的脚本刷取；
• 只多出零星的、看起来像探测的调用 → 可能只是被扫描到，尚未被利用。

把日志导出保存，这是后续追索或申诉的唯一依据。

第 10–15 分钟：更换

生成新 Key，更新所有引用处。

注意：不要"暂时先用旧 Key"，也不要"先复制一份再删"。

更新引用的地方要列清单（这一步最容易漏）：

□ 生产环境的环境变量
□ 测试环境的环境变量
□ 本地开发环境（.env、IDE 配置）
□ CI/CD 的 secrets
□ 容器编排的 secret 配置
□ 第三方平台（监控、日志、Serverless 函数）
□ 客户端工具（Cursor、Cherry Studio、Claude Code 配置等）
□ 定时任务脚本
□ 文档、笔记（很多泄露就是从这来的）

最后一项值得单独强调：在聊天记录、协作文档、README、代码注释里硬编码的 Key，是泄露最常见的来源之一。

第 15–25 分钟：排查泄露路径

按常见程度排查：

1. 前端代码：Key 是否被打包进了浏览器端 JS？（只要能看到它，就等于公开）
2. Git 提交历史：是否曾经提交过 Key 后再删除？（历史里还在）
3. 公开仓库：如果是公开仓库，爬虫扫 Key 的速度是分钟级；
4. 截图与录屏：演示时把 Key 露出来了；
5. 第三方工具：某些工具会把配置上传或同步到云端。

Git 历史这一步最容易被忽略：删除文件不会删除历史。要彻底处理需要重写历史，或者（更省事的做法）这个 Key 已经作废了，重写历史的意义只在于防止其他 Key 也被扫到。

第 25–30 分钟：加固

• 给新 Key 设额度上限（止损的最后一道防线）；
• 加 IP 白名单（如果固定出口 IP）；
• 把 Key 从代码移到环境变量 / 密钥管理；
• 加调用量告警（超过基线 2 倍就通知）。

三个最常见的泄露路径

按实际发生频率：

1. 提交到公开仓库。爬虫扫描公开仓库的速度是分钟级，密钥可能在提交后 1–2 分钟就被尝试使用。
2. 写进前端代码。只要在浏览器里能看到，就不算秘密。
3. 留在文档 / 聊天记录 / 截图里。这一条发生频率很高但往往不被当成泄露。

事前的三道防线（比应急更重要）

一、Key 分离

不同用途用不同 Key：生产、测试、本地、CI。这样单个 Key 泄露的影响面被限制在一个用途内。

二、最小权限

• 给每个 Key 设额度上限（最重要，它是唯一能在事后自动止损的手段）；
• 加 IP 白名单（固定出口 IP 的场景）；
• 如果站方支持，限制可用模型（把某个 Key 限定在它实际需要的模型上）。

三、不入库、不入前端

• 任何情况下不把 Key 写进代码、提交、截图；
• 前端一律通过自己的后端代理，不能直连模型 API。

一个现实的提醒

绝大多数泄露的 Key，都是使用者自己放出去的，而不是被"攻破"的。所以在讨论密钥管理时，重点不是加密算法，而是流程：

• 有没有把 Key 放进代码的习惯；
• 有没有在提交前检查；
• 有没有把 Key 分用途。

这三件事做到了，泄露概率会下降一个数量级。剩下的，靠额度上限兜底。