OpenAI 已将工作负载身份联合资源添加到其官方 SDK 中，并发布了用于验证 API 和 Codex 自动化的文档，而无需存储长期的 OpenAI 凭据。
系统接受受支持的云、CI 和工作负载平台颁发的身份，然后将其交换为短期的 OpenAI 访问令牌。 OpenAI 记录了对身份源的支持，包括 Amazon Web Services、Microsoft Azure、Google 云、Oracle 云、Kubernetes、GitHub 操作和 SPIFFE 兼容环境。
这不仅仅是 SDK 的便利。它为组织提供了一种将现有工作负载身份系统连接到 OpenAI 的方法，并限制因泄漏、复制或旋转不当的 API 密钥造成的损害。它还改变了网关和开发者平台在代表客户对自动化工作负载进行身份验证时需要记录的内容。
OpenAI工作负载身份联合的工作原理
工作负载首先从其本机环境获取凭据。根据平台和 OpenAI 服务，该身份可以通过 OpenID Connect、SPIFFE 或 X.509 证书表示。然后将其交换为临时 OpenAI 访问令牌，而不是使用应用程序配置中嵌入的持久 API 密钥。
OpenAI 将配置分为工作负载身份提供程序和联合规则。提供商确定哪个外部身份系统是可信的。联合规则确定该系统中的身份如何映射到 OpenAI.
对于 OpenAI API 工作负载，可以将外部身份映射到项目服务帐户。在托管的 Codex 环境中，OpenAI 记录到工作区用户或服务帐户的映射。这种区别很重要，因为无人值守的后端进程通常不应继承与单个开发人员相同的身份和权限。
11 月 3 日发布的官方 Python 和节点 SDK 添加了用于管理工作负载身份提供程序和联合规则的生成资源。 OpenAI 不过，尚未发布单独的发布文章来定义确切的部署范围，因此组织应在计划迁移之前确认帐户资格和配置可用性。
为什么短期凭据很重要
传统 API 密钥很简单，但会带来运营责任。复制到 CI 变量、容器映像或部署脚本中的密钥可能仍然有用，直到有人轮换或撤销它。联合使用从工作负载已拥有的身份派生的访问令牌取代该常设凭据，该访问令牌会在有限期限后过期。
实际好处是缩小暴露范围，而不是免受损害。在授权环境中运行的恶意进程仍可能请求令牌并调用API。因此，团队需要限制性的联合规则、范围狭窄的 OpenAI 服务帐户、对外部身份颁发者的控制以及将每个令牌交换连接到启动它的工作负载的日志。
GitHub 操作是一种直接用例。组织可以使用工作流的身份，而不是在存储库或组织机密中放置可重用的 OpenAI 密钥。云托管服务和 Kubernetes 工作负载可以通过其本机身份系统遵循相同的一般模式。
网关和合作伙伴平台的后果
联合为开发者团队使用的任何AI API控制平面引入了新的身份验证路径。平台不能再假设每个上游请求都由静态客户密钥授权。它可能需要保留外部工作负载身份、获取或接受短期令牌，并将使用情况与正确的 OpenAI 项目服务帐户相关联。
对于多模型网关，该功能还突出了可移植性问题。即使推理请求共享 OpenAI 兼容格式，身份联合也是特定于提供者的。跨供应商支持它需要单独的信任配置、令牌交换逻辑、到期处理和故障报告。统一端点不会自动创建统一身份模型。
同样的问题也适用于 AI API 经销商平台。将每个客户工作负载映射到范围狭窄的服务帐户比共享组织级凭据更安全，但平台必须防止一个租户的外部身份解析为另一个租户的 OpenAI 项目。审核记录应保留外部身份、联合规则、映射的 OpenAI 主体和结果使用属性。
Model Gate 和类似的合作伙伴平台可以评估联合，将其作为受支持企业集成的客户提供的提供商密钥的替代方案。这样做需要明确的租户隔离和生命周期处理，而不是将临时令牌视为普通的 API 密钥。
尚不清楚的内容
文档建立了身份验证模型和支持的身份提供商类别，但一些部署问题仍然是特定于帐户的。 OpenAI 没有在独立公告中明确说明哪些计划或组织可以立即配置联盟。添加的 SDK 显示了客户端支持，但 SDK 类型本身并不能确认每个帐户都具有相应的后端权利。
还有一个需要注意的服务级别差异：OpenAI 记录了 API 路径的 X.509 联合，但没有记录 Codex 路径的 X.509 联合。团队应验证其预期服务支持的凭据类型，而不是假设每种身份机制都统一适用。
采用该功能的组织应在删除现有密钥之前测试令牌获取、过期、撤销和回退行为。主要的好处是更小的长期凭证足迹。真正的安全性仍然依赖于精确的身份映射、受限的服务帐户以及通过身份验证、推理和计费跟踪工作负载的审核跟踪。