OpenAI 现支持按服务账号创建作用域 API 密钥——多项目运营商必读

OpenAI Python SDK v2.46.0 新增端点,支持为单个项目服务账号创建并列出作用域 API 密钥。对多项目 AI 路由团队而言,这一更新补上了迫使流水线使用全组织密钥的凭证蔓延漏洞。

发布于 来源 OpenAI

归档条目:由 AI 根据所引信源辅助生成,发布时未经逐篇审阅。责任编辑:Joe Werner。

一张简洁的编辑风格示意图,展示项目树结构中的各个服务账号,每个账号持有一个作用域 API 密钥,并连接至路由网关层。

对于在多团队 OpenAI 部署中管理 API 凭证的工程团队来说,这个令人头疼的问题终于有了针对性的解决方案。OpenAI Python SDK v2.46.0 今日发布,向 Admin API 开放了一个新端点,支持运营商为单个项目服务账号创建并列出专属 API 密钥——而非绑定到整个组织。

对于通过 CI/CD 流水线、预发布环境或按团队部署来路由至 OpenAI 的团队,这一更新影响重大。此前,密钥的可编程下发路径只有项目级或组织级,迫使团队赋予流水线超出实际需要的宽泛权限。

发生了什么

v2.46.0 SDK 版本新增了三项相关能力:

1. 按服务账号创建 API 密钥。 client.admin.organization.projects.service_accounts 下新增 create_api_key 方法,对应端点 /organization/projects/{project_id}/service_accounts/{service_account_id}/api_keys。调用时传入 name 和 scopes 数组——后者是一个显式权限列表,明确规定该密钥可执行的操作。

2. 密钥列表新增 owner_project_access 过滤参数。 组织 API 密钥的 list 方法现在接受 owner_project_access,允许运营商按服务账号或项目过滤密钥清单。这是首次让按工作负载审计活跃凭证变得可行,无需导出完整密钥列表。

3. Beta 别名清理。 同步提交移除了组织 API 首次公开以来积累的遗留 beta 资源访问器,Admin API 接口面向自动化构建者更加整洁。

源码 SDK 提交为 5a0094194eac9c605c8ca84d47d1c5518f8e2131,该变更已在 openai-python>=2.46.0 中生效。

为什么 AI 工程团队应该关注

凭证蔓延是多项目 AI 部署中最隐蔽的风险。过去的常见模式:团队在 CI 流水线中需要自动化访问 OpenAI,于是在初始化时生成一个项目级密钥,写入环境变量,然后置之不理。几个月后,这个密钥已经在无关的运行任务中积累了大量使用记录,轮换困难,撤销则会波及整条流水线。

服务账号密钥创建端点从根本上改变了这一架构:

  • 每条流水线对应一个服务账号。 为部署流水线、CI 环境或 coding agent 工作负载单独创建服务账号。
  • 密钥作用域绑定至该账号。 创建的 API 密钥仅限于该服务账号的 scopes 列表,而非宽泛的项目级密钥。
  • 按工作负载轮换,而非按项目轮换。 轮换某条流水线的密钥,不会影响服务其他工作负载的凭证。

这一变化对使用 OpenAI 兼容路由网关的团队尤为重要。向多个 OpenAI 上游项目分发请求的网关,现在可以为每个被路由项目持有各自专属的服务账号密钥,而非共用一个宽泛密钥。这直接降低了凭证泄露的爆炸半径。

路由器/运营商视角分析

对于跨多团队或多环境向 OpenAI 路由请求的 AI 网关运营商而言,scopes 参数是此次最重要的新增内容。它允许精确指定密钥的权限范围——模型推理、微调、管理操作——而不是继承服务账号在项目中的全部角色权限。

具体来看:服务 coding agent(如 Cursor、Claude Code、VS Code Copilot)的路由网关,现在可以持有仅限模型推理调用的专用密钥。管理操作所需的独立密钥完全脱离运行时数据路径。

密钥列表的 owner_project_access 过滤也帮助运营商维护每个项目的活跃凭证实时清单,便于治理审计:哪些密钥由自动化创建,哪些由人工创建;哪些即将到期;哪些服务账号拥有跨多个项目的密钥。

v2.46.0 升级运营商 Checklist:

  1. 审计现有服务账号。 使用 client.admin.organization.projects.service_accounts.list(project_id=...) 盘点每个项目下的服务账号。
  2. 替换流水线使用的全组织密钥。 针对所有当前使用宽泛项目密钥的 CI/CD 或 agent 工作负载,创建专属服务账号并生成作用域密钥。
  3. 设置最小作用域。 scopes 数组仅传入工作负载实际需要的权限,模型推理流水线无需管理或微调权限。
  4. 将 owner_project_access 过滤纳入密钥审计流程。 建议至少每季度执行一次定期清单检查,发现过期或过度授权的凭证。
  5. 更新网关配置。 若通过 AI 网关层路由,将每个上游项目的项目级密钥替换为对应服务账号的作用域密钥。

TheRouter 用户应关注什么

如果你使用 TheRouter 在多个 OpenAI 项目间路由请求,此次变更为每个上游项目绑定提供了更清晰的凭证模型。与其为每个项目持有单一项目密钥,不如为每个路由目标创建专属服务账号,并为该账号签发作用域密钥。这样即使网关凭证遭到泄露,所能触达的范围也受到严格限制。

对注重治理合规的部署场景,新的密钥列表过滤功能让你在定期审查时能更便捷地验证路由层凭证的作用域设置是否合规。

查看 TheRouter 文档 了解如何在多项目 OpenAI 路由配置中设置每个 provider 的 API 密钥。

帮助与联系