如何为团队设计LLM API密钥治理系统

共享 LLM 提供商密钥非常方便，直到首次离职、账单高峰、合作伙伴集成或机密泄露。实际问题不仅仅是一把钥匙可能被暴露。共享密钥会导致所有权不明确、难以归属，并且存在紧急撤销风险，因为多个应用程序可能依赖于相同的凭据。

一个可行的 AI API 密钥治理系统应该针对每个请求回答五个问题：谁拥有此访问权限、可以做什么、可以花费多少、如何检测异常使用以及如何在不关闭不相关系统的情况下撤销该访问权限？

本指南将经过验证的事实与实施建议分开。事实描述了主要提供商或安全框架记录的功能和风险。这些建议描述了使用多个 LLM 提供商的团队的实用操作模型。

从两层凭证模型开始

最重要的设计决策是停止在应用程序、脚本、笔记本电脑、CI 作业和合作伙伴系统之间广泛分发原始上游提供商密钥。相反，使用两层模型：

• 提供商凭证：由上游 AI 提供商颁发的密钥或服务凭证。这些内容应仅存储在受控后端、网关、秘密管理器或类似的受限服务中。
• 受管理的内部凭据：颁发给团队、应用程序、环境、CI 作业或合作伙伴的密钥。这些密钥调用您的受控访问层，该层应用策略、路由、遥测、限制和撤销。

事实：提供商指南通常建议不要与团队成员共享 API 密钥、建议安全存储，并警告泄漏的密钥可能会造成未经授权的活动或费用。提供商控制台还可以支持项目、工作区、关键级别使用、速率限制和预算控制，尽管功能因供应商和计划而异。

建议：将提供商密钥视为基础设施机密，而不是开发人员便利令牌。开发人员应该收到可以独立确定范围和撤销的受管理密钥。此方法支持企业 LLM API 操作，因为凭证策略、分析和成本控制可以跨多个模型和提供商一致应用。

在发布更多密钥之前定义密钥分类

团队通常会在定义每个密钥代表的内容之前发布密钥，从而造成治理问题。密钥不应该是一个随机的秘密。它应该是一个具有元数据、所有权、策略和生命周期状态的托管对象。

每个受控密钥的最小元数据

• 所有者团队：负责的团队，而不仅仅是个人请求者。
• 应用程序或工作负载：使用密钥的系统、服务、脚本或集成。
• 环境：生产、暂存、开发、CI、沙盒或合作伙伴。
• 业务目的：客户支持摘要、内部搜索、代码帮助、文档提取、代理工作流程或其他批准的用例。
• 允许的模型系列或提供商路线：密钥可以访问哪些模型或提供商。
• 数据敏感度层：请求是否包含公共数据、内部数据、机密数据、受监管数据或客户数据。
• 预算上限：每日、每周、每月或项目级别的支出限额。
• 速率限制：每分钟请求数、每分钟令牌数、并发作业或批次限制。
• 到期日期：对于临时密钥是必需的，建议对于大多数非生产密钥。
• 紧急联系人：事件期间负责的团队渠道或人员。

简单的命名约定可以帮助操作员快速了解爆炸半径。例如：

团队：支持行动
应用程序：票证汇总器
环境：产品
use_case：客户支持摘要
data_tier：客户机密
models_allowed: [模型系列-a, 模型系列-b]
每月预算美元：2500
旋转间隔天数：90
owner_contact：#support-platform-alerts

建议：不要为生产系统发布以人名命名的通用密钥，例如 alice-openai-key。使用服务帐户所有权和团队责任，使密钥能够在员工角色变化后继续存在，同时保持可追溯性。

单独的环境以减少爆炸半径

切勿在生产、暂存、开发、CI 和合作伙伴环境中重复使用一个 LLM API 密钥。操作原因很简单：这些环境具有不同的风险状况。本地开发中使用的密钥更有可能出现在 shell 历史记录、临时文件、笔记本或测试存储库中。生产密钥通常具有更高的配额和对敏感工作负载的访问权限。将它们结合起来会使每次泄漏更加严重。

实用环境政策

• 生产：严格审批、服务帐户所有权、对广泛模型访问的低容忍度、受监控的预算和紧急撤销程序。
• 分期：与生产流程类似，但限制较低，并且除非明确批准，否则不会提供生产数据。
• 开发：较低的配额、较短的有效期、有限的数据敏感性以及鼓励安全实验的模型限制。
• CI 和自动化：测试作业、基准测试作业、评估管道和发布工作流程的专用密钥。
• 合作伙伴访问权限：委托或合作伙伴范围内的密钥，具有严格的配额、文档和每个合作伙伴的可观察性。

权衡：细粒度的环境分离会增加需要管理的凭据数量。答案不是将所有内容都压缩到一个共享密钥中。答案是自动化配置、元数据捕获、秘密存储和轮换状态。

在 API 层应用最小权限策略

