从写代码,到创作下一幕

探索 字节跳动 - 火山方舟 的 AI 编程与视频创作活动。

Agent Plan & Coding Plan

一站体验多款热门模型,为 AI 编程与智能体开发提供更多选择。新用户可联系(微信: goo_lvyouyou)免费体验 9.9 agent plan。

Seedance 2.5

让创意,跃然成片。探索 30 秒视频、多模态参考与局部编辑,把脑海中的画面变成下一支作品。

中文

用户生命周期管理

使用本指南,可在员工入职时为其授予适当的 ChatGPT 工作区访问权限, 在其职责发生变化时更新这些权限,并在其离职时移除访问权限。此流程还涵盖工作区席位、基于群组的角色、 Codex 访问令牌,以及拥有自身访问控制的关联系统。

单点登录 (SSO) 用于验证员工身份。预配会将 员工添加到工作区。这两项操作本身都不能决定员工的席位、 功能权限、本地运行时策略或对外部系统的访问权限。

请围绕三个生命周期里程碑管理员工访问权限:

  • 入职: 预配工作区访问权限、群组、角色及正确的席位。
  • 调动: 更新员工所属的群组,并仅移除已过时的直接角色。
  • 离职: 移除工作区访问权限、撤销令牌并检查关联系统。

验证先决条件并指定负责人

在员工入职前,确定由谁负责生命周期的各个环节:

负责人 职责
工作区所有者 启用目录同步、分配工作区角色、批准席位类型并审查审计访问权限
身份管理员 配置身份提供商、应用分配、预配群组和同步状态
工作区管理员 审查工作区成员、群组成员资格和受支持的管理设置
安全或服务负责人 审查 Codex 令牌、关联系统、共享自动化和所需的审计证据

确认目标工作区,并在需要时验证组织的电子邮件域, 同时确定一位能够启用目录 同步的工作区所有者。然后检查工作区方案支持哪些控制项:

功能 支持的工作区方案
通过 SCIM 进行目录同步 ChatGPT Enterprise、Edu 和 Healthcare
自定义角色和基于角色的访问控制 ChatGPT Enterprise、Edu、Healthcare 和 Teachers
Codex 访问令牌 ChatGPT Business 和 Enterprise
仅限 Codex 的席位 符合条件的 Enterprise 工作区和满足条件的现有 Business 工作区;不适用于 Edu、Teachers 或 Healthcare

SCIM 是 System for Cross-domain Identity Management 的缩写。Business 工作区可以在不支持 SCIM 的情况下支持 Codex 访问令牌,而 Edu 工作区 可以在不支持 Codex 访问令牌或仅限 Codex 的席位的情况下支持 SCIM。请仅应用 您的工作区可用的控制项。

Business 工作区只有在 2026 年 6 月 24 日之前已有 Codex 席位,或截至该日期存在符合条件的待处理 Codex 席位邀请时,才能保留和添加仅限 Codex 的席位。 新的 Business 工作区,以及没有符合条件的席位或 邀请的工作区,无法添加首个仅限 Codex 的席位。请参阅 管理 ChatGPT Business 中的工作区生命周期和迁移

如果工作区支持多种席位类型,请在启用自动 预配之前,检查 Workspace settings > Identity & access 中的默认设置。通过 SCIM 预配的用户会继承该默认设置,而席位决定 哪些产品界面可用。自定义角色无法授予席位未包含的访问权限。

使用 Permissions & roles 检查本地访问、访问令牌、 凭据有效期和远程设备控制项。部分工作区将本地 访问合并在 Codex and Work Local 中,并使用 允许成员在本地使用 Codex 和 Work 控制项。其他工作区则将包含 允许成员在本地使用 CodexCodex Local 与包含 在本地使用 WorkWork Local 分开。 彼此独立的 Codex 和 Work 控制项不会相互授予访问权限。令牌 控制项可能显示在本地访问部分,也可能显示在单独的 Access tokens 部分。这些设置与群组成员资格和 已分配的席位类型相互独立。

以下示例显示了合并后的 Codex and Work Local 控制项,以及单独的 访问令牌 部分:

有关当前的先决条件和受支持的身份模式,请参阅 身份与预配管理成员、席位类型、角色和访问权限

选择员工加入工作区的方式

为每类用户选择一种主要预配方式:

方式 如何开始获得访问权限 在何处移除访问权限
手动邀请 工作区所有者或管理员邀请员工 工作区成员管理
Automatic Account Creation 拥有符合条件的电子邮件域的员工登录 工作区管理及相关身份流程
通过 SCIM 进行 Directory Sync 身份管理员在身份提供商中为员工进行分配 身份提供商应用或预配群组

对于小规模试点或未通过目录同步管理的群组,请使用手动邀请。 如果工作区成员资格应随员工入职、团队变更或离职而遵循 身份提供商,请使用 SCIM。

