Token 超市一个接一个地上线，API 越来越便宜，接入门槛越来越低。但一个尴尬的问题被所有人忽略了：Key 到底放哪了？谁来管？
最近行业里连续出了几件事，把这个问题的严重性推到了台前。
LiteLLM，月安装量 9500 万次的 AI 网关，在 PyPI 上被人投毒，植入后门窃取 API 密钥。Braintrust 的 AWS 账户被攻破，Box、Stripe、Cloudflare 等客户的 API 密钥全部暴露。而 Axios 报道了一家企业在开通 Claude 企业授权后忘了设置用量上限，一个月烧掉 5 亿美元。
这些事件的共同点不是技术有多复杂，而是管理有多粗糙。
我们到底在管理什么
大模型 API 调用本质上是一个典型的「分布式凭据管理」问题。团队里七八个人，Claude、GPT、DeepSeek 都在用，Key 散落在项目配置文件、环境变量、飞书聊天记录、CI/CD 的 Secret 中。有人离职三个月了，Key 还在后台跑。没人记得轮换。
用 Git 管代码，用 Docker 管环境，用 Kubernetes 管部署。但管 API Key 的方式，跟十年前把密码写在便利贴上贴在显示器旁边没有本质区别。
工程化的思路
解决这个问题的核心思路其实不复杂，可以拆成三层。
第一层：凭据安全存储。 Key 不进 Git、不进 .env、不进聊天记录。用本地加密 Vault 存储身份信息，项目配置文件只描述意图（「这个项目用 Claude」），不存任何密钥。
第二层：访问控制与审计。 不直接使用云厂商的原始 Key，而是通过可撤销的派生凭证来分发。每个派生凭证设置额度、限速、模型白名单。人员变动时控制面一键撤销，分钟级生效。同时每一笔调用按项目、按人、按模型拆分记账，谁在什么时候用了什么 Provider、花了多少钱，完整可查。
第三层：异常检测。 当某个项目的 Token 消耗突然飙升，或者有 Key 在非工作时间被大量调用时，自动告警。这层可以和云平台的安全监控能力结合使用。
实现思路
如果团队规模不大，可以先从最轻量的方式跑起来。核心逻辑不复杂：密钥从加密存储中读取，项目配置只声明意图（"这个项目用哪个模型"），调用链路统一拦截记录审计日志。路由层本质上是一个映射表，凭据层依赖本地加密 Vault，审计层则在请求入口做统一埋点。三层组合起来，就能形成从「谁在调用」到「花了多少钱」的完整闭环。生产环境接入密钥轮换、用量熔断等机制后，这套方案的健壮性会进一步提升。
不只是技术问题
黄仁勋说 Token 是资产，李彦宏说 Token 是成本。两个人吵得不可开交。但争论的前提是——你得先知道你的 Token 在哪。
如果你连谁在用、用了多少、花在哪了都不知道，那它是资产还是成本，跟你有什么关系？
Token 超市让企业用 AI 像用自来水一样方便，拧开水龙头就有。但拧开水龙头之前，最好先确认一件事：你家的水表，装了没？
本文探讨的密钥管理思路可结合阿里云 KMS（密钥管理服务）实现凭据的安全托管与自动轮换，同时借助阿里云百炼平台的模型调用能力构建统一的 API 网关层。
