API Key 泄露后怎么办？10 分钟止损、1 小时排查和长期预防

API Key 一旦出现在公开仓库、截图、日志、聊天记录、浏览器前端代码或第三方工单里，就应该按泄露处理。不要等到账户余额异常下降后再行动，因为自动化脚本可能在几分钟内开始消耗额度。

前 10 分钟：先止损

• 立即停用或删除疑似泄露的 Key。
• 如果不确定是哪一个 Key，先降低相关 Key 的限额。
• 暂停可疑项目、定时任务、Agent 或 CI 流水线。
• 保存泄露位置截图、时间和相关提交记录，后续排查会用到。

接下来 1 小时：确认影响范围

• 查看泄露前后几个小时的调用记录。
• 按 Key、模型、时间段、请求量和费用排序。
• 确认是否出现陌生模型、异常请求量或非工作时间调用。
• 检查 Git 历史、CI 变量、部署平台、日志系统和共享文档。
• 如无法判断影响范围，联系 控制台的“支持与反馈”入口 并提供账户邮箱、Key 备注、异常时间段和订单信息。

轮换 Key 的顺序

• 先创建新 Key，并写清项目、环境和负责人备注。
• 只替换后端服务、CI 或服务器环境变量，不要写进前端代码。
• 重启服务并用最小请求确认新 Key 生效。
• 观察 10 到 30 分钟，确认旧 Key 已无调用，新 Key 调用正常。
• 删除旧 Key，并把泄露来源从仓库历史或配置系统中清理。

不要这样处理

• 不要只在代码当前版本删除 Key，却不清理 Git 历史。
• 不要把新 Key 发到群聊或截图里让大家复制。
• 不要所有项目继续共用同一个新 Key。
• 不要在没有限额的情况下恢复 Agent 或脚本。

长期预防清单

• 生产 Key 只放在服务端环境变量或密钥管理系统。
• 前端只调用自己的后端，不直接暴露模型 API Key。
• 为不同项目、环境、工具创建独立 Key。
• 给测试 Key 和自动化任务设置较低限额。
• 定期清理不用的 Key，并检查最近用量是否符合预期。

FAQ

• Key 只露出前几位算泄露吗？通常不算完整泄露，但截图里如果包含完整 Key 就要立即轮换。
• 泄露后是否必须换所有 Key？不一定。先确认泄露范围，但无法判断时宁可扩大轮换范围。
• 怎么减少下次损失？独立 Key、低限额、白名单、用量告警和不把 Key 放进前端代码。