请勿同时启用 Automatic Account Creation 和 SCIM。通过 Automatic Account Creation 添加的用户可能不受 SCIM 管理,因此,将其从 身份提供商群组中移除后,其工作区访问权限可能不会被移除。有关当前指导,请参阅 SCIM 集成常见问题

根据获批的身份设置,SCIM 可以连接单个 ChatGPT 工作区或组织租户。 请明确指定每个工作区和产品的 分配。共享目录连接不会自动授予或移除 每个工作区或 Platform API 组织的访问权限。

将预配群组连接到正确的工作区

请在添加首位试点员工前配置连接。工作区 所有者和身份管理员分别承担不同的职责:

  1. 让工作区所有者选择目标 ChatGPT 工作区并检查 Workspace settings > Groups。记录现有群组名称、成员、 自定义角色分配,以及相关项目或 GPT 共享情况。
  2. 让身份管理员确定要进行同步的准确身份提供商群组。 将其名称和成员与所有 现有工作区群组进行比较。
  3. 如果同步群组与现有工作区群组同名, 请在启用同步前协调或重命名冲突群组。 让工作区所有者批准最终的成员、继承角色和 共享设置。匹配的现有群组将转为由 SCIM 管理,其成员资格 也将改由身份提供商控制。
  4. 选择范围严格限定的试点群组,并记录获批的工作区、 预期员工和群组角色分配。
  5. 让工作区所有者打开 Workspace settings > Identity & access 并选择 Enable Directory Sync。如果系统提示,请选择 Use SCIM only for this workspace 以进行工作区级预配,或选择 Keep the option to expand across products 以进行获批的租户级预配。如果 租户级 SCIM 已启用,请管理该现有连接, 而不要创建第二个工作区连接。
  6. 让身份管理员完成身份提供商连接, 选择 ChatGPT 应用,并分配获批的群组,以便将 成员预配到目标工作区。
  7. Workspace settings > Groups 中,确认所选群组显示 SCIM 标记。在将其用于访问控制前,验证群组名称、已同步成员和目标 工作区。
  8. 让工作区所有者打开 Permissions & roles > Custom roles, 创建或选择获批的角色,并将其分配给同步群组。 角色配置可在网页端进行,并且需要工作区所有者 权限。
  9. 在添加代表性试点员工之前,检查群组的有效权限和默认工作区席位 类型。

身份提供商管理员控制应用和群组成员资格; 工作区所有者控制目录同步和工作区角色 分配。有关当前各提供商的具体步骤和可用性,请参阅 SCIM 集成常见问题配置基于角色的访问控制

预配新员工

对于通过 SCIM 管理的员工:

  1. 确认目标工作区、已验证的电子邮件地址、默认席位类型 和身份提供商群组。
  2. 在身份提供商中,将员工分配给 ChatGPT 应用或授予访问权限的群组。
  3. 等待目录同步完成。如果员工未显示,请检查当前的 身份提供商状态。
  4. Workspace settings > Members 中,验证员工的电子邮件、 成员资格或待处理邀请、席位类型和 SCIM 标记。
  5. Workspace settings > Groups 中,确认员工属于 目标同步群组。让工作区所有者验证分配给该群组的自定义 角色。
  6. 让一名代表性员工登录正确的工作区,并验证 其所需的具体产品界面、功能和关联系统。
  7. 使用组织批准的流程,记录访问权限负责人和成功的验证结果。

如果手动添加员工,请从工作区成员 管理页面发送邀请,然后执行相同的席位、群组、角色和登录检查。

群组用于组织成员,但其本身并不会授予对所有功能的访问权限。 有关当前的角色分配流程,请参阅 角色与工作区权限配置基于角色的访问控制

在员工调动时更新访问权限

员工调动后,可能仍保留来自原有群组或角色 分配的访问权限。请先更新成员资格的权威来源,再验证 新的访问级别:

  1. 确定员工的新团队、所需工作区、席位、获批的 功能权限和目标群组。
  2. 如果员工在变更期间必须持续留在工作区,请先将其添加到 获批的目标群组,再将其从原群组移除。在身份提供商中更新由 SCIM 管理的成员资格;通过工作区管理更新 手动管理的成员资格。
  3. 确认获批的角色已分配给目标群组。 保留共享群组中的现有角色分配,以便其他成员 继续拥有获批的访问权限。
  4. 只有在批准了单独的群组级策略变更,并审查其对 每位成员的影响后,工作区所有者才能更改群组到角色的分配。
  5. 让工作区所有者打开员工的个人资料,检查 Direct roles, 并移除直接分配给该员工的过时角色。自定义角色使用 DefaultOnOff。任何已分配角色中的显式 Off 都会覆盖 另一角色中的 On
  6. 在批准团队变更前,检查员工在所有直接角色和 群组分配角色下的有效权限。
  7. 如果工作区支持多种席位类型,让工作区所有者打开 Workspace settings > Members > Change seat type,并检查 员工预期的产品访问权限。
  8. 在将 ChatGPT 席位转换为仅限 Codex 的席位前,确认 员工应失去对聊天、记忆、项目和其他 ChatGPT 功能的访问权限。底层数据不会被删除;如果员工恢复为 ChatGPT 席位, 这些数据将再次可用。
  9. 同步和权限更新完成后,同时验证 新获准的操作和应不再可用的操作。

