多模型 API Key 如何按项目隔离并保留审计线索

当多个应用、团队和环境共用一枚模型 API Key 时，调用成功并不代表接入方式合理。费用或错误率突然变化后，团队可能无法判断请求来自哪个服务；密钥泄露时，只能同时中断所有业务；测试脚本也可能误用生产额度。解决问题的重点不是先更换 SDK，而是建立“调用主体可识别、权限可收敛、密钥可单独撤销、日志可关联”的边界。本文给出一套与具体供应商无关的拆分方法，以及迁移期间需要验证的审计线索。

为什么不能只按模型拆分密钥

“一个模型一枚 Key”只能说明请求发往哪里，不能说明是谁发起请求。实际排查至少需要回答四个问题：

哪个应用发起了请求？
请求来自开发、测试还是生产环境？
谁负责该应用及其预算？
出现异常时能否只撤销这一条调用链？

因此，密钥的主要边界应是调用主体和环境。模型范围、额度与速率限制属于附加权限，不应替代主体身份。

建立路径级密钥清单

先盘点现有调用，不要直接轮换。清单可使用如下字段：

一条记录应对应一个可以独立停止的调用路径。例如同一个服务的测试与生产环境应使用不同密钥；临时数据脚本不应复用在线服务的生产密钥。

用稳定名称传递配置

应用代码只读取约定的环境变量或密钥挂载路径，不把真实密钥写进仓库：

import os

api_key = os.environ["MODEL_API_KEY"]
api_base_url = os.environ["MODEL_API_BASE_URL"]

不同环境使用相同变量名，由部署系统注入不同值。这样，轮换操作发生在密钥管理与部署层，业务代码不需要随密钥变化而修改。

日志中不能输出 MODEL_API_KEY 的值。若需要识别凭据，可在密钥管理侧为其设置不含敏感信息的标识，并将该标识作为部署元数据传入，例如 credential_id=orders-prod。

定义最小审计字段

一条可用于排查的调用记录通常需要：

timestamp
service
environment
credential_id
request_id
model
operation
status
latency
input_units
output_units

字段名称可以按现有日志规范调整。关键是让应用日志、网关日志和上游返回的请求标识能够关联。正文内容、完整提示词和用户输入不应默认进入日志；是否记录以及如何脱敏，需要根据数据分类和调查目的单独决定。

分阶段替换共享密钥

1. 创建新凭据但不撤销旧凭据

按清单为一个低风险服务创建独立凭据，并仅授予该服务需要的模型和权限。此时保持旧路径可用，便于发现配置遗漏。

2. 在单一环境切换

先切换开发或测试环境。使用不含敏感数据的最小请求，验证认证、模型选择、超时处理和日志字段。不要因为文本请求成功，就推断文件输入、工具调用或流式响应也兼容。

3. 对比两侧观测结果

检查应用是否拿到响应，同时确认审计侧出现正确的 service、environment、credential_id 和 request_id。若只有业务结果而没有身份信息，后续仍无法归因。

4. 切换生产并观察失败信号

生产切换后，关注认证失败、权限不足、模型不可用、超时和限流。异常时只回滚该服务的配置，不恢复跨项目共享密钥作为长期方案。

5. 撤销旧凭据

确认清单中的调用方全部迁移后再撤销旧密钥。撤销后主动执行一次旧凭据测试，预期应认证失败；随后再用新凭据执行最小请求，确认业务路径仍可用。

轮换演练必须验证什么

密钥隔离只有在撤销流程可执行时才有意义。演练至少验证：

• 负责人能从清单定位密钥和受影响服务；
• 撤销一枚密钥不会中断其他项目；
• 新密钥可以通过部署系统注入，而无需提交代码；
• 应用日志不包含密钥明文；
• 旧密钥失效和新密钥生效都留下可查询记录。

不要在同一次演练中同时更换接口协议、模型和密钥，否则失败原因难以定位。

结论与限制

多模型接入的首要治理单元应是“服务加环境”，而不是供应商或模型名称。路径级密钥、最小权限、稳定配置名和可关联日志组合起来，才能让异常归因与局部撤销成为可能。

本文描述的是通用设计与迁移检查点。具体供应商支持哪些权限、日志字段、额度或轮换接口，需要依据当前官方文档和实际控制台逐项确认；敏感数据的日志策略还应服从组织的数据分级与合规要求。