LLM API 密钥不应意味着对每个模型、端点、上下文大小和支出水平的无限制访问。 LLM 证书的最低权限需要的不仅仅是是或否权限检查。

值得实施的控制措施

• 允许的模型：仅允许密钥用例批准的模型系列或路由。
• 最大上下文大小：防止意外提交异常大的文档或提示包。
• 最大输出代币：限制失控的生成成本并减少滥用影响。
• 端点限制：单独的聊天、嵌入、批处理、图像、工具使用和相关的代理工作流程访问。
• 预算上限：设置关键级别、应用级别和团队级别的上限。
• 速率限制：限制请求峰值并保护上游配额。
• IP 或网络限制：在支持且操作可行时应用。
• 阻止的用例：拒绝已知不允许的工作流程、未经批准的数据层或高风险自动化路径。

例如，内部文档助理可能被允许使用嵌入和中等成本的文本生成模型，但不允许使用高级推理模型、批量批处理作业或图像生成。财务工作流程可能需要更严格的数据处理和更窄的模型路由。开发沙箱的每日上限可能较低，并且只能访问非敏感测试数据。

建议：将策略实施放在受控访问层中，而不是完全依赖应用程序代码。应用程序级检查很有用，但当团队复制代码片段、创建脚本或快速添加新集成时，它们更容易被意外绕过。

通过使用情况分析来检测每个按键

当凭证已发出但未得到遵守时，密钥治理就会失败。监控应该使每个受控密钥都可归因且可诊断。

默认捕获的遥测数据

• 密钥 ID 和密钥名称，不包括秘密值本身。
• 所有者团队、应用、环境和成本中心标签。
• 时间戳、请求计数、令牌数量和估计成本。
• 提供程序、模型、端点、延迟、状态代码和错误类别。
• 源应用程序、服务帐户、区域或网络来源（如果有）。
• 政策决策，例如允许、拒绝、限制、限制预算或路由至后备。

事实：主要人工智能提供商提供某种形式的使用情况、成本、项目、工作区或关键级别报告。确切的报告字段和管理 API 因提供商和计划而异。

建议：如果您使用多个提供商，请在您自己的系统中标准化使用元数据。提供商本机仪表板很有用，但当一个团队可能针对不同工作负载使用不同模型时，跨提供商视图是必要的。

提示和响应记录需要特别小心。详细的内容日志可以帮助事件调查和质量调试，但它们也会产生隐私和合规义务。更安全的默认设置是记录元数据、策略决策、成本以及哈希值或引用。仅针对具有保留规则和访问控制的已批准用例启用内容日志记录。

创建警报以尽早检测凭据滥用

支出阈值是必要的，但还不够。泄露的密钥可能会在达到大额账单之前导致可疑的流量模式。警报应结合成本、数量、路线和行为信号。

有用的异常警报

• 开发密钥突然发送类似生产的流量。
• 密钥使用了之前未使用过的模型系列。
• 与之前时期的同一小时或同一天相比，代币交易量急剧增加。
• 请求来自新的网络、区域、合作伙伴或部署目标。
• 由于自动化客户端频繁重试，错误率激增。
• 某个关键点接近其预算上限的 50%、80% 和 100%。
• 休眠密钥在几周或几个月未使用后会变为活动状态。

预测：随着团队部署更多代理工作流程和自动化 LLM 作业，关键级别异常检测将变得比每月发票审核更加重要。问题会以机器的速度发生，因此治理系统需要近乎实时的信号。

构建不会导致中断的轮换工作流程

通常会避免关键轮换，因为团队担心破坏生产。当轮换是手动且未跟踪时，这种担心是有道理的。更安全的轮换工作流程使用重叠的有效性窗口。

轮换操作手册

1. 使用相同或有意更新的政策创建替换密钥。
2. 将其存储在批准的机密管理器中并附加相同的所有者、应用程序和环境元数据。
3. 使用正常发布流程将新密钥部署到应用或工作负载。
4. 通过检查请求是否通过新密钥 ID 到达来确认流量转移。
5. 等待商定的观察窗口足够长的时间，以涵盖预定的作业和后台工作人员。
6. 仅在确认不再存在合法流量后才撤消旧密钥。
7. 记录完成情况，包括时间戳、所有者、原因和任何政策更改。

对于临时合作伙伴概念验证、短期开发密钥或一次性评估作业，请使用到期日期和自动提醒。对于生产工作负载，请选择与您的安全要求和部署成熟度相匹配的轮换间隔。生命周期非常短，可以减少暴露，但如果秘密部署不可靠，可能会造成中断。

权衡：轮换频率是一种平衡。较短的间隔可减少长期暴露。较长的间隔可减少运行噪音。自动化通过减少频繁轮换的破坏性来改变平衡。

在泄漏发生之前准备泄漏响应操作手册

泄漏响应不应从争论谁拥有密钥开始。治理系统应该使所有权、最近使用情况和撤销选项变得显而易见。

