API Key 安全管理实践：从生成到泄露应急的最小清单
大模型的 API Key 本质上就是一张「记账卡」：谁拿到它，谁就能用你的账户调用接口，账单记在你头上。2026 年 10 月，开源 AI 编程工具 OpenCode 发生安全事件——一套正在下线流程中的旧系统被攻击者入侵，约 1.4% 的 Console 用户存储的 OpenAI、Anthropic、谷歌等第三方密钥外泄，有用户被冒用身份调用接口，Anthropic 账户被盗刷 400 美元，最高的单用户损失达 1700 美元（据环球网科技 2026-10-18 报道）。
这件事最值得记住的一点是：用户没有泄露自己的密码，问题出在把 Key 托管给了第三方工具。所以 Key 的安全不靠「选一家靠谱的平台」，而靠一套自己手里的最小习惯。下面这份清单不堆砌企业级方案，普通个人用户照着做就够了。
一、生成阶段：一个用途一把 Key
很多人从注册那天起就犯了个错：一把 Key 用遍所有工具。正确的做法很简单：
- 按用途拆分。写脚本用一把、配中转站用一把、给第三方工具用一把。这样一旦某把 Key 泄露，能立刻判断是从哪个渠道漏的，吊销时也不影响其他工具。
- 命名写清用途。创建 Key 时备注「opencode-2026-11」这类名字，三个月后你还能看懂它是干嘛的。
- 能设到期日就设。OpenAI 支持为项目密钥设置到期日期，到期后所有请求自动被拒。其官方帮助中心明确建议建立定期轮换流程，这能大幅降低泄露造成的影响（参见 OpenAI 官方密钥安全最佳实践）。
二、存放阶段：环境变量是底线
OpenAI 官方列出的泄露途径里，排最前面的两条是「提交进代码仓库」和「部署在浏览器、App 等客户端」。对应到普通人身上就是几条红线：
| 场景 | 能不能做 | 原因 |
|---|---|---|
| 硬编码在代码 / 配置文件里随代码提交 | 不行 | 公开仓库等于直接把钥匙挂门上，私有仓库被拖库同样会泄 |
| 用环境变量（如 OPENAI_API_KEY）存放 | 推荐 | Key 跟代码分离，代码可以随便分享 |
| 贴进聊天窗口、在线笔记、截图 | 不行 | 聊天记录、云端笔记、图床都是潜在的公开面 |
| 交给第三方工具托管 | 谨慎 | OpenCode 事件就是前车之鉴；一定要用就只放限额最低的那把 |
如果你需要把 Key 给到中转站或聚合工具使用，给出去的应该是「专门为它创建的那把」，而不是你账户里唯一的主 Key——这一点和《新人选站指南》里的思路一致：任何第三方都按「可能出事」来假设。
三、限额阶段：给账单装刹车
额度类平台被盗刷的速度以分钟计，等你早上醒来发现余额清零，损失已经发生。所以拿到 Key 后第一件事是去后台把限额配好：
- 设置消费提醒。OpenAI 支持按月度预算设置 90%、95% 等多个阈值告警，并自定义接收邮箱。
- 开启硬性消费上限。注意：硬上限存在统计与结算延迟，高并发盗刷在触发熔断前实际产生的费用可能已经超出上限——它是刹车，不是保险箱（社区分享，未实测）。
- 关闭非必要的自动充值。预付费余额本来是天然限额，但开了自动充值，预付费就会被盗刷变成无限透支。这是最容易踩的坑。
四、轮换阶段：季度一换，出事即换
轮换不需要仪式感，记住两个触发条件就行：
- 定期轮换：每三个月换一次。流程是「先在平台创建新 Key → 更新应用配置 → 确认新 Key 正常工作 → 再删除旧 Key」，顺序反了会把自己的服务搞断线。
- 事件触发轮换：团队成员变动、设备丢失、某个托管平台出了安全公告（哪怕它说「你可能没受影响」），都按泄露处理。Anthropic 在 OpenCode 事件后就强制注销了所有疑似泄露的密钥，等通知不如自己动手。
五、泄露应急：四步止损
发现余额异常、收到平台异常调用预警、或者确认 Key 贴错过地方时，按这个顺序处理：
- 立即吊销：登录模型平台的 API Keys 页面删除该 Key，让它立刻失效。注意是去平台后台删除，而不是只删本地的环境变量或配置文件——后者不影响 Key 本身的有效性。
- 查用量日志：在平台后台按时间导出调用明细，看调用了什么模型、有没有陌生来源 IP。日志里全是你不认识的请求，基本可以定性为泄露。
- 换新 Key 并排查源头：从可信设备生成新 Key，更新所有用到旧 Key 的工具配置。同时回想这把 Key 出现过的所有地方：截图、git 历史、聊天记录、第三方工具后台。
- 核对账单：导出异常时间段的扣费明细，联系平台客服说明是密钥被盗用产生的非授权调用。有延时结算的账单要持续复查几天，别以为当天账单没涨就没事。
FAQ
Q1：Key 只在我的私有仓库里，也有风险吗？
有。私有仓库依然可能因为设备丢失、账号被盗、平台数据泄露而外泄。环境变量 + 定期轮换的成本很低，没必要赌运气。
Q2：把 Key 给中转站用安全吗？
任何第三方托管都有 OpenCode 式的风险。如果确实要用：给中转站单独创建一把 Key、在源平台设好消费硬上限、关闭自动充值，并且这把 Key 不用于任何生产用途。
Q3：额度突然没了，怎么区分是自己脚本失控还是被盗刷？
看平台调用日志：自己脚本失控的请求来源 IP 和时间规律都符合你自己的使用习惯；陌生 IP、深夜集中调用昂贵模型、调用量突然呈火箭式上升，基本是被盗刷了。
Q4：轮换时直接把旧 Key 删了建新的，为什么不行？
顺序应该是「建新 → 更新配置 → 验证正常 → 删旧」。直接删旧的，所有还在用旧 Key 的工具会同时断线，你得手忙脚乱地一个个重新配置。
Q5：设置消费上限后是不是就绝对安全了？
不是。硬上限有结算延迟，盗刷的账单可能超出上限才被拦住。上限的意义是缩小损失范围，真正的安全还是靠「一把 Key 一个用途 + 及时吊销」。
---
本文由中转站导航整理，2026-11-03 更新。发现失效信息欢迎反馈。