大模型 API 密钥管理：从散落各处到统一治理的工程实践

背景：密钥管理，一个被忽视的盲区

无锡上线城市级 Token 超市，三十多家模型厂商接入，按用量收费。企业接入 AI 的流程被简化到极致。

但一个问题被忽略了：Key 放在哪？

一个七八人的技术团队，同时使用多个大模型服务。API Key 散落在项目配置、环境变量、聊天记录、CI/CD Secret 中。有人离职数月，Key 仍在运行。月底看账单只知道总金额，具体花在哪、谁用得最多——完全不清楚。

近期安全事件回顾

三起事件指向同一个根因：Token 获取越来越便捷，但管理基础设施严重缺失。

分层治理方案

第一层：安全存储

核心原则：密钥不进 Git、不进 .env、不进聊天记录。使用本地加密 Vault 存储，项目配置文件只声明意图，不存放任何密钥。

第二层：访问控制与审计

用可撤销的派生凭证替代原始 Key。每个凭证绑定额度、限速和模型白名单。人员变动时控制面一键撤销，分钟级生效。按项目、按人、按模型记录每笔调用，形成完整审计链路。

第三层：异常检测

基于调用日志构建监控指标，设定用量阈值。当 Key 在非工作时间出现异常调用量时自动告警。

最小化实现思路

落地层面，可以用 Python 快速搭建一个三层轻量网关。凭据层采用对称加密（如 Fernet）对密钥做本地 Vault 存储，运行时解密注入；路由层用配置表描述项目到模型的映射关系，不存放任何密钥原文；审计层在调用入口统一记录项目标识、延迟和调用时间。这三层都是几十行代码量级的模块，组合起来就能形成从接入到审计的完整闭环。

结语

Token 是资产还是成本？回答这个问题之前，得先回答一个更基础的问题：你的 Token 在哪。

Token 超市让企业用 AI 像用自来水一样方便，但拧开水龙头之前，最好先确认一件事——水表装了没。