泄漏响应清单

1. 从泄露的值、前缀、哈希、密钥 ID、存储库查找或网关日志中识别密钥。
2. 使用密钥注册表查找所有者和环境。
3. 根据严重性和可用的连续性选项冻结或撤销密钥。
4. 检查最近的使用情况是否存在异常请求量、模型、区域、端点和成本。
5. 估计暴露程度，包括支出、数据访问和受影响的下游系统。
6. 如果密钥存储在其他凭据附近，则轮换相关机密。
7. 酌情通知利益相关者，例如所属团队、安全团队、财务团队、法律团队、合作伙伴经理或客户团队。
8. 记录根本原因，例如提交的机密、客户端暴露、复制笔记本、不安全的 CI 变量或合作伙伴处理不当。
9. 添加预防性控制，例如秘密扫描、缩短有效期、更严格的策略或部署更改。

事实：在浏览器或移动应用等客户端环境中公开 API 密钥被广泛认为是不安全的，因为分发到最终用户设备的机密可能会被提取。对移动应用程序生态系统的研究还报告了持续存在的 LLM API 凭证泄露问题，这进一步强调了将提供商凭证排除在分布式客户端之外的必要性。

通过委派访问权限处理合作伙伴集成

合作伙伴整合带来了一个特殊的治理问题。合作伙伴需要稳定的访问权限，但向他们提供原始提供商密钥会放弃过多的控制权并削弱归因。如果合作伙伴错误配置存储或超出约定的使用量，则提供商密钥所有者将承担运营和财务风险。

改为颁发合作伙伴范围的密钥或委派访问令牌。每个合作伙伴凭证都应有自己的配额、批准的端点、允许的用例、到期或续订日期以及支持路径。合作伙伴流量应与内部应用程序流量分开可见。

合作伙伴关键政策示例

合作伙伴：acme-integration
环境：生产
allowed_endpoints：[聊天]
allowed_models：[批准的低延迟模型]
每月预算美元：500
速率限制转速：60
最大输出令牌：800
内容日志记录：已禁用
更新审查：2026-12-31
support_contact：[email protected]

建议：以较低的默认配额启动合作伙伴密钥，并在观察到稳定的流量后增加它们。这可以保护双方：合作伙伴获得清晰的集成路径，平台所有者保持撤销和支出控制。

使用提供商原生控件，但不依赖于某个提供商的模型

提供商项目、工作区、服务帐户、预算警报、速率限制和使用报告都很有价值。使用它们。它们从源头上降低了风险，并可以提供额外的遏制层。

但是，多提供商团队很快就会遇到不一致的情况。一个提供商可能会公开关键级别的使用报告；另一个可能是围绕工作空间构建访问；另一个可能提供不同的管理 API 或计划门控。如果团队使用多个 LLM 提供商，治理应该规范它们之间的运营模型。

建议：即使存在提供商本机控制，也要维护内部密钥注册表和策略层。尽可能将内部密钥映射到提供商项目或工作区。这为安全、平台和财务团队提供了一个回答基本问题的地方：谁拥有此流量、应用了什么策略、成本是多少以及我们如何关闭它？

实施清单

• 创建包含所有者、应用、环境、用途、数据层、预算、到期时间和紧急联系人的密钥注册表。
• 将提供商密钥移至受限后端、网关或秘密管理服务中。
• 为团队、应用、环境、CI 作业和合作伙伴颁发受管密钥。
• 应用最低权限路由：允许的模型、端点、令牌限制、速率限制和预算上限。
• 独立的生产、准备、开发、CI 和合作伙伴访问。
• 需要为生产机器到机器工作负载提供服务帐户所有权。
• 捕获关键级别的使用遥测数据并在提供商之间对其进行标准化。
• 针对支出高峰、休眠密钥活动、新模型使用和异常网络来源设置异常警报。
• 集中实现重叠密钥轮换和轨道补全。
• 编写并测试泄漏响应操作手册。
• 默认情况下使用仅元数据日志记录，除非内容日志记录得到明确批准。
• 定期检查休眠、无主、过度许可和即将过期的密钥。

可行的结论

LLM API 密钥治理的目标不是减慢团队的速度。是为了让安全访问变得容易，让不安全访问变得不必要。共享的提供商密钥会造成所有权不明确、爆炸半径不受控制以及事件响应缓慢。受控密钥创建可管理的生命周期：请求、批准、发布、范围、监控、轮换和撤销。

从风险最高的领域开始：生产和合作伙伴访问。将提供商密钥置于受控层后面，颁发范围内的内部凭据，附加所有权元数据，并按密钥监控支出和使用情况。一旦基础到位，将相同的模式扩展到开发、CI、评估管道和临时实验。

最好的治理系统是开发人员可以实际使用的系统：快速请求、政策明确、默认可观察以及出现问题时可以安全撤销。

相关阅读

• 每个团队 LLM 成本分类帐