API 密钥管理不再是一项小型仪表板任务。对于使用 AI API 的团队来说，它是发送提示、接收模型输出、调用工具或花钱进行计量推理的每个应用程序的安全、成本和操作模型的一部分。
许多团队从本地环境文件中的一个提供程序密钥开始。直到相同的密钥出现在 CI 变量、笔记本、IDE 扩展、代理、批处理作业、客户集成和支持脚本中时，这种情况才会起作用。到那时，泄露的密钥不仅仅是一个身份验证问题。它可以公开提示和响应、触发意外费用、调用高级模型、使用应用程序权限运行工具或根据猜测进行事件响应。
本指南将 API 密钥管理视为生命周期：如何设计、颁发、存储、确定范围、监控、轮换和撤销密钥。它重点关注 AI API 访问，其中常见的 API 安全问题还包括模型访问、基于令牌的支出、多提供商凭据、客户归因和 OpenAI 兼容客户端。
API 密钥适合 API 安全性
API 密钥通常证明拥有凭据。它回答了这个问题：“这个调用者有一个有效的秘密吗？”它本身并不能回答所有重要的授权问题。
后端仍必须决定调用者是否可以访问特定租户、对象、模型、端点、工具、工作区、报告或管理功能。 OWASP API 十大安全风险（例如损坏的对象级授权、损坏的身份验证、不受限制的资源消耗和损坏的功能级授权）提醒我们有效的凭据只是系统的一层。
对于 AI API，这种区别很重要，因为相同的密钥可能能够执行具有截然不同风险状况的操作。可以为一个内部工作流程调用低成本文本模型的密钥不应自动调用高级模型、创建批处理作业、访问其他租户的数据、调用发送电子邮件的工具或管理结算设置。
持久的API安全模型可区分三个问题：
- 身份验证：证明请求具有有效的凭据、令牌或会话。
- Authorization: 决定经过身份验证的调用方可以在当前租户、环境和业务上下文中执行哪些操作。
- 治理： 限制支出、费率、模型访问、数据公开和管理控制，以便一个错误的影响范围有限。
API 键很有用，但它们不应该是保护敏感或高价值资源的唯一控件。将它们与 HTTPS、服务器端授权检查、审核日志、最低权限、速率限制、支出限制和安全秘密处理结合使用。
从实时 API 密钥清单开始
您无法管理无法命名的密钥。第一个实际步骤是实时清点 AI 系统使用的每个 API 密钥和类似凭证的对象。
每个密钥记录至少应包含密钥 ID、不可逆哈希或指纹、所有者、创建者、团队或租户、环境、工作负载、范围、允许的模型、允许的端点、支出政策、费率政策、IP 限制（如果适用）、状态、创建时间、到期时间、上次使用的时间戳、轮换组和审核元数据。
清单应涵盖的不仅仅是生产运行时密钥。包括个人开发者密钥、服务帐户密钥、CI/CD 密钥、工作区密钥、客户或租户密钥、经销商管理的密钥、记帐/报告密钥、管理 API 凭据和上游提供商凭据。
最重要的字段是所有权、用途、范围、上次使用和限制政策。如果没有它们，未来的每项安全任务都会变得更慢：卸载、轮换、泄漏响应、成本调查和客户支持。
故意设计密钥边界
最大的API密钥管理错误是使用一个密钥跨越太多边界。共享生产密钥一开始很方便，但它破坏了归属并使撤销具有破坏性。如果发生泄漏，您可能必须停止每项服务的流量，同时仍然无法确定哪个工作负载导致了问题。
良好的关键边界遵循业务和软件的形状。将生产与开发、人员与服务、客户与内部团队、租户彼此、运行时凭据与管理凭据以及网关颁发的客户密钥与上游提供商密钥分开。
环境边界
开发、暂存和生产应使用单独的密钥。开发密钥不应达到生产数据或生产预算。除非有严格控制的原因，暂存密钥不应有权访问实时客户工作负载。
工作负载边界
每个服务、批处理作业、代理队列、集成或计划任务都应有自己的密钥或服务帐户。这样您就可以回答基本问题：哪个工作负载花费了资金、哪个服务开始无法通过身份验证、哪个集成使用了已弃用的模型，以及在事件期间应冻结哪个密钥。
租户和客户边界
多租户系统需要归属和隔离。如果使用面向客户的 API 键提交提示，则请求应与客户、租户、应用程序以及最好是匿名的最终用户或参与者相关联。一个租户的密钥泄露后，不应允许访问另一租户的数据、模型配置文件、预算或日志。
提供商凭据边界
上游提供商密钥与您向客户或内部应用程序颁发的密钥不同。提供商凭据应保留在服务器端，存储在保管库或机密管理器中，并且永远不会发送到浏览器、移动应用程序、桌面客户端、公共笔记本或客户控制的环境。
网关可以在这方面提供帮助，方法是公开一个面向客户的密钥表面，同时将上游提供商凭据保留在网关后面。这使得跨提供商集中使用分析、撤销、团队控制和策略执行成为可能。如果您要围绕 OpenAI 兼容的 API 标准化客户端，则网关边界变得尤为重要，因为许多工具都需要单个基本 URL 和承载令牌。
对模型、端点、工具和支出应用最小权限
最小权限意味着密钥应仅具有其工作负载所需的访问权限。对于 AI 系统，范围不仅仅是 API 端点的列表。它还包括模型、工具、令牌预算、速率限制、租户、数据类和管理功能。
实用的 AI API 关键策略可以包括：
- 允许的模型系列或特定模型 ID。
- 允许的端点，例如聊天完成、嵌入、批处理作业或图像生成。
- 不允许的管理 API、运行时密钥的密钥管理 API、结算 API 和工作区管理 API。
- 每分钟请求和每分钟令牌的每密钥速率限制。
- 每个租户、每个团队或每个客户的支出限制。
- 高级模型控制，以便低风险工作流程不会突然使用最昂贵的模型。
- 工具权限，例如是否密钥可以调用外部连接器、代码执行、检索系统或业务操作。
- 用于稳定服务器端工作负载的 IP 许可名单，其中网络路径是可预测的。
支出控制是计量 AI API 的 API 安全性的一部分。即使密钥从未访问过敏感数据，泄露的密钥也会造成直接的财务损失。速率限制有所帮助，但还不够。代币数量、重试、批处理作业、工具调用和模型选择都会影响成本。安全的实施应将费率控制与支出上限、模型许可名单、异常检测和紧急冻结控制结合起来。
比较模型成本和访问策略的团队应保持安全和财务的一致性。模型定价不仅仅是采购问题；它决定了受损或配置错误的密钥可以花费什么。将批准的模型配置文件与预算挂钩，并在模型组合发生变化时对其进行审核，尤其是在使用AI 模型定价按成本和功能路由工作负载时。
将机密存储在其所属位置
API 密钥属于机密管理器、服务器端配置、受控 CI/CD 变量或保管库支持的网关。它们不属于源代码、浏览器JavaScript、移动捆绑包、桌面应用程序包、公共笔记本、屏幕截图、聊天消息、分析负载、支持票证或日志。
客户端暴露是一种常见的故障模式。如果提供商密钥嵌入在浏览器或移动应用程序中，则任何可以检查该应用程序的人都可以提取该密钥并代表帐户持有人提出请求。对于在不受控制的环境中运行的浏览器、移动应用程序、IDE 队列和代理，请使用服务器端代理或范围狭窄的短期委派凭据。请勿将长期提供者凭据分发给您无法控制的客户端。
CI/CD 需要同样的纪律。将键存储为受保护的变量。限制谁可以阅读或更改它们。避免在构建日志中打印环境变量。编辑失败的请求转储中的 Authorization 标头。将预览部署和分叉拉取请求视为受保护生产管道的不同信任区域。
日志和可观察性系统值得特别关注。存储关键指纹、请求 ID、租户 ID、模型 ID、响应状态、令牌计数器、成本计数器、IP 或客户端元数据（如果适用）以及策略决策。不要存储完整的API密钥。编辑跟踪记录、反向代理日志、异常报告、网络钩子负载、支持工具、分析事件和死信队列中的机密。
在紧急情况发生之前进行轮换
轮换并不是简单地删除一个密钥并创建另一个密钥。如果已部署的服务仍然依赖于旧密钥，则删除会导致停机。可靠的轮换过程使用重叠、观察和明确的退休点。
常见的模式是具有两个活动槽的轮换组。创建替换密钥，将其部署到每个依赖系统，观察旧密钥的最后使用情况，在流量移动时冻结旧密钥，并在信任窗口后将其删除。保持回滚规则明确：何时可以重新启用旧密钥、谁可以批准以及它可以保持可用多长时间？
短密钥生命周期可降低凭据过时的风险，但会增加运营负担。长期密钥可以减少部署流失，但它们为遗忘凭证和员工离职间隙创造了更大的窗口。正确的政策取决于工作量。高价值的生产服务帐户可能会按照固定的时间表自动化轮换。临时开发者密钥应该很快就会过期。客户管理的集成可能需要更长的迁移窗口和明确的弃用消息。
不要以相同的方式轮换每个密钥。可以列出、创建、删除或修改密钥的管理凭据比运行时推理密钥的风险更高，并且应该具有更强的控制、更窄的访问范围和更积极的监控。除非有经过审查的具体原因，否则运行时密钥不应具有管理权限。
检测泄漏和异常使用
当多个系统相互加强时，泄漏检测效果最佳。源代码控制秘密扫描可以捕获提交到存储库的密钥。 CI 检查可以在合并之前阻止明显的泄漏。自定义模式可以检测内部密钥格式。提供商仪表板可以显示异常活动。网关遥测可以显示新 IP、新地理位置、失败的身份验证突发、突然的支出速度或对意外模型的调用。
有用的安全仪表板包括休眠密钥、无所有者的密钥、无限制的密钥、即将过期的密钥、新网络使用的密钥、令牌快速增长的密钥、仍在接收流量的冻结密钥、失败的身份验证突发以及接近支出上限的客户密钥。
检测还应涵盖日志和异步系统。 Webhook、后台作业、队列和延迟完成需要请求 ID 和原始密钥属性。否则，可疑的回调或批处理结果可能无法关联到创建它的密钥和租户。
当密钥出现在 Git 历史记录中时，仅将其从存储库中删除是不够的。任何访问存储库、构建日志、镜像、分叉、包工件或缓存页面的人都可能已经复制了密钥。必须使凭据失效或冻结，然后进行替换。
响应泄露的 API 密钥
好的事件响应计划应该简短、经过排练且具体。第一个决定通常是是否冻结或撤销。冻结可以快速阻止交通，同时保留调查记录。撤销会永久禁用该密钥。有些团队在需要审计连续性和立即回滚选项时首先使用冻结；其他人会在确认公开泄密后自动撤销。这两种方法都需要自动化和明确的权限。
实用的响应流程如下所示：
- 根据严重性和可信度冻结或撤销可疑密钥。
- 识别所有者、租户、工作负载、范围、模型访问权限、支出政策和上次使用的时间线。
- 查看异常提示、模型、端点、工具、IP 的使用情况，令牌数量和成本。
- 评估受影响的数据、租户、下游操作和结算影响。
- 发出具有更正范围和限制的替换密钥。
- 消除根本原因，例如提交的机密、暴露的日志、过于宽泛的 CI 变量或客户端捆绑包。
- 添加预防控制，例如秘密扫描、日志编辑、更窄的范围、更短的有效期或支出警报。
- 记录事件并更新操作手册。
替换步骤不应重新产生相同的风险。如果密钥因在十个服务之间共享而泄漏，请用单独的服务帐户密钥替换它。如果它通过日志泄漏，请在发布新密钥之前修复日志记录。如果因为可以调用每个模型而超支，请添加模型许可名单和支出限制。
网关管理的密钥和多提供商 AI 访问
AI 团队经常使用多个模型提供商。每个提供商都有自己的关键模型、工作区结构、速率限制、模型名称、定价和管理 API。直接管理每个应用程序中的每个提供商密钥会增加运营风险。
网关管理的密钥模型可以降低这种复杂性。应用程序使用面向客户的密钥或内部密钥调用网关。网关对调用者进行身份验证，应用租户策略，实施模型和支出控制，记录使用情况，并在服务器端使用上游提供商凭据。这对于多模型应用程序、内部平台、代理机构和经销商服务非常有用。
对于 Model Gate，这就是网关角色的相关之处：集中的面向客户的密钥、统一的使用分析、团队控制、支出限制、IP 安全、Telegram 运营集成、合作伙伴 API 自动化和滥用响应。对于提供客户或下游服务的企业，合作伙伴API自动化可以使密钥创建、限制更新、冻结和经销商工作流程保持一致，而不是手动。
网关并不能免除应用程序团队的所有责任。您仍然需要安全存储、后端授权、租户隔离、端点设计、CI/CD 卫生、提示和响应数据策略以及提供者端限制（如果可用）。网关成为高价值的控制平面，因此需要强大的存储、审核日志、访问控制、可用性规划和管理分离。
常见的 API 密钥管理错误
最常见的错误是可以预测的。团队将提供商密钥直接放入客户端应用程序中。他们为每项服务和客户使用一个生产密钥。它们通过先删除、后部署来轮换。他们创建的密钥没有所有者、限制、范围或过期时间。他们记录完整的 Authorization 标头。他们仅依靠速率限制来控制人工智能成本。他们提供运行时服务管理凭据。他们从 Git 中删除了泄露的密钥，但没有撤销它。他们让员工离职，但保留个人密钥、本地环境文件和 CI 变量处于活动状态。
另一个微妙的错误是将提示和响应日志记录视为纯粹的操作。详细的日志可以帮助调查滥用行为，但它们也可能包含个人数据、客户内容、秘密或受监管的信息。元数据优先日志记录通常更安全：默认情况下捕获关键指纹、模型 ID、令牌计数、成本、状态代码、策略决策和请求 ID，然后需要受控访问以获取更深入的调试数据。
实施清单
强大的 API 密钥管理程序可以从重点清单开始：
- 创建所有密钥、所有者、环境、租户、范围、限制和限制的清单上次使用时间戳。
- 按环境、工作负载、租户、客户和凭据类别分隔密钥。
- 将提供商凭据移至服务器端并移出浏览器、移动应用、笔记本和公共客户端。
- 对模型、端点、工具、租户、预算和管理功能使用最低权限。
- 添加支出限制、费率限制、模型许可名单、异常警报和紧急冻结控制。
- 将机密存储在机密管理器、保管库、受保护的 CI 变量存储或网关管理的凭据系统中。
- 从日志、跟踪、分析、支持工具、网络钩子和错误报告中编辑机密。
- 通过重叠密钥、上次使用监控、冻结和最终实现轮换删除。
- 在存储库和 CI/CD 中集成秘密扫描，包括自定义密钥模式。
- 记录个人密钥、服务帐户、工作区密钥和客户密钥的卸载行为。
- 将运行时推理凭据与管理提供程序凭据分开。
- 在真正的泄漏强制执行之前测试事件响应流程。
结论
API AI API 的密钥管理涉及控制身份、权限、成本和操作爆炸半径。安全密钥不仅仅是一个随机字符串。它具有所有者、目的、范围、环境、预算、有效期、轮换路径、审核跟踪和事件响应计划。
实际目标不是围绕每个请求创建官僚机构。它是为了让正常工作更安全：开发人员可以构建，服务可以运行，客户可以配置，安全团队可以回答密钥泄漏或支出激增时发生的情况。从库存和边界开始，然后添加最低权限、安全存储、轮换、监控和响应自动化。对于多提供商 AI 访问，网关可以集中大部分控制，但应用程序授权和秘密卫生仍然是核心工程职责。