如果员工拥有自动化工作流,请检查其 Codex 令牌、 密钥管理器条目或关联服务授权是否应移交给另一位 获批的负责人。移除员工的本地 Codex 权限会暂停该 员工的 Codex 令牌,但不会将其撤销。恢复权限会 重新激活这些令牌,因此,对于必须永久失去访问权限的凭据,应将其撤销。

移除离职员工

从管理员工工作区成员资格的权威系统开始:

  1. 确定员工是由 SCIM 管理,还是由管理员手动添加。
  2. 对于由 SCIM 管理的员工,请移除该员工的 ChatGPT 应用 分配,并在身份提供商中将其从所有授予访问权限的预配 群组中移除。请勿移除共享群组本身。
  3. 对于不由 SCIM 管理的员工,让工作区所有者或 管理员从 Workspace settings > Members 中移除该成员。
  4. 确认该成员已不在目标工作区中。 对于由 SCIM 管理的访问权限,请确认同步已完成,且没有 其他身份提供商分配能够恢复成员资格。
  5. 记录已完成的移除操作,并指定负责人检查令牌、 关联系统和保留的数据。

如果身份提供商仍将员工分配到由 SCIM 管理的群组,请勿依赖工作区端的移除操作。 后续同步可能会将该 员工重新添加到工作区。

撤销 Codex 访问令牌并移交自动化

将人员从工作区移除,并不能取代对受信任自动化所用 凭据的明确审查。仅当工作区支持并启用了 Codex 访问令牌时,才应用此流程。

移除本地 Codex 权限会暂停现有令牌,但不会将其撤销。 如果工作区所有者恢复权限,这些令牌可能会再次生效, 因此,对于必须永久失去访问权限的凭据,应明确将其撤销。

访问令牌 页面会标明每个令牌的创建者和状态。使用 撤销 移除活动令牌的访问权限:

  1. 让工作区所有者或管理员打开 访问令牌
  2. 找出离职员工创建的令牌,以及使用这些令牌的工作流。
  3. 选择替代身份。对于采用符合条件的按量付费方案、需要长期运行的非人类工作流,请使用获批的专用服务 账号。否则,请指定一位 获批且在职的工作流负责人。如有需要,让工作区所有者向该人员授予 创建访问令牌的权限,并确认其拥有 本地 Codex 权限。
  4. 创建替代令牌。获准的服务账号操作员可以 从服务账号详情页面创建令牌。对于个人 替代令牌,让新的工作流负责人为其自己的 ChatGPT 工作区身份创建令牌。如果对话框显示 作用域,请选择 Codex。仅当工作流需要时,才选择其他作用域。没有 作用域 的对话框会创建仅限 Codex 的令牌。管理员无法 代表其他用户创建个人令牌。
  5. 更新工作流中存储的密钥,然后验证其能否使用替代令牌成功运行。
  6. 让工作区所有者或管理员撤销离职员工的令牌 以及所有已替换的凭据。
  7. 确认已撤销的令牌无法再启动新的已验证身份运行。

当获批的替代负责人创建令牌时,请使用具有描述性的工作流 名称,并选择组织策略允许的最短凭据有效期。 如果显示 作用域,请选择 Codex,并避免授予工作流不需要的 权限。以下示例显示了带作用域的界面:

工作区所有者和管理员可以撤销其工作区中的任何令牌。拥有 访问令牌权限的成员只能撤销自己创建的令牌。有关当前的 令牌权限和轮换步骤,请参阅 访问令牌

检查关联系统和保留的数据

工作区预配不会管理所有授权边界。请让 相关服务负责人检查以下各项的访问权限:

  • 源代码仓库和关联的 GitHub 账户。
  • Google Drive、Slack 和其他关联应用。
  • 已安装的插件、捆绑技能和由连接器支持的功能。
  • 托管的 Codex 环境、共享自动化和存储的密钥。
  • 托管设备、本地存储的凭据和受支持的远程会话。
  • 独立的 Platform API 组织、项目和 API key。

请应用各系统自身管理的控制项,而不要假定工作区 群组或 SCIM 变更会更新所有位置的权限。有关完整的边界模型,请参阅 角色与工作区权限;有关插件可用性、捆绑技能和关联应用权限,请参阅插件控制

