LLM API 的密钥管理，是一套决定谁能拿到密钥、每个密钥能访问什么、存放在哪里、以及如何轮换与吊销的规则。在生产环境站得住的做法是一项目一密钥：每个工作负载有自己的项目，项目的密钥带着自己的模型清单与预算。下面依次整理共用密钥出问题的三种情况、发密钥的做法、各环境密钥存放位置的对照表，以及一份 30 天迁移流程。
共用密钥出问题的三种情况
已离职的外包工程师
一位外包工程师用公司唯一的一个 API 密钥做 RAG 原型，密钥放在本地的 .env 文件里，周五离职。同一个密钥还在跑客服机器人、每晚的摘要任务和内部的 Slack 助手。当天下午吊销它，三个服务一起挂；不吊销，等于一位已离职的外包手里还有一个能用的密钥。多数团队选择“下个 sprint 再轮换”，而下个 sprint 总是排满。
一项目一密钥的话，这位外包从头到尾只拿到自己沙箱项目的密钥。吊销它，其他什么都不受影响。
被推到公开仓库的密钥
有人把含密钥的配置文件 commit 到公开仓库。拿到它的人发出的流量会算在你的账单上，而且因为每个服务都发同一个密钥，对方的请求在用量数据里和你的完全一样。处理方式与外包的情况相同，同样会带来一次停机。
没人说得清的花费暴涨
月度账单翻倍。供应商的仪表盘看得出哪个模型用量上升，但每笔请求都带同一个密钥，没人能说清是哪个产品造成的。财务要求按产品拆账，工程师花两天比对各服务日志的时间戳。
各家厂商的建议
OpenAI 的 API 密钥安全最佳实践 要求每位团队成员使用各自的 API 密钥、定期轮换并设置过期，且永远不要把密钥放在客户端代码里。OpenAI 还建议把 staging 与生产环境分成不同项目，各自设置上限（生产环境最佳实践）。Anthropic 可以把 API 密钥限定在单个 Console 工作区。Vercel AI Gateway 的密钥可以同时设置预算与过期时间，适合有明确结束日期的外包密钥（Vercel 预算）。
个人密钥解决的是人员离职的问题。生产服务不应该跑在某个人的密钥上，否则移除这个人，服务也会跟着停。实际可行的分法是：个人密钥给个人沙箱，每个已部署的工作负载各有一个项目密钥。
发密钥的做法
- 每个工作负载、每个环境各一个项目。
support-bot-prod与support-bot-staging是两个独立项目，各有各的密钥。 - 服务使用项目密钥，一个项目一个。需要做实验的人有自己的沙箱项目。
- 密钥按“服务、环境、签发月份”命名，例如
support-bot-prod-2026-10，在日志或仓库里发现时能直接对应到负责人。 - 密钥从控制台直接放进 secret manager，不要贴到聊天、工单或文档里。
- 用重叠方式轮换：在同一个项目发新密钥、部署、确认流量已经转移，再吊销旧的。
各环境的密钥放在哪里
ATP Token 的密钥如何工作
ATP Token 是四层结构：组织、工作区、项目、密钥（设置组织）。一个密钥只属于一个项目，并继承该项目允许的模型与点数余额。模型权限按项目设置，从不按密钥设置，所以同一个项目里的两个密钥能调用的模型始终相同。
创建密钥的向导会让你填写名称、选择工作区与项目，并可选择先拨入一些起始点数。密钥以 atp- 开头、长度 92 个字符，完整密钥只在创建时显示一次，之后只能看到前缀（管理 API 密钥）。API 密钥页面列出组织内所有工作区与项目的每一个密钥，可按名称或前缀搜索。吊销的密钥立即失效，并保留在列表中供审计。
追查花费时，用量页面按模型和密钥显示点数与 token，请求日志则记录每次调用的模型、状态、token 数与请求 ID（用量与日志）。请求日志保留 7 天，事件发生后请尽快检查可疑的密钥。网关在转发请求前会去掉你的 atp- 密钥，上游供应商永远看不到它（工作原理）。
谁能做什么由角色决定：Admin 管理成员、资源、密钥与点数分配，Member 则使用自己有权限的内容（团队与角色）。
迁移流程：从一个共用密钥到项目密钥
这份流程最好搭配每个项目的预算，泄露或陷入循环的密钥也会撞到上限。见 AI API 花费上限对比。
