如何为生产工作负载设计 LLM 服务帐户

生产 LLM 工作负载不应以人​​员身份进行身份验证。 CI 作业、后端服务、代理运行程序、批处理处理器或面向合作伙伴的网关需要自己的非人类身份，具有明确的所有者、狭窄的范围、预算、审计跟踪和关闭路径。如果没有该模型，一个泄露的密钥可能代表过多的系统，关闭并不会删除访问权限，并且使用情况报告无法解释哪些工作负载造成了成本或风险。

本指南为工程和平台团队提供了跨提供商 API 和内部网关的 LLM 服务帐户治理的实用设计。它将经过验证的提供商事实与实施建议分开，并提出运营模型可能发展的预测。

什么是 LLM 服务帐户？

事实： 服务帐户是应用程序和工作负载而不是个人用户使用的非人类身份。 OpenAI API 项目支持项目范围的服务帐户和 API 密钥。 Anthropic 将服务帐户描述为组织内的指定非人类身份。 GoogleCloud IAM 将服务帐号描述为应用程序和工作负载的非人类用户。

对于 LLM 系统，服务帐号应代表工作负载边界：一个后端服务、一个 CI 工作流程系列、一个代理运行时、一个批处理管道或一个合作伙伴 API 集成层。它不应代表一个人、整个公司或环境中的每个应用程序。

有用的服务帐户记录可以回答五个问题：

• 哪个应用程序或工作流程拥有此身份？
• 可以在哪些环境中运行？
• 哪个团队负责费用、访问权限和事件？
• 允许哪些模型、端点、工具、数据政策和区域？
• 凭证如何轮换、撤销或替换为联合？

何时创建服务帐户

当调用者是可操作的软件而不是人类时，创建服务帐户。常见示例包括运行评估的 CI/CD 作业、生产 API 服务、文档处理工作人员、客户支持副驾驶、自主代理队列、计划的丰富作业以及为许多团队代理 LLM 访问的内部开发人员平台。

不要为每个开发者、每个本地实验或每个提示创建新的服务帐户。人类探索属于用户身份和短暂的开发凭证。提示级别和功能级别归因可以捕获为工作负载身份下的请求元数据。

简单的决策规则效果很好：

• 如果调用者可以在无人值守的情况下运行，请使用服务帐户。
• 如果调用方提供生产流量，请根据工作负载和环境使用服务帐号。
• 如果调用方代表客户或合作伙伴，请将工作负载身份与委托租户身份分开。
• 如果调用者是使用控制台或笔记本的人，请勿将其隐藏在生产服务帐户后面。

从身份清单开始

迁移应从库存开始，而不是从密钥轮换开始。团队经常发现生产服务、暂存作业、本地脚本、评估管道和废弃的集成使用一个提供程序密钥。首先轮换该密钥会带来风险，但不会提高所有权。

建立包含以下类别的库存：

• 人工拥有的提供商API密钥。
• 工作负载服务帐户。
• CI/CD 身份。
• 网关颁发的内部密钥。
• 合作伙伴或客户委托的密钥。
• 紧急打破玻璃凭证。
• 仍然产生使用的未知密钥。

对于每个凭据、记录提供商、项目或工作区、密钥所有者、使用应用程序、部署环境、秘密位置、允许的模型、支出所有者、上次查看的时间戳和吊销风险。该清单成为LLM API密钥管理的真实来源，但服务帐户应建模为一流的工作负载身份，而不仅仅是另一个密钥标签。

每个工作负载边界使用一个服务帐户

主要的设计选择是粒度。创建共享爆炸半径的服务帐户太少。太多会产生运营噪音。正确的单位是具有不同所有权、权限、成本概况或事件响应需求的最小工作负载边界。

使用单独的服务帐户：

• 生产和非生产环境。
• 不同团队拥有不同的应用程序。
• 面向客户的服务与内部工作。
• 交互式请求路径与异步批处理器。
• 可以调用工具或运行循环的代理运行时。
• 合作伙伴 API 公开委托访问权限的表面。

实用的命名模式是：

llm-sa-{app}-{env}-{team}-{purpose}

示例：

llm-sa-supportbot-prod-cx-chat
llm-sa-contracts-stg-legal-extract
llm-sa-evals-ci-platform-regression
llm-sa-agentrunner-prod-eng-tools

请勿在帐户名称中对机密、客户名称、个人姓名或临时票号进行编码。将可变详细信息放入标签或元数据中。

将提供商帐户映射到网关身份模型

事实：提供商的功能有所不同。 OpenAI 支持 API 项目内的服务帐户，并且项目服务帐户对于创建它们的项目来说是唯一的。 Anthropic 工作区可以包含成员、服务帐户、API 密钥和资源限制。 Anthropic 工作负载身份联合允许工作负载使用签名身份令牌而不是静态 Anthropic 凭据，并在配置时将属性和速率限制与工作区相关联。

