泄露之后会发生什么
Key 泄露最常见的原因是提交到公开仓库、写进前端代码、截图里带出去。拿到 key 的人不需要你的账号密码，直接按 token 烧额度。
按最坏情况算：claude-opus-5 在 Claude Max 分组输入 4.25、输出 21.25 美元每百万 token。假设脚本每小时跑 1000 次、每次 2000 输入 500 输出，一小时 19.13 美元，一天 459 美元。额度耗尽是小事，共享渠道被限速、同组其他人受影响才是连锁反应。
这类脚本通常在 key 暴露后几分钟内就开始跑，等你看到账单已经过去几小时。把 key 贴进工单、贴进聊天群、录进演示视频，后果一样。
前端不能放 key
任何写进前端代码的 key 都是公开的。打包后的 JS 里能搜到，浏览器网络面板里能看到，按 F12 就有。混淆和加密只是把明文换了个位置，运行时总要还原。
前端只能调你自己的后端，由后端持有 key，并加上登录校验、频率限制和用量配额。静态站点没有后端，就别直连模型接口。
环境变量与最小权限
- key 只放环境变量或密钥管理服务，不进代码、不进镜像、不进日志。
- 不同项目用不同的 key，一个泄露不牵连全部。
- 给 key 设额度上限和模型范围，别用管理员 key 跑业务。
.env进.gitignore，CI 里用 secret 变量，别写进流水线脚本。
本地开发也一样。把 key 写在 settings.py 里再提交，是这类事故里最常见的一种。测试环境同样要限额，测试 key 泄露一样能刷出账单。
轮换后旧 key 留三天观察期，确认没有遗漏的服务还在用，再吊销。直接删掉，隐藏的定时任务会在半夜报错。
轮换流程
轮换的原则是新建、切换、吊销分三步走，中间不要留空窗。
import os
import requests
from pathlib import Path
NEW_KEY = os.environ["NEW_API_KEY"]
OLD_KEY = os.environ["OLD_API_KEY"]
BASE = "https://ai.idcidiot.com/v1"
def probe(key: str) -> bool:
r = requests.get(f"{BASE}/models",
headers={"Authorization": f"Bearer {key}"}, timeout=20)
return r.status_code == 200
assert probe(NEW_KEY), "新 key 不可用，先别切"
env = Path(".env")
lines = [l for l in env.read_text().splitlines() if not l.startswith("OPENAI_API_KEY=")]
lines.append(f"OPENAI_API_KEY={NEW_KEY}")
env.write_text("\n".join(lines) + "\n")
print("已写入新 key，确认流量正常后再吊销旧 key")跑完还要重启服务、确认进程读到的是新值。只在 .env 里改了但没重启，是最容易漏的一步。
泄露检测
gitleaks detect --source . --no-git 扫工作区，去掉参数扫提交历史。把扫描挂进 pre-commit 和 CI，比出事后再翻 git 历史便宜。公开仓库里的 key 通常推送后很快就会被自动化脚本扫到。
除了扫描工具，定期在后台看调用记录：来源 IP、模型分布、消耗曲线。出现你没跑过的模型或者凌晨的调用高峰，先按泄露处理。
公开仓库的 secret scanning 会主动通知你，私有仓库不会，别指望平台兜底。自己扫一遍花不了几分钟。
事故处置清单
- 立刻在后台禁用该 key，不是改密码。
- 查调用日志，记录模型、IP、时间段和消耗额度。
- 建新 key，更新所有部署环境并重启。
- 检查同一批 key 是否也泄露，同一份
.env、同一个仓库都要查。 - 复盘泄露路径：是提交、是日志、还是前端打包产物。
处置完把这次的时间线写下来，包括发现时间、禁用时间、恢复时间。下次再遇到，这份记录比任何预案都好用。
清单可以打印出来贴在值班文档里。出事的时候人容易慌，按顺序执行比临场判断可靠。
模型和分组的价格在 定价页，claude-opus-5 的参数在 模型页，其他接入问题可以翻 文章列表。今天就花十分钟把仓库扫一遍，比事后追账单划算。