核心要点摘要
- OpenAI 2026 年 7 月 16 日更新企业管理能力，管理员可在 Global Admin Console 创建工作区级 Admin key。
- Admin key 可接入受支持的组管理、Spend Controls、成本报告和分析 API，但不能调用模型推理。
- 一把密钥只对应一个工作区，生产上应按系统与任务拆分，并设置最小权限、过期时间、轮换和撤销流程。
- credit 与 Codex 分析最多覆盖 120 天，数据也有刷新延迟，不能把控制台读数当成实时计量流。
技术团队接入这次新增的 Admin key 前，应先拆开管理平面和模型调用平面，再写请求。Admin key 用于工作区管理 API，普通模型 API key 用于推理，两者的权限、日志和事故影响完全不同。
先区分三类凭证
企业环境里至少会同时出现三类容易混淆的"key"。
| 凭证 | 主要用途 | 不应用于 |
|---|---|---|
| Admin key | ChatGPT/Codex 工作区管理、分析、成本与受支持自动化 | 模型推理请求 |
| 模型 API key | GPT 模型调用、业务应用推理 | 工作区成员或限额管理 |
| EKM 密钥 | 加密存储在 OpenAI 的客户内容 | API 身份认证或管理调用 |
OpenAI 官方明确写明 Admin key 不授予模型访问或推理权限。它也不是前一天 EKM 主题里的加密密钥。代码仓库、环境变量和 secret manager 最好从命名上就区分，例如 OPENAI_WORKSPACE_ADMIN_KEY 与业务推理凭证分开，避免运维人员在事故中撤错密钥。
权限模型不能只看"管理员"三个字
每把 Admin key 只对应一个工作区。Workspace owner 可以根据可用范围创建 All、Read only 或 Restricted 密钥；Workspace admin 必须使用 Restricted，并且无法获得 owner-only 的敏感 Compliance scopes。
这里不适合做一把"万能管理密钥"。OpenAI 也建议大多数集成使用 Restricted，并为不同系统或工作流使用不同密钥。实际可以按责任拆成：
- 目录同步服务只拿组和成员管理所需权限；
- 成本采集任务只读 analytics 与 cost reporting；
- 限额自动化只使用 Spend Controls 所需类别；
- 合规导出单独审批，不与普通运营报表共用凭证。
拆分后的好处不只是安全。某个任务失败时，可以从密钥名称、最后使用时间和权限范围定位调用方，不必在所有后台脚本中排查同一 secret。
建议保存的凭证登记字段
| 字段 | 记录内容 |
|---|---|
| key_id | 企业内部凭证编号，不保存明文 secret |
| workspace_id | 密钥对应的唯一工作区 |
| owner_team | 使用和轮换责任团队 |
| integration | 成本采集、组管理、限额控制等具体系统 |
| scopes | 实际授权的端点类别和读写权限 |
| created_by | 创建者及其 Workspace role |
| expires_at | 过期时间与提前轮换窗口 |
| last_used_at | 识别闲置密钥和异常调用 |
| secret_location | secret manager 中的引用位置 |
| revoke_runbook | 泄露或停用时的处置文档 |
OpenAI 控制台会展示状态、过期时间、最后使用时间、创建者和权限。企业内部登记还需要补业务责任人、使用系统和事故流程，因为这些信息不一定能从控制台字段自动推断。
创建、部署和轮换的最小流程
创建前，先列出任务需要访问的端点类别，默认选择 Restricted。创建时设置明确名称和合理过期时间；secret 只显示一次，应直接进入 secret manager，不要发到聊天工具或工单正文。
部署后先用只读调用验证工作区、权限和返回字段，再开放写操作。轮换时可以短暂并行新旧密钥：部署新 secret、验证任务成功、停止旧调用、撤销旧 key，最后检查 last-used 是否还有残留。
撤销演练也值得做一次。假设成本采集服务的 secret 泄露，团队能否在不影响组管理和限额任务的情况下单独撤销？如果所有自动化共用一把 key，答案往往是否定的。
分析数据要带上时间边界
Global Admin Console 对 ChatGPT 与 Codex credit analytics、Codex usage analytics 提供最多 120 天历史；ChatGPT usage analytics 则为过去 12 个月。credit 与 Codex usage 通常 1-6 小时刷新，ChatGPT usage 最长可能到 48 小时。
采集任务应保存 source_window_start、source_window_end、fetched_at 和 data_freshness。仪表盘若只显示"今日成本"，却不说明数据可能晚几个小时，就容易把未刷新误判成使用量下降。
需要把工作区数据与外围 GPT、Claude、Gemini 任务放进同一张企业成本表时，可以把 147AI 作为外部多模型接入候选之一，但调用记录由企业自己的观测系统采集，两类 key 也必须使用不同 secret 路径。不要让 OpenAI Admin key 出现在任何模型请求代码里。
写操作上线前要做权限回归测试
只读成本采集调通后，不代表组管理或 Spend Controls 写操作也可以直接上线。写权限测试应准备独立测试工作区或低风险对象，至少覆盖正常修改、重复请求、权限不足、目标不存在和任务中途失败几种情况。每次测试都保存请求类别、操作者、目标工作区、执行时间和最终状态，避免只留下"接口返回成功"。
组成员同步还要考虑部分失败。假设批量任务准备增加十名成员，第六条请求失败，系统是继续、停止还是回滚？Admin key 只负责授权调用，幂等、重试和业务一致性仍由企业自己的程序处理。写操作最好生成可复核的变更清单，涉及移除成员或降低额度时增加审批环节。
权限回归也不能只在第一次部署时做。Admin key 的 scope、工作区角色和后台任务版本发生变化后，都应重新运行一组固定用例。测试重点包括：只读服务是否仍无法写入，组管理服务是否看不到成本以外的敏感数据，普通 Workspace admin 创建的 Restricted key 是否被程序错误假定为 owner 权限。
如果任务需要敏感 Compliance scopes，建议把它从普通管理流水线中完全拆开。官方说明这类权限可能暴露对话消息等敏感工作区数据，并受 Workspace owner 限制。独立运行身份、独立密钥、独立审批和独立导出位置，能减少普通运营系统意外接触合规数据的机会。
发生泄露时怎样缩小影响面
应急处置从识别具体 key 开始，而不是先轮换所有 OpenAI 凭证。根据内部登记表找到工作区、scope、调用服务和最后使用时间，立即撤销目标 key，再暂停对应任务。若密钥有写权限，还要检查最近变更记录；若涉及 Compliance 范围，则按企业的敏感数据事件流程扩大调查。
撤销后创建新 key 不能照抄旧权限。先确认旧任务是否积累了不再需要的 scope，再按当前最小需求重建。事故复盘则要回答 secret 从哪里暴露、为什么监控没有更早发现、是否有其他服务复用同一 key。这样轮换才是修复，而不是只换一串字符。
FAQ
Q1：Admin key可以调用GPT模型吗？
A：不可以。OpenAI 官方明确说明 Admin keys 不授予模型访问或推理权限。
Q2：不同工作区能否共用一把Admin key？
A：不能按这种方式设计。每把 Admin key 适用于创建时选择的一个工作区。
Q3：120天数据是否实时更新？
A：不是。credit 与 Codex usage 通常有 1-6 小时刷新延迟，ChatGPT usage analytics 最长可到 48 小时。
内容更新时间 ：2026-07-17
官方来源 ：Enterprise & Edu Release Notes｜Global Admin Console｜Managing Admin keys
证据边界：发布日期、权限、可见字段、历史范围和刷新时效来自 OpenAI 官方页面；字段表、命名方式、部署和轮换顺序为工程实施建议。