建议：即使存在提供商本机服务帐户，也要保留网关级服务帐户模型。网关身份应该是政策、报告、预算和审计证据所附加的稳定的内部对象。然后，提供者凭据就是映射在其下方的实现详细信息。

例如：

internal_service_account:
  id: sa_01h_supportbot_prod
  name: llm-sa-supportbot-prod-cx-chat
  owner_team: customer_experience
  environment: production
  app: supportbot
  allowed_models:
    - provider: openai
      model_family: gpt-4.1
    - provider: anthropic
      model_family: claude-sonnet
  data_policy: no_training_required
  monthly_budget_usd: 2500
  provider_bindings:
    openai_project: proj_supportbot_prod
    anthropic_workspace: ws_supportbot_prod

此映射在多模型 AI API 网关中很重要，因为上游提供商会公开不同的帐户结构、结算字段、模型权限和联合选项。单个内部身份层可让团队执行一份政策合同，同时仍保留特定于提供商的上下文以进行故障排除。

权限范围狭窄

服务帐户的范围应根据工作负载的需求来确定，而不是根据提供程序密钥允许的范围来确定。至少要跨这些维度定义范围：

• 提供程序边界：可以使用哪些提供程序以及提供程序项目或工作区。
• 模型边界：允许的模型系列、版本、预览模型和后备模型。
• 端点边界：聊天、响应、嵌入、批处理、文件、微调、助手、工具或管理 API。
• 环境边界：开发、暂存、生产、沙盒或合作伙伴。
• 数据边界：保留政策、区域、敏感数据类别和允许的有状态功能。
• 预算边界：软警报、硬上限、每分钟限制和每月限制。
• 网络边界：接受的源网络、工作负载身份或部署平台。

管理API权限几乎不应该可供运行时服务帐户使用。将配置自动化与推理工作负载分开。发送提示的后端服务不应还能够创建新的提供商密钥、更改预算或授予模型访问权限。

在实用的情况下，优先选择联合而不是静态密钥

事实： Anthropic 将工作负载身份联合记录为工作负载使用签名身份令牌而不是静态 Anthropic 凭据的一种方式。 Google Cloud 警告称，如果不仔细管理，用户管理的服务帐户密钥会存在安全风险，并在可能的情况下建议更安全的替代方案。 OWASP 建议尽可能集中秘密存储、审核秘密请求和使用、轮换、撤销和过期。

建议： 对于存在提供商支持的云托管服务和 CI/CD 系统，首选工作负载身份联合或短期令牌交换。仅当联合不可用、不受您所需的提供程序路径支持或对于低风险工作负载操作不合理时，才使用静态 API 键。

联合流程通常如下所示：

1. 工作负载在云、CI 或身份提供商主体下运行。
2. 工作负载从上游身份提供商获取签名身份令牌。
3. LLM 提供商或内部网关验证颁发者、受众、主题和声明。
4. 网关将令牌映射到内部服务帐户。
5. 网关发出短期会话或直接授权 LLM 请求。

验证的不仅仅是发行者。检查受众、主题、存储库或工作负载路径、环境、分支或部署声明（如果可用）以及令牌生命周期。联合将风险从静态秘密泄漏转移到身份提供商配置。薄弱的声明、广泛的信任策略或宽松的 CI 环境仍然可能授予意外的访问权限。

每个请求都需要属性元数据

服务帐户可识别工作负载，但它们不应是唯一的归因字段。生产 LLM 请求需要足够的元数据来快速回答运营问题。

在网关处需要这些字段：

• service_account_id
• app
• environment
• owner_team
• deployment_id或发布版本
• request_purpose，例如聊天、提取、分类、评估或agent_tool_use
• tenant_id或客户标识符（如果适用）
• workflow_id 或异步工作的作业标识符

这些字段支持LLM API成本归因、事件响应、速率限制决策和提供商发票核对。它们还可以防止常见的故障模式，即来自共享密钥的每个请求仅标记为“后端”。

将预算和提醒附加到工作负载标识

服务帐户通常在无人值守的情况下运行。这使得成本控制变得更加重要，而不是更少。用户可能会注意到失控的聊天会话。计划的代理或重试批处理作业可能会在一夜之间耗尽预算。

设置多层预算：

• 提供受支持的项目或工作区预算。
• 每个服务帐户的网关级每月预算。
• 针对突然峰值的短窗口异常检测。
• 每个请求或每个作业的最高预估费用。
• 生产、暂存、CI 和评估工作负载的单独限制。

针对不同的阈值使用不同的操作。达到 50% 时，通知所有者团队。 80% 时，需要确认。在 100% 时，要么阻止非关键请求，要么降级到更便宜的批准模型，要么需要显式覆盖。正确的行为取决于工作负载是面向客户的、内部的、批量的还是安全关键的。

设计生命周期工作流程

没有生命周期控制的服务帐户将成为另一个不受管理的密钥。在广泛采用之前定义工作流程。

请求

请求者必须提供应用名称、环境、所有者团队、业务目的、预期每月支出、数据分类、模型要求、端点要求以及是否可以联合。

批准

