API Key 不是配置项，而是可转让的身份：个人项目秘密管理实战
从 .env、日志、备份到 AI 上下文，重新理解秘密的生命周期。
API Key 更像一张不看脸的门票：谁捡到谁就能用，系统通常分不清是不是原主人。
个人项目常把秘密管理理解为“不要提交到 Git”。这是必要条件，却远远不够。Token 可能出现在 shell 历史、进程参数、Docker inspect、错误日志、截图、备份压缩包和 AI 对话上下文中。它的风险来自可复制性：攻击者不需要破解，只要在某个副本里找到一次。
更稳妥的做法是管理秘密的完整生命周期：怎样产生、授予哪些权限、在哪里保存、谁能读取、怎样轮换、泄露后如何撤销。即使只有一个人维护，这套思路也能显著减少“我记得曾经放在某处”的混乱。
先区分配置、身份和加密材料
端口、时区和功能开关是普通配置；数据库密码、Admin API Key 和云密钥代表身份；备份主密钥、TLS 私钥则属于加密材料。三者不应进入同一份公开 Compose 示例。可以提交 .env.example 描述字段，却只在部署主机保存真实值。
文件权限 600 能阻止普通用户读取，却挡不住宿主机 root、Docker 管理员和获得目录挂载的容器。权限模型必须结合运行用户、挂载边界和备份去向理解。不要因为文件“隐藏”或以点开头，就把它当成安全存储。
最小权限要细到动作
DNS Token 如果只用于更新某个子域，就不应拥有整个账户的域名转移权限；博客发布 Key 不应能够管理账单和成员；只读监控凭据不应允许删除资源。服务商提供作用域时，按任务拆分；无法拆分时，至少为不同系统使用不同 Token，便于单独撤销和追踪。
MCP 和 AI 工具更需要细粒度 scope。不要给一个“读取文档”的 Agent 同时配置删除、分享和发邮件能力。OWASP 所说的 excessive agency 往往不是模型突然变坏，而是系统提前给了它不需要的功能。
日志和错误报告是常见泄漏点
调试 HTTP 时打印完整 Header 很方便，却可能把 Authorization、Cookie 和签名 URL 永久写进日志。结构化日志应在采集入口按字段脱敏，而不是等上传到日志平台后再处理。查询参数也要谨慎，因为 Token 有时被放进 URL，随后进入访问日志、浏览器历史和 Referer。
给别人或 AI 分析日志前，先保留一份原始证据，再生成脱敏副本。脱敏规则应覆盖 Token、密码、Cookie、私钥、邮箱和公网标识，但不要把时间、状态码、请求路径和关联 ID 全删掉，否则日志失去诊断价值。
AI 上下文是一条新的复制路径
把完整 .env 粘给 AI，让它帮忙排错，相当于主动制作了秘密的新副本。更好的方式是只提供变量名、长度、是否为空和错误消息，把值替换成占位符。需要 Agent 调用真实服务时，让运行环境注入凭据，模型只看到工具名称和结果，不直接看到秘密。
浏览网页、邮件和文档的 Agent 还可能遭遇间接提示注入，恶意内容会诱导它寻找并发送环境中的秘密。因此高敏感 Token 不应与开放网页浏览处在同一权限域，外发请求应有限定目标和人工确认。
轮换不是改字符串，而是一次小型迁移
可靠轮换顺序是：创建新 Key，部署消费者，确认新 Key 有流量，撤销旧 Key，最后检查日志与失败任务。直接覆盖旧值容易让定时任务或离线设备悄悄失效。对长期 Key 建立创建日期、用途、权限、存放位置和负责人清单，即使负责人只有你自己。
泄露时先撤销，再调查。不要花半小时争论截图是否真的被别人看见，因为 bearer token 的安全假设已经破坏。撤销后再检查调用日志、来源 IP、异常资源和关联 Key，必要时逐级轮换下游秘密。
可以直接照着做的检查清单
- 把普通配置、访问身份和加密私钥分开存储与备份。
- 为 DNS、博客、备份和 AI 工具创建不同且最小权限的 Key。
- 搜索 Git 历史、shell 历史、日志和旧备份中的秘密副本。
- 给日志和 AI 输入建立固定脱敏流程，不粘贴完整 .env。
- 记录每个长期 Key 的用途、创建时间、权限和轮换步骤。
- 发现疑似泄露时立即撤销，再分析影响范围。
延伸阅读
秘密管理的成熟标志不是从来不泄露，而是副本足够少、权限足够小、撤销足够快。
