OpenAI Workload Identity Federation：CI/CD 与 Coding Agent 的无密钥 API 认证 — 附 Admin API 模型白名单、消费告警配置

5 月 26 日，OpenAI API 上线了两项变更，大多数团队尚未充分消化。第一项是工作负载身份联合（workload identity federation）——一种无密钥认证机制，允许 CI/CD 流水线、云函数和 agent runtime 用 OIDC token 换取短期 OpenAI 访问令牌，无需存储长期 API key。第二项是一组 Admin API 新增能力：按项目的模型 allowlist/denylist、消费告警、数据保留控制和细粒度账单明细。这两项都不是模型发布，但合在一起，它们改变了任何规模化运行 OpenAI 的团队的治理姿态。

发生了什么

5 月 26 日，OpenAI 发布了两项相互关联的治理功能：

工作负载身份联合允许受信任的工作负载用外部签发的 OIDC JWT token 换取短期 OpenAI 访问令牌。流程分四步：注册工作负载身份提供商（你的 OIDC issuer、audience 和密钥来源），创建服务账号映射（授权特定 token 属性铸造 OpenAI token），配置工作负载执行 token 交换，最后用生成的短期 bearer token 发起 API 调用。该功能在 Organization Settings > Security > Workload Identity Provider 中配置。支持的提供商包括 AWS、GCP、Azure、GitHub Actions 以及任何兼容 OIDC 的 issuer。

Admin API 扩展新增了四项能力：

• 按项目的模型 allowlist/denylist：设置 mode: "allow_list" 加指定模型 ID，限制项目可调用的模型；或设置 mode: "deny_list" 屏蔽特定模型，允许其余所有模型。
• 消费告警：为每个项目配置月度消费阈值，触发时发送邮件通知。阈值单位为美分。
• 数据保留控制：在项目级别覆盖或继承组织的数据保留策略。
• 细粒度账单明细：以比现有用量仪表盘更细的粒度查询账单数据。

这些 Admin API 功能需要 Admin API key（与普通 API key 分开），支持 Node SDK 6.36.0+、Python SDK 2.34.0+、Go 3.34.0+、Ruby 0.61.0+、Java 4.34.0+。

为什么 AI 工程团队需要关注

长期 API key 是 AI 基础设施中最大的凭证风险。 大多数团队今天将 OpenAI API key 存储为环境变量或 secrets manager 条目，手动轮换，并在多个服务间共享。工作负载身份联合为已有 OIDC 身份的工作负载消除了这一模式——几乎涵盖所有现代 CI/CD 流水线、云函数和 Kubernetes 工作负载。短期 token 自动过期，无需轮换，不会泄露到 git commit，也无需在发生安全事件后撤销。

对于在 CI 中运行 coding agent（Codex、Claude Code 等）的团队，这一点尤为重要。这些 agent 会发起大量 API 调用，且通常运行在 secret 管理操作复杂的环境中。基于 OIDC 的流程将 API 访问权限绑定到工作负载现有的云身份，而非独立的凭证。

模型白名单是一种路由治理原语。 通过 API 而非仅通过仪表盘限制项目可调用的模型，意味着你可以以编程方式执行模型策略。出于成本考虑只应使用 gpt-4.1 的项目，可以在 API 层面锁定，而不仅仅依靠约定。出于延迟考虑不应调用 o3 的项目，可以将其屏蔽。这类控制此前需要代理层来执行。

消费告警填补了用量与账单之间的空白。 现有用量仪表盘是事后展示。按项目配置可调阈值和邮件通知的消费告警，让团队在失控用量变成账单意外之前就能发现。结合细粒度账单明细，财务和平台团队无需构建自定义用量抓取流水线，就能获得成本分摊和归因所需的数据。

Router/Operator 视角分析

对于通过 gateway 路由 OpenAI 流量的团队，这些变更既带来机会，也引入了新的配置面：

无密钥认证改变了 gateway 的凭证模型。 如果你的 gateway 目前向出站请求注入 OpenAI API key，工作负载身份联合提供了一种替代方案：将 gateway 本身配置为受信任的工作负载，用其云身份换取短期 OpenAI token，并在一批请求的生命周期内使用该 token。这消除了 gateway 对存储 API key 的依赖。代价是 token 交换增加了一次往返延迟，且要求 gateway 具有 OIDC 身份——在 AWS/GCP/Azure 上很直接，但需要配置。

模型白名单与你的路由策略相互作用。 如果你跨多个 OpenAI 项目路由请求（例如每个团队或每个成本中心一个项目），模型白名单让你在 API 层面执行不同的模型策略。将 GPT-5.5 请求路由到 project_a、将 GPT-4.1 请求路由到 project_b 的路由规则，现在可以由 API 层面的执行来支撑，而不仅仅依赖 gateway 正确路由每个请求。这是路由策略的纵深防御。

消费告警是 gateway 层面限流的补充。 Gateway rate limit 防止突发流量；消费告警防止在 rate limit 范围内持续的高成本用量。为某个项目设置每月 $500 预算的团队，可以在 $400 时设置告警以获得早期预警。这对 agent 工作负载尤为有用——单个失控任务可能在数小时内消耗一个月的预算。

账单明细支持无需抓取的对账。 如果你的平台团队按项目或团队做成本分摊，新的细粒度账单明细提供了结构化 API 来拉取数据，而不是解析用量仪表盘。对于拥有多个项目的团队，这是一项有意义的运营改进。

5 月 26 日变更 Operator 检查清单：

1. 审计你的 API key 存储。 识别哪些工作负载使用长期 OpenAI API key，哪些已有 OIDC 身份（AWS IAM role、GCP service account、GitHub Actions OIDC 等）。有 OIDC 身份的工作负载是迁移到工作负载身份联合的候选。

2. 为成本敏感项目设置模型白名单。 如果你有模型选择是成本控制问题的项目，现在就配置白名单。这是一次性设置，提供持续执行。

3. 在下个账单周期前配置消费告警。 为每个项目设置预期月度消费 80% 的阈值。邮件通知是低摩擦的早期预警系统。

4. 更新 Admin API SDK 版本。 新功能需要 Node 6.36.0+、Python 2.34.0+、Go 3.34.0+、Ruby 0.61.0+、Java 4.34.0+。在针对新端点编写自动化之前，检查当前版本。

5. 评估 gateway 凭证架构。 如果你的 gateway 存储 OpenAI API key，评估工作负载身份联合是否更符合你的安全姿态。token 交换增加延迟，但消除了凭证轮换开销。

TheRouter 用户应关注什么

对于使用 TheRouter 跨多个 provider（包括 OpenAI）路由流量的团队，模型白名单功能值得纳入治理模型。如果你按团队或用例使用独立的 OpenAI 项目，模型白名单让你在两个层面执行路由策略：TheRouter 的路由规则和 OpenAI 项目级 API 执行。这是模型选择的双重保障治理。

工作负载身份联合功能最适合在具有现有 OIDC 身份的云环境中运行 TheRouter 部署的情况。在这种情况下，你可以从 TheRouter 配置中消除存储的 OpenAI API key，用 token 交换流程替代。这是值得在生产部署中评估的安全改进。

关注 OpenAI API changelog 的后续 Admin API 新增——5 月 26 日的发布增加了消费告警和模型白名单，但这一模式表明更多可编程治理控制正在路上。