移除工作区访问权限并不等同于删除内容。成员 离开后,工作区会自动将其项目和自定义 GPT 的所有权重新分配给工作区所有者。这些项目不会被标记为删除。 如果该成员重新加入,所有权将返还给该成员。

对于 Enterprise 和 Edu 工作区,聊天、文件和 canvas 文档遵循 已配置的工作区保留策略。Business 工作区会无限期保留聊天、 文件和 canvas 文档。Healthcare 工作区也提供 数据保留控制;请检查适用的工作区配置和 ChatGPT Healthcare 指南

重新分配项目或 GPT 不会转移前成员的私密 对话或文件,工作区所有者也无法通过所有权变更查看这些私密内容。 有关当前各方案的具体行为,请参阅 工作区成员移除和数据保留

如果安全或合规要求提供变更证据,请在获批的系统中记录 受影响的工作区、员工、身份提供商分配、完成时间、 审批负责人和令牌撤销验证结果。 在需要身份验证的 Admin API 参考中确认可用记录、管理员权限和保留期限。 敏感的合规作用域可能需要工作区所有者权限。有关产品 概述,请参阅 Compliance API 和审计事件。 请勿根据本指南推断事件覆盖范围、字段或保留期限。

排查访问权限缺失或异常问题

症状 要检查的内容 纠正措施
员工可以登录,但找不到工作区 目标工作区、邀请、身份提供商分配和电子邮件地址 更正分配或电子邮件映射,然后验证工作区成员资格
已同步员工获得了错误的席位 工作区的默认席位类型和当前成员记录 让工作区所有者检查默认设置和该员工受支持的席位选项
团队变更后某项功能仍未被移除 其他群组成员资格、Direct roles 和员工的综合权限 将员工从过时群组中移除,然后让工作区所有者仅撤销该员工已过时的直接角色
手动群组未经批准就变为由 SCIM 管理 相同的群组名称、身份提供商成员、继承角色和现有共享设置 在身份提供商中协调获批的群组成员资格,并检查受影响的访问权限
团队变更后其他员工失去访问权限 最近对共享群组角色分配所做的更改,以及原团队获批的访问权限 让工作区所有者恢复获批的共享群组角色,然后仅更新调动员工的成员资格
团队变更后自动化令牌停止工作 工作流负责人的本地 Codex 权限和当前令牌状态 让工作区所有者恢复获批的本地 Codex 访问权限,或轮换并撤销受影响的令牌
访问权限变更未立即显示 身份提供商同步状态、预期同步时间窗口和最近的角色更新 在联系 OpenAI Support 前,让身份管理员验证同步
已移除的员工重新回到工作区 身份提供商应用分配和所有授予访问权限的预配群组 在身份提供商中移除员工,而不是仅在工作区设置中移除
离职员工仍有列出的令牌 令牌创建者、工作流负责人和工作区管理员的令牌权限 轮换所有必需的自动化凭据,然后撤销离职员工的令牌
关联应用仍允许访问 源系统账户、插件可用性和应用授权 让相关服务负责人使用该系统支持的控制项移除访问权限

大多数身份提供商每 30 到 40 分钟同步一次,但有些会 立即应用更新。自定义角色的变更可能需要约五分钟才会 显示。您无法强制执行 SCIM 同步,因此,请勿通过移除后重新创建 工作区成员来规避延迟更新。

如果访问权限移除或群组更新在预期的 提供商特定时间窗口过后仍未完成,请让身份管理员收集:

  • 受影响的工作区和员工电子邮件地址。
  • 身份提供商、应用分配和预配群组。
  • 尝试执行的变更、时间戳和最新同步状态。
  • 仍需检查的直接角色、群组角色或令牌。

通过 Help Center 联系 OpenAI Support,并提供这些详细信息。 将离职员工仍保有访问权限的情况视为安全 例外,并遵循组织的事件升级流程。

有关各提供商的具体设置和同步行为,请使用当前的 SCIM 集成常见问题。 有关登录和身份错误,请参阅 身份验证故障排除

验证完整的员工生命周期

在更大范围推出之前,使用一名代表性测试员工验证所有三个 过渡阶段:

生命周期阶段 主要负责人 成功结果
入职 身份管理员 员工以预期的席位、群组和功能访问权限加入正确的工作区
调动 身份管理员和工作区所有者 管理员更新群组成员资格,工作区所有者移除过时的直接角色,同时保留共享群组角色
离职 身份和安全负责人 管理员移除工作区访问权限、检查受支持的令牌,并撤销或重新分配外部访问权限

记录每项变更的批准人、已验证的内容,以及由哪位负责人 处理所有剩余的访问权限例外。按照组织的身份和安全策略,安排定期 访问权限审查。

相关文档