团队的 LLM API 密钥管理：隔离、轮换、支出限制和泄漏响应
用于跨团队管理 LLM API 密钥的实用操作模型：密钥隔离、仅代理访问、使用归因、支出控制、轮换和泄漏响应。
在第一次泄漏、无法解释的账单或生产中断之前，一个共享的 LLM API 密钥非常方便。 API 密钥管理的实际目标不仅仅是保密凭证。它是为了限制爆炸半径、属性使用、安全轮换、检测异常支出以及在不破坏不相关应用程序的情况下撤销访问权限。
本指南为团队提供了跨提供商、网关、内部应用程序、机构和面向客户的产品的 LLM API 密钥的操作模型。它将经过验证的安全事实与建议的实现选择分开，并避免假设每个提供商都公开相同的控制。
操作模型：每个键都需要一个边界
有用的密钥策略从一个问题开始：如果该密钥被滥用或撤销，什么会失败？如果答案是“整个公司”，则密钥太宽泛。
事实：OpenAI 的 API 密钥安全指南建议每个团队成员使用唯一的 API 密钥，并表示共享密钥违反其使用条款，并建议在支持的情况下向各个密钥分配权限。 OpenAI 的指南还建议不要在客户端环境（例如浏览器或移动应用程序）中部署 API 密钥，因为暴露的密钥可能会被滥用来代表所有者发出请求。
建议：围绕操作边界而不是便利性创建密钥。常见的边界包括：
- 环境：生产、暂存、开发、沙盒。
- 应用：聊天机器人后端、文档处理器、编码助手、分析工作流程。
- 所有者：团队、服务帐户、开发人员、代理客户、租户。
- 风险级别：面向公众的工作流程、内部自动化、批处理作业、实验性集成。
- 提供商或路由：上游提供商 A、提供商 B、批准的模型组或网关路由。
对于不断壮大的团队来说，一个好的默认设置是：每个应用程序或服务一个生产密钥，每个环境一个非生产密钥，以及用于高风险自动化或客户级使用的单独密钥。代理机构和经销商应该更喜欢客户级虚拟密钥，而不是共享上游提供商凭据。
切勿将提供商密钥放入分布式客户端
浏览器、移动应用、桌面扩展、公共插件和客户端脚本都是原始提供商凭据的敌对场所。即使您混淆了密钥，分布式软件也可以被检查、复制或拦截。
事实：OpenAI 明确警告不要在客户端环境中部署 API 密钥。对移动应用程序的研究还报告了 iOS 应用程序中持续存在的 LLM API 凭证泄露问题，这也支持了同样的实际警告：分布式客户端中嵌入的凭证往往会泄露。
建议：使用后端或网关模式：
- 客户端使用用户会话、JWT、客户令牌或短期凭据对您的应用进行身份验证。
- 您的后端会验证用户、租户、计划和请求的操作。
- 您的后端或 AI API 网关使用受保护的服务器端凭据调用上游 LLM 提供商。
- 经过政策检查、日志记录和成本核算后，响应将返回给客户端。
此设计可让您在支出发生之前强制执行产品规则。例如，免费计划用户可以仅限于较小的型号，付费租户可以获得更高的每日配额，内部管理工作流程可以使用具有更严格监控的单独路由。
在需要事件响应之前建立关键清单
团队经常在泄漏期间发现没有人知道哪个服务拥有暴露的密钥。这是库存失败。
事实：2023 年 OWASP API 安全前 10 名将库存管理不当列为主要 API 安全风险。对于 LLM 基础设施，关键清单是 API 清单的一部分：您需要知道存在哪些凭证、它们可以访问什么以及谁拥有它们。
建议：每个键都应该有元数据。至少，跟踪：
- 密钥名称和内部密钥 ID。
- 业主团队和紧急联系人。
- 环境：生产、暂存、开发、沙盒。
- 用途：应用、工作流程、租户、集成或开发人员使用。
- 允许的提供程序、模型、端点或路由（如果受支持）。
- 创建日期、上次使用时间戳和计划审核日期。
- 支出上限或配额。
- 轮换状态和链接的部署配置。
使用在警报中保持可读性的命名约定。例如：
<前><代码>prod-supportbot-teamcx-gpt4class-2026q3stg-docprocessor-平台-低成本-2026q3 租户-acme-产品-标准-2026q3 dev-jlee-sandbox-2026q3精确的格式比一致性更重要。目标是警报可以说“tenant-acme-prod-standard 超出了其每日阈值”，并且负责任的所有者知道该怎么做。
在平台允许的情况下应用最小权限
并非每个提供商或网关都公开相同的权限控制，但原则是一致的：密钥应该只能执行其工作负载所需的操作。
建议：通过以下一个或多个受支持的控件来限制按键：
- 项目：将密钥绑定到项目而不是整个组织。
- 型号：仅允许批准的型号；默认情况下阻止昂贵的或实验性的模型。
- 端点：允许聊天完成，但拒绝不相关的管理端点。
- 提供商路由：允许网关路由，而不是直接访问每个上游提供商。
- 速率：每分钟请求数或并发请求数上限。
- 预算：强制执行每个密钥、每个团队或每个租户的支出限制。
例如，暂存密钥通常不需要访问最昂贵的生产模型。文档分类工作人员可能不需要访问图像生成。面向客户的租户密钥不应消耗其他租户的预算。
分层设计支出控制
LLM API 安全性和成本控制重叠。泄露的密钥通常在被检测为安全事件之前被检测为计费异常。
事实：OpenAI 帐户安全指南建议合理的支出限制，并指出单独的 API 密钥可以使按功能、团队、产品或项目更容易查看使用情况。 OpenAI的使用报告还支持通过项目ID、用户ID、API密钥ID、模型、批次和服务层级等字段进行详细分析。
建议：使用分层限制而不是单一的全局上限：
- 每键限制：防止一个凭据耗尽整个预算。
- 每个团队的限制：保持部门使用情况可见且负责。
- 每租户限制：隔离 SaaS 和代理场景中的客户使用情况。
- 每日异常阈值：当使用情况偏离正常模式时触发警报。
- 全局紧急停止：允许在滥用行为发生时快速暂停。
硬限制很有用，但它们可能会中断合法的批处理作业。更安全的生产模式是一系列控制：
- 在预期每日支出的 50% 时发出提醒。
- 升级到 80%。
- 将非关键流量限制在 100%。
- 在使用全局关闭之前，仅阻止有问题的密钥、租户或路由。
权衡：严格的预算可以降低计费风险，但会带来可用性风险。按工作负载划分的层级限制：交互式生产流量、面向客户的付费流量、后台作业、实验和开发人员沙箱不应该都以同样的方式失败。
按关键参与者和逻辑参与者跟踪使用情况
密钥标识凭证。它可能无法识别引起请求的实际用户、租户、功能或工作流程。为了获得有用的人工智能使用分析，请记录技术和业务维度。
建议：在隐私和政策允许的情况下为每个请求收集以下字段：
- 请求 ID 和时间戳。
- API 密钥 ID 或虚拟密钥 ID。
- 应用、团队、租户、用户或工作流程标识符。
- 提供商、型号、路线和服务等级。
- 提示和完成令牌计数或等效使用单位。
- 预计成本。
- 延迟、状态代码、重试次数和错误类别。
不要将成本可观察性转变为不必要的数据收集。如果提示可能包含个人数据、客户机密或受监管内容，请避免默认存储完整提示。在许多情况下，哈希用户 ID、租户 ID、令牌计数和模型名称足以进行退款和异常检测。
无需停机轮换：安全的工作流程
事实：NIST 的密钥管理指南将密钥管理视为生命周期规则，包括生成、存储、激活、轮换、暂停、撤销和销毁。对于 LLM API 密钥，轮换不是一次性的安全杂务；这是一个可操作的工作流程。
建议：使用此无停机轮换流程：
- 创建替换密钥。匹配所需的权限、预算、路线和元数据。暂时不要撤销旧密钥。
- 将其存储在机密管理器中。避免本地文件、聊天消息、票证和粘贴的环境变量。
- 逐步部署配置。一次更新一项服务、区域、工作组或租户分段。
- 验证流量移动。确认请求是根据新密钥到达的，并且错误率和延迟保持正常。
- 冻结对旧密钥的写入。阻止新部署引用它。
- 撤销旧密钥。流量转移后，将其禁用，而不是将其作为被遗忘的备用密钥。
- 审核落后者。搜索旧密钥 ID 的日志、部署清单、秘密存储、CI 变量和运行时错误。
对于仍然使用静态环境变量的应用程序，旋转将很脆弱。转向动态秘密加载、集中配置或网关管理的虚拟密钥。至少，记录在撤销之前必须更改哪些部署。
泄漏响应操作手册
当密钥泄漏时，速度很重要。响应应该在事件发生之前写下，而不是在计费恐慌中即兴创作。
立即收容
- 撤销或暂停公开的密钥。
- 如果撤销会中断生产，请先发出替换通知并立即切换关键流量。
- 如果滥用行为仍然存在，则阻止路线、租户或提供商。
- 保留识别滥用所需的日志。
调查
- 确定密钥出现的位置：存储库、前端捆绑包、移动应用、日志文件、支持票证、供应商工具或聊天。
- 查找最后一次已知的合法用途。
- 比较可疑接触前后的使用情况。
- 查看所使用的模型、请求量、成本、地理位置（如果有）以及异常状态代码。
- 检查依赖秘密或相邻系统是否也可能被暴露。
恢复和预防
- 如果同一环境可能泄露了多个秘密，则轮换相关凭据。
- 在适当的时候通知所有者团队和受影响的客户利益相关者。
- 向存储库和 CI 管道添加秘密扫描。
- 通过将客户端调用移至后端或网关后面来防止重复发生。
- 记录事件时间表、根本原因、成本影响和控制改进。
预测：随着团队将更多的代理、插件、自动化工具和客户特定的工作流程连接到法学硕士，关键泄漏将越来越看起来首先是成本事件，其次是安全事件。具有逐键归因和预算控制的团队比使用单一共享凭据的团队能够更快地解决这些问题。
适用于多提供商团队的网关管理密钥
如果您的组织使用多个 LLM 提供商，直接提供商密钥可能会造成分散的治理：不同的仪表板、不同的计费视图、不同的权限模型和不一致的轮换流程。
网关管理的密钥层可以通过发布面向应用程序的密钥来简化这一过程，同时隐藏上游提供商凭据。应用程序调用与 OpenAI 兼容的 API 端点，而网关则处理路由、使用情况分析、计费归因和策略执行。
建议：在需要时考虑网关或代理层：
- 在一个地方管理多个提供商的团队密钥。
- 统一的 AI API 计费和每键支出报告。
- 适用于代理机构、经销商或 SaaS 租户的客户级虚拟密钥。
- 中央模型许可名单、路线政策和紧急暂停。
- 按租户、功能、工作流程或合作伙伴客户划分的使用归因。
权衡：网关改进了治理并隐藏了上游凭据，但它成为请求路径的一部分。像监控生产基础设施一样监控它：延迟、可用性、错误率、排队、重试行为和特定于提供商的故障都很重要。
实施清单
- 将组织范围内的共享密钥替换为按应用、环境、租户或工作流程划分的密钥。
- 从浏览器、移动应用、桌面扩展程序和公共脚本中删除原始提供商密钥。
- 通过后端或 AI API 网关路由客户端请求。
- 将所有者、目的、环境、允许的模型、预算和审核元数据附加到每个键。
- 应用最低权限：项目、端点、模型、路线、费率和预算控制（如果可用）。
- 设置每个密钥、每个团队、每个租户和全局支出限额。
- 记录密钥 ID、逻辑参与者、模型、令牌使用情况、估计成本、延迟和状态代码。
- 创建无停机轮换工作流程并在出现紧急情况之前对其进行测试。
- 编写泄漏响应操作手册，其中包含遏制、调查和预防步骤。
- 查看非活动密钥并撤销没有所有者或最近合法使用的任何内容。
可行的结论
从风险最高的密钥开始：在生产中使用、由多人共享、嵌入太多位置或负责最大支出的密钥。给它一个所有者，按边界分割它，添加预算，将它移到后端或网关后面（如果客户可以看到它），并记录如何轮换它。
然后重复。强大的 LLM API 密钥管理不是单一的秘密存储决策。它是一个生命周期：库存、隔离、最小权限、使用归因、成本控制、轮换和泄漏响应。回报很简单：当出现问题时，只有一个应用程序、租户或工作流程面临风险，而不是整个 AI 预算。