生成与分发：一钥一用
每个用途单独密钥：个人实验、CI、产品后端各一把，出事可单独吊销不影响其他链路。分发给成员走密码管理器的共享功能，不走聊天记录与邮件正文。用中转站的要注意分组绑定：米醋官方公告（落款 2026-05-19）明确令牌“务必选择对应分组、禁止使用默认分组”，否则计费异常或调用失败——发密钥时把分组一起写清。
存储位置红线
三条红线：不进浏览器 JS（前端代码里的密钥等于向所有访问者公开，需要前端调模型就走自己的后端代理）；不进公开仓库与截图；不进聊天记录。主流工具的设计与此一致——Codex 用 env_key 指向环境变量名，Claude Code 用 ANTHROPIC_AUTH_TOKEN / ANTHROPIC_API_KEY 环境变量（2026-10-07 核对的官方文档），密钥本体都不落配置文件。
# 在仓库目录自查常见密钥形态（提交前 / 接手旧项目时跑一遍）
grep -rnE "sk-[A-Za-z0-9_-]{16,}" \
--exclude-dir=node_modules --exclude-dir=.git --exclude-dir=dist .
# 密钥只放环境变量或部署平台的 secret 注入，进程内读取；sk-... 只是占位写法
# 本地临时测试用 read -s MY_APP_API_KEY 交互读入（不回显、不进 shell 历史），别写进 shell 配置轮换与回收
成员离职、设备退役、密钥出现在任何不该出现的地方——立即吊销重发。每季度在服务商后台核对一次密钥清单与调用日志：不认识的来源 IP、异常用量峰值、早已下线项目仍在产生的调用，都是轮换信号。中转站的调用日志通常记 token 消耗与时间（米醋公告自述如此），恰好可以反向用来发现异常。
请求内容边界
默认假设请求内容可能被服务商记录与查看，无论其宣称什么。米醋公告明确“有记录：每条 API 调用均有日志，包含时间、Token 消耗等调用信息”，并自述“对话内容不作保存”——后者是商家单方声明，不是可验证的技术保证。据此划线：密钥、口令、客户隐私、未公开财务与合同数据不进请求；确需处理先脱敏或用占位符替换。
验收条件
(1) 自查命令在所有相关仓库零命中；(2) 每把密钥能对应一个用途和一个负责人；(3) 做过一次吊销演练——吊销后旧密钥确实返回 401，且替代密钥已就位。没有演练过的轮换流程等于没有流程。