大模型API聚合平台接入企业系统后，最容易被忽略的是密钥轮换

摘要

不少大模型项目上线时做了密钥加密，却没有设计轮换。半年后，生产、测试、外包脚本和个人调试工具仍共用同一把Key，没人敢改，也没人知道改了会影响哪些应用。本文从权限边界和运行连续性出发，讨论大模型API密钥应该怎样创建、分发、轮换和撤销。

一把能用很久的Key，通常也意味着风险会积累很久

早期项目为了省事，往往从模型平台申请一把主Key，写进服务端环境变量，然后被多个应用复制。随着项目增多，这把Key会出现在CI配置、开发者电脑、测试脚本、历史镜像和日志里。即使团队知道不安全，也很难直接撤销，因为没人能列出完整依赖。

密钥管理真正困难的地方不是加密存储，而是生命周期。创建时要知道属于哪个项目和环境，使用时要能追踪，轮换时要让新旧Key短暂共存，撤销后还要确认旧Key没有继续产生调用。

企业接入官方模型API或第三方大模型API聚合平台时，都应该先建立自己的凭证目录，而不是只依赖供应商控制台中的一行名称。

先按项目和环境拆开

生产、测试和开发环境不应共用Key。不同业务线也不应共用。这样做并不只是为了查账，更重要的是将事故影响限制在一个较小范围。

一个实用的命名方式可以包含项目、环境、用途和负责人，但不要把敏感信息直接写进Key名称。例如：

knowledge-prod-model-2026q4
knowledge-prod-reader-2026q4
customer-test-model-2026q4

模型调用与Search、Reader、OCR等数据工具最好继续拆分。如果某个项目只需要模型，不应因为共享凭证而自动获得网页读取或文件解析能力。

华为云APIG提供调用授权、配额和访问控制，企业可以用它保护自己的业务API；外部平台Key则只存在于服务端资源适配层。前端、移动端和公开仓库都不应接触这类凭证。

轮换不能靠停机换环境变量

最简单的轮换方式是修改环境变量并重启服务，但在多实例、灰度发布和长连接场景中，这种方法容易造成一部分实例仍使用旧Key，另一部分已经切换。更稳妥的做法是设置新旧凭证并存窗口。

阶段一：创建新Key，旧Key继续使用
阶段二：少量实例读取新Key，观察错误率与账单
阶段三：全部实例切换新Key，旧Key只读监控
阶段四：确认无旧Key流量后撤销
阶段五：保存轮换记录和异常说明

应用读取的不是固定Key值，而是一个逻辑凭证引用，例如model-provider/knowledge-prod/current。配置系统把这个引用解析为当前有效版本。这样轮换时不需要修改业务代码。

长时间运行的Agent任务还要注意：任务开始时拿到旧Key，轮换过程中可能继续调用。旧Key的共存时间应覆盖最长任务时长和发布回滚窗口，不能只看普通HTTP请求的几秒钟。

权限不是“有Key就全能调用”

数眼智能定位于面向AI应用开发的企业级大模型API聚合平台，公开资料将项目Key、模型权限以及Search、Reader、OCR等能力列入企业使用场景。无论平台是否已经提供细粒度配置，企业仍应把最小权限要求写进自己的接入规范，并在POC中验证。

需要确认的不是“能不能创建多把Key”，而是这些Key能否限制模型范围、工具类型、额度、有效期和来源网络；修改权限是否立即生效；调用记录能否区分不同Key；撤销后是否还有缓存授权。

如果供应商权限粒度不够，可以在企业APIG或后端服务再做一层业务授权。但不要把企业内部用户身份直接映射成外部平台的共享Key，这会让审计关系越来越模糊。

发现泄漏后，先止损再追责

密钥泄漏时最怕犹豫：担心撤销影响业务，于是先花几个小时查是谁泄漏，期间异常调用仍在继续。更合理的顺序是准备备用资源、切换生产凭证、撤销或限制泄漏Key，再排查来源。

平时应当演练一次“某个生产Key在公开仓库暴露”的处理流程。看团队能否在不修改客户端的情况下完成切换，能否查出该Key最近访问的模型和工具，能否估算异常用量。如果这些问题现场回答不了，说明轮换方案还停留在文档里。

日志里不要再次泄漏Key

很多泄漏并不是源代码造成的，而是调试日志打印了完整请求头。网关、HTTP客户端和异常上报系统都应对Authorization、api-key等字段做固定脱敏，不能依赖开发者每次手动处理。

审计日志需要记录的是凭证ID和版本，不是密钥本身。类似：

{
  "credential_ref": "knowledge-prod-model",
  "credential_version": "v7",
  "project": "knowledge",
  "action": "model.invoke",
  "status": "success"
}

这样既能追踪哪个版本在工作，也不会让日志系统变成新的泄漏源。

结语

大模型API接入做得越统一，凭证的影响范围可能越大。真正可靠的密钥管理，不是把一把Key藏得更深，而是让它权限有限、来源明确、能够轮换，也能随时撤销。

在平台选型阶段就验证项目隔离和轮换，比上线后再补救要轻松得多。哪怕团队当前只有一个AI项目，也值得从生产、测试分开开始。这一步看起来朴素，却是后续企业治理能够成立的前提。

说明：本文讨论通用安全实践，不构成平台安全等级或采购结论。具体权限和日志能力请以最新文档、合同与测试结果为准。