批准应来自所有者团队和平台或安全政策。高预算、敏感数据、面向合作伙伴或使用工具的工作负载应比低风险的内部汇总作业需要更严格的审核。

配置

创建内部服务帐户、提供商绑定、预算、模型政策、审核接收器以及秘密或联合信任。尽可能通过自动化而不是手动控制台工作进行配置。

秘密递送

如果需要静态密钥，请仅将其传送到集中式秘密管理器或部署平台。请勿通过聊天、票证、本地文件或文档页面发送密钥。

评论

以固定的节奏审核服务帐户。确认所有者团队、上次使用情况、权限、预算、模型访问权限、数据政策以及是否可以用联合替换静态密钥。

禁用和删除

删除前禁用未使用的服务帐户。如果缺少工作负载依赖性，这将创建一个恢复窗口。隔离期结束后，删除帐户并撤销所有提供商绑定和机密。

记录审核员和响应员所需的事件

审核日志应涵盖控制平面和数据平面活动。至少记录：

• 服务帐户创建、更新、停用和删除。
• 凭据创建、读取、轮换和撤销。
• 联合信任创建和声明政策更改。
• 权限、模型访问、端点访问和数据政策更改。
• 每个 LLM 请求均包含服务帐户、租户、模型、提供商、令牌使用情况、估算费用、状态和请求目的。
• 预算阈值事件、硬限制块和手动覆盖。
• 管理 API 影响提供程序项目、工作区、服务帐户或密钥的调用。

将这些事件发送到不可变或防篡改的审核流。如果有助于控制存储成本，请将高基数请求遥测与长期保留审核证据分开，但保留调查所需的连接密钥。

共享密钥的迁移计划

可以逐步替换共享密钥。除非密钥已被泄露，否则请避免大爆炸迁移。

1. 识别最繁忙的共享密钥。按支出、流量、模型访问权限和未知所有权进行排名。
2. 将调用者分组到工作负载边界。使用日志、源存储库、部署变量、用户代理和网络源数据。
3. 创建范围服务帐户。从拥有明确所有者、高支出或高风险的生产工作负载开始。
4. 通过网关进行路由。如果直接提供程序迁移需要更长时间，请暂时保留网关后面的旧提供程序密钥。
5. 双运行归因。在完全切换之前比较流量、费用、错误、延迟和提供商计费。
6. 轮换调用者。一次更新一个工作负载的部署机密、CI 变量和应用配置。
7. 撤销共享密钥。如果爆炸半径不清楚，先隔离，观察窗口期后再撤销。

我们的目标不仅仅是轮换密钥。目标是用工作负载拥有的身份、政策、预算和证据取代不明确的访问。

明确的权衡

更多的服务帐户可以改善控制，同时增强管理。命名约定、所有权元数据、清理作业和审核工作流程使模型保持可用。

联合降低了静态秘密风险，但增加了身份提供商依赖性。令牌交换可能会因发行者更改、声明漂移、时钟偏差或 CI 配置更改而失败。设计清晰的故障模式和警报。

提供商本机控制很有价值，但不一致。某些提供商以不同方式公开项目、工作区、服务帐户、预算或联合。网关级身份层提供一致的政策和报告，但它必须保留配额、计费和支持调查的上游上下文。

短期凭据可提高安全性，但会增加运行时复杂性。仔细缓存令牌，遵守过期时间，并避免使每个 LLM 请求都依赖于缓慢的控制平面调用。

集中执行可以改善治理，但也提高了平台责任。如果网关拥有政策、预算和归属，则它必须具有高度可观察性且运营成熟。

实施清单

• 创建人员密钥、工作负载身份、CI 身份、合作伙伴密钥和 Break-glass 凭据的清单。
• 定义包含应用、环境、所有者团队和用途的命名约定。
• 每个生产工作负载边界使用一个服务帐户。
• 将每个身份绑定到缩小的提供商项目或工作区。
• 限制模型系列、端点、区域、数据政策和预算。
• 在支持的情况下首选联合或短期令牌交换。
• 仅在集中式秘密管理中存储静态密钥。
• 每个请求都需要归因元数据。
• 设置服务帐户预算和异常警报。
• 记录凭据、权限、请求、预算和撤销事件。
• 在删除未使用的帐户之前先将其禁用。
• 按工作负载迁移共享密钥，然后吊销旧凭据。

结论

LLM 服务帐户治理是生产 AI 访问的操作模型。将每个无人值守的调用者视为具有所有者、目的、权限边界、预算和生命周期的工作负载身份。在有帮助的地方使用提供商本机服务帐户，在可行的情况下首选联合，并在网关处标准化身份，以便 OpenAI、Anthropic、Gemini 和内部系统能够得到一致的管理。

预测：LLM 平台将继续从广泛的静态密钥转向服务帐户和工作负载身份模型。现在建立干净的工作负载所有权的团队稍后将可以更轻松地进行提供商联合、审核准备、合作伙伴API治理和可靠的成本控制。

相关阅读

• API团队的关键治理