> ## Documentation Index
> Fetch the complete documentation index at: https://aicoding.cscitech.top/llms.txt
> Use this file to discover all available pages before exploring further.

# 06-团队管理与企业治理

> 建立 Codex 的企业身份、托管配置、权限、数据、审计、网络、成本、CI 与事件响应治理体系。

## 本页目标

个人使用 Codex，重点是任务能否完成；企业使用 Codex，首先要回答另一组问题：

* 谁可以使用，离职后能否及时收回访问？
* 哪些配置由组织强制，哪些允许开发者自行调整？
* 代码、提示词、输出和日志会流向哪里，保留多久？
* 谁批准了联网、提权、推送、部署或敏感数据访问？
* 自动化任务以谁的身份运行，凭据泄露后如何止损？
* 模型、额度和高成本功能怎样分级开放？
* 发生越权、泄露或异常消耗时，能否快速调查和恢复？

本页面向工作区所有者、平台工程、安全、合规、研发效能和团队负责人。
目标不是列出一组后台开关，而是建立一套可以持续执行、审计和改进的控制体系。

<Warning>
  Codex 的套餐名称、管理后台路径、角色名称、模型、策略键、日志字段、保留期限、数据驻留区域、API 端点及预览功能会变化。
  涉及这些动态能力时，以组织合同、当前管理后台、已安装版本的 `codex --help` 和 OpenAI 官方文档为准。
  上线前应由安全、法务和采购共同核对，不要把本文示例当作合同承诺。
</Warning>

## 先建立治理边界

企业治理不是“给所有人装好 CLI”之后再补一份制度。
应先划清系统边界，再决定是否开放能力。

### 区分三种执行面

| 执行面            | 代码主要位于哪里          | 常见身份              | 主要治理关注点                    |
| -------------- | ----------------- | ----------------- | -------------------------- |
| 本地 App、CLI、IDE | 开发者设备或企业开发环境      | ChatGPT 工作区身份     | 设备安全、沙箱、审批、托管配置、终端日志       |
| Codex 云端任务与审查  | 托管执行环境及连接的代码仓库    | ChatGPT 工作区身份     | 仓库连接、云端环境、数据驻留、云端网络、审计     |
| API、SDK、CI 自动化 | 企业 runner、容器或自建平台 | API key、服务身份或访问令牌 | 密钥、归属、额度、runner 隔离、API 侧审计 |

不要假定三种执行面的权限、留存和审计完全相同。
尤其要区分 ChatGPT 工作区身份产生的活动与 API 组织身份产生的活动。
两者可能进入不同的管理后台、日志源和计费口径。

### 建立责任矩阵

至少指定以下责任人，并为每个角色安排替补：

| 角色        | 负责内容                  | 不应单独决定的事项     |
| --------- | --------------------- | ------------- |
| 工作区所有者    | 套餐、组织设置、管理员授权         | 安全例外与数据分类     |
| 身份管理员     | SSO、MFA、SCIM、组同步、离职回收 | 放宽执行权限        |
| Codex 管理员 | 功能开关、托管策略、环境和用量查看     | 自行批准自己的高风险例外  |
| 安全负责人     | 威胁模型、网络策略、审计、事件响应     | 业务是否接受输出质量    |
| 数据负责人     | 数据分类、驻留、留存、DLP 和删除要求  | 绕过合同与法务评估     |
| 平台工程      | CI runner、密钥、镜像、策略分发  | 扩大用户权限范围      |
| 成本负责人     | 预算、预警、异常用量和月度复盘       | 查看无业务必要的提示词内容 |
| 团队负责人     | 场景准入、培训、例外发起和效果评估     | 绕过企业基线        |

最重要的原则是职责分离。
能修改全员策略的人，不应成为唯一的审计者；能创建自动化令牌的人，不应独自批准无限期使用。

## 企业身份与生命周期

身份治理的目标不是“大家能登录”，而是每次访问都能回答：这个人是谁、为什么有权限、权限何时失效。

### 强制企业身份

生产性使用应优先采用企业控制的身份体系：

1. 将企业工作区连接到组织的身份提供商（IdP）。
2. 配置 SSO，并按企业基线强制 MFA。
3. 禁止用共享账号代表团队运行日常任务。
4. 明确个人账号与企业账号的切换规则。
5. 对管理员使用更强认证策略和条件访问。
6. 对高风险登录启用 IdP 侧告警与会话撤销。

SSO 解决“如何认证”，SCIM 解决“成员如何自动增删”，RBAC 解决“成员能做什么”。
三者需要一起实施，不能用其中一个替代另外两个。

### 用组管理授权

建议从少量清晰的组开始：

| 建议组                    | 典型成员        | 允许范围          |
| ---------------------- | ----------- | ------------- |
| `Codex-Users-Pilot`    | 首批试点开发者     | 受限本地能力、试点仓库   |
| `Codex-Users-Standard` | 一般研发成员      | 组织批准的标准能力     |
| `Codex-Cloud-Users`    | 允许使用云端任务的成员 | 指定仓库和云端环境     |
| `Codex-CI-Operators`   | 平台与自动化维护者   | 创建和维护受控 CI 集成 |
| `Codex-Admins`         | 极少数管理人员     | 管理策略、环境和分析能力  |
| `Codex-Audit-Readers`  | 安全、合规审计人员   | 只读日志和用量数据     |

项目访问应尽量沿用代码托管平台已有的团队和仓库权限。
Codex 权限用于补充产品能力边界，不要制造另一套互相冲突的仓库授权体系。

### 入职、转岗与离职

身份生命周期应成为可测试的自动化流程。

**入职：**

1. HR 系统创建人员记录。
2. IdP 根据部门、岗位和地区加入基础组。
3. SCIM 将成员同步到对应工作区或权限组。
4. 团队负责人确认业务场景和数据级别。
5. 成员完成安全培训后才进入正式组。
6. 首次使用只开放低风险配置和测试仓库。

**转岗：**

1. 旧组权限先回收，再授予新组权限。
2. 检查个人创建的令牌、云端环境和仓库连接。
3. 转移仍需保留的自动化任务所有权。
4. 复核管理员、审计读取者等高权限角色。

**离职：**

1. IdP 禁用账号并撤销活跃会话。
2. SCIM 从工作区和授权组移除成员。
3. 吊销其创建或保管的令牌和密钥。
4. 检查 CI、定时任务、机器人和共享 runner 是否仍引用旧凭据。
5. 转移必要资产并保留合规所需记录。
6. 在规定时限内验证访问已真正失效。

每季度执行一次“模拟离职”测试。
选取测试账号，验证从 IdP 禁用到 Codex、代码仓库、密钥管理器和 CI 全部失效所需的时间。

## 团队权限模型

权限设计应从业务场景出发，而不是从“工具能开什么”出发。

### 按风险分层

| 层级       | 典型场景              | 建议边界                 |
| -------- | ----------------- | -------------------- |
| L0 只读    | 解释代码、审查 diff、生成方案 | 只读沙箱，无生产凭据，默认无外网     |
| L1 工作区写入 | 修复、测试、文档和局部重构     | 仅工作区可写，越界需审批         |
| L2 受控联网  | 安装依赖、查询批准的内部服务    | 精确域名白名单，记录审批和网络日志    |
| L3 仓库操作  | 创建分支、提交、打开 PR     | 代码托管身份最小权限，禁止直接推主分支  |
| L4 发布操作  | 部署、迁移、生产变更        | 独立流水线审批，不把生产权限交给交互代理 |

默认成员从 L0 或 L1 开始。
权限提升应绑定明确场景、负责人、到期时间和补偿控制，不能因“审批太多”永久放宽。

### 沙箱与审批是两个控制面

沙箱决定进程技术上能访问什么；审批决定何时必须停下来等待授权。
企业基线通常应限制成员可选择的沙箱和审批组合。

以下是说明意图的策略示例，不保证适用于所有版本：

```toml theme={null}
# 示例：只允许只读或工作区写入，不允许完全访问。
allowed_sandbox_modes = ["read-only", "workspace-write"]

# 示例：保留人工审批，不允许全程无审批。
allowed_approval_policies = ["untrusted", "on-request"]
```

配置键和取值属于动态能力。
部署前必须对照官方“企业托管配置”文档和当前客户端版本验证。

不要在开发者本机或生产主机上允许同时关闭沙箱与审批。
确需高权限自动化时，把权限放在一次性、隔离、无持久凭据的 runner 内，而不是放宽员工设备。

### 高风险动作的固定规则

下列动作应被禁止，或至少强制人工批准：

* 读取 `.env`、SSH 私钥、云凭据目录或浏览器凭据。
* 修改 shell 启动文件、系统服务、计划任务和登录项。
* 使用 `sudo`、管理员权限或绕过沙箱。
* 删除大量文件、覆盖备份或改写共享 Git 历史。
* 直接推送受保护分支、合并 PR 或触发生产发布。
* 向未批准域名上传代码、日志、提示词或构建产物。
* 安装来源不明的 MCP、插件、Skill、包或二进制文件。
* 关闭安全扫描、分支保护、签名验证或审计采集。

命令规则只是一层补充控制。
最终还要依赖操作系统权限、代码托管平台保护、网络出口和流水线审批形成纵深防御。

## 托管配置与变更管理

企业需要区分“强制要求”和“托管默认值”。

| 配置类型  | 用途                      | 用户能否覆盖           |
| ----- | ----------------------- | ---------------- |
| 强制要求  | 封锁危险模式、限制网络与外部工具、建立安全底线 | 通常不能，具体行为以官方文档为准 |
| 托管默认值 | 提供统一模型、推理强度、界面或工作流起点    | 可能允许会话级调整        |
| 项目配置  | 仓库特有说明、测试命令、代码规范        | 由仓库所有者审查         |
| 用户配置  | 个人偏好和非安全性体验设置           | 可自行调整，但不得突破上层要求  |

### 配置优先级要可解释

管理员应维护一份配置优先级说明，至少包含：

1. 哪一层拥有最高优先级。
2. 冲突时客户端如何处理。
3. 用户在哪里查看实际生效值。
4. 不合规值是报错、回退还是被忽略。
5. 离线设备多久必须重新获取企业策略。
6. 策略获取失败时是继续运行还是故障关闭。

云端策略、系统级文件、MDM 分发路径和客户端支持范围会随平台变化。
Windows、macOS、Linux 的路径和能力也可能不同，应以官方托管配置文档为准。

### 把策略当代码管理

即使最终通过管理后台下发，也建议把策略源文件放在受控私有仓库中：

* 使用代码审查和受保护分支。
* 标注策略版本、所有者、适用组和生效日期。
* 每次变更附风险说明、测试证据和回滚方案。
* 禁止同一人提出、批准并发布高风险放宽。
* 在测试组验证后再分批扩大范围。
* 保留管理后台中的变更记录或截图证据。
* 定期比较源文件、后台配置和终端实际状态。

一个最小变更单应包含：

```text theme={null}
变更目标：为什么要改
影响对象：哪些组、设备、runner、仓库
变更内容：旧值、新值、动态能力依据
风险分析：可能增加的数据、权限、网络或成本风险
验证计划：正向测试与拒绝测试
回滚条件：出现什么现象立即回滚
回滚步骤：由谁在多长时间内恢复
审批人：业务、安全、平台
到期时间：临时例外何时自动失效
```

### 验证拒绝路径

策略测试不能只验证“允许的任务能成功”，还要验证“不允许的任务确实失败”。

每次策略发布至少测试：

* 标准用户不能进入未批准的完全访问模式。
* 未批准域名无法访问。
* 敏感路径不能读取或外发。
* 普通用户不能修改托管要求。
* 管理员组之外看不到管理能力。
* 过期令牌和离职账号不能继续运行任务。
* 受保护分支不能被代理直接推送。
* 策略获取失败时行为符合组织预期。

## 数据治理

“企业数据不用于训练”并不等于“不产生任何数据”。
治理评估必须按数据类型、执行面和生命周期逐项确认。

### 建立数据分类

| 分类   | 示例                | Codex 使用原则        |
| ---- | ----------------- | ----------------- |
| 公开   | 开源代码、公开文档         | 可在批准环境中使用         |
| 内部   | 非公开代码、一般设计文档      | 仅企业身份和批准仓库        |
| 机密   | 客户代码、未发布产品、漏洞细节   | 需专项评估、最小数据和严格网络边界 |
| 严格受限 | 私钥、口令、生产数据、监管敏感数据 | 默认禁止输入或暴露给代理      |

数据分类应写入研发规范、仓库标签和培训材料。
不要依赖开发者临时判断“这段内容应该没关系”。

### 绘制数据流

对每个准入场景画出以下路径：

```text theme={null}
用户或 CI 身份
  -> 输入来源（仓库、Issue、日志、网页、MCP）
  -> Codex 执行面（本地、云端、API）
  -> 模型请求与工具调用
  -> 输出位置（工作区、PR、日志、制品）
  -> 审计、备份、留存与删除系统
```

逐节点记录数据类别、控制者、处理区域、加密方式、留存期限和删除责任人。
本地执行仍可能发送模型请求；“代码在本地”不能自动推导出“任何内容都不离开设备”。
实际传输与留存范围必须以产品架构、合同和官方数据控制说明为准。

### 核对训练、留存与驻留

采购和上线评审至少应获得以下书面结论：

1. 企业输入和输出是否用于训练模型。
2. 各执行面的服务端数据是否保留以及保留多久。
3. 零数据留存是否适用于当前套餐、功能和地区。
4. 审计日志是否独立保留，期限是否不同。
5. 可选择哪些数据驻留区域，覆盖哪些数据类型。
6. 支持请求、滥用监测和安全日志是否存在例外。
7. 删除工作区、成员、任务或仓库连接后如何删除数据。
8. 分包商、跨境传输和合同附件如何约定。

这些答案会随合同与功能变化，必须以官方文档和签署条款为准。
不要把营销页面的一句话扩展为所有产品面的统一承诺。

### 最小化发送内容

即使合同允许，也应执行数据最小化：

* 用最小相关文件代替整个仓库。
* 用脱敏样本代替真实客户记录。
* 删除日志中的 cookie、令牌、邮箱和请求正文。
* 不把生产数据库导出到开发目录。
* 不将密钥放入提示词、代码注释、测试夹具或 `/tmp`。
* 对 PR 评论、Issue 和网页内容按不可信输入处理。
* 对输出再次扫描，防止复述输入中的敏感值。

对严格受限数据，技术上应使用 DLP、secret scanning、文件权限和网络控制阻止，而不只是写一条制度。

## 网络白名单与外部连接

网络权限决定代理能否把已读取的数据带出当前边界，也决定它能否下载恶意依赖或接受提示注入内容。

### 默认拒绝，按需开放

企业网络策略建议采用以下顺序：

1. 默认关闭命令执行环境的出站网络。
2. 为确有需要的场景建立精确域名白名单。
3. 按用户组、环境和用途分别维护白名单。
4. 禁止直接访问裸 IP，除非有明确业务依据。
5. 通过企业代理、DNS 和防火墙记录出口日志。
6. 对上传、Webhook、文件分享和匿名存储域名重点拦截。
7. 定期清理不再使用的域名和通配符。

不要仅白名单顶级域名后假定其所有子域都可信。
重定向、CDN、包管理镜像和登录域名可能需要单独验证。

### 建立域名申请单

| 字段   | 要回答的问题                   |
| ---- | ------------------------ |
| 业务目的 | 为什么任务必须访问它？              |
| 数据方向 | 只下载，还是会上传内容？             |
| 数据类别 | 可能发送公开、内部还是机密数据？         |
| 身份方式 | 匿名、用户 OAuth、服务令牌还是 mTLS？ |
| 所有者  | 谁负责域名和集成的生命周期？           |
| 到期时间 | 何时重新评估或自动移除？             |
| 替代方案 | 能否通过内部镜像或缓存完成？           |

对于包管理器，优先使用企业制品库和依赖代理。
这样既能缩小域名范围，也能执行恶意包扫描、许可证审查和版本固定。

### 把 MCP 和插件视为第三方应用

MCP、插件和其他外部工具可能读取会话上下文、访问外部系统并执行有副作用的动作。
接入前应评估：

* 发布者和代码来源是否可信。
* 工具声明的权限是否与实际行为一致。
* 能读取哪些数据，能调用哪些写操作。
* 使用什么身份，令牌由谁保管。
* 是否支持只读模式、审批和细粒度范围。
* 日志是否进入企业 SIEM。
* 撤销集成后令牌和缓存是否删除。

未知网页、README、Issue、工具返回值和依赖安装脚本都可能包含提示注入。
代理读到的内容不是管理员授权，不能因为文档写着“必须执行”就自动提高权限。

## 审计与合规

审计的目标是重建事实，而不是单纯统计活跃人数。

### 区分三类记录

| 记录      | 主要用途                 | 常见消费方         |
| ------- | -------------------- | ------------- |
| 用量分析    | 采用率、模型和额度趋势          | 研发效能、财务、团队负责人 |
| 管理活动    | 角色、策略、令牌、连接器变更       | 安全、平台、内审      |
| 任务与合规日志 | 用户、时间、请求、响应、模型和任务元数据 | 安全调查、法务、合规    |

Analytics 仪表盘、Analytics API、Compliance API 或管理后台的实际可用范围、字段和延迟属于动态能力。
应以当前套餐和官方文档为准，并在试点期用真实测试事件验证。

### 设计日志管道

```text theme={null}
Codex / ChatGPT / API 组织日志
  -> 定时导出或采集
  -> 完整性校验与标准化
  -> SIEM 或受控数据湖
  -> 告警、调查、留存和删除策略
```

采集任务要监控自身健康状态。
如果官方源日志保留窗口较短，导出失败可能导致不可恢复的审计缺口。

至少对以下事件告警：

* 管理员、所有者或审计角色被新增。
* 企业策略被放宽或分配范围扩大。
* 新建、导出、轮换或吊销访问令牌。
* 大量访问新仓库或敏感项目。
* 非工作时间出现异常高用量。
* 突然切换到高成本模型或高推理强度。
* 大量审批绕过、提权或完全访问尝试。
* 向新域名发送请求或出现大流量上传。
* 离职账号、禁用账号或过期令牌仍有活动。

### 保护审计数据

审计日志本身可能包含提示词、响应、代码片段、用户标识和安全事件细节。
因此必须：

* 按敏感数据保护，不向所有管理员默认开放原文。
* 对日常报表使用聚合数据和最小字段。
* 将调查访问与普通用量查看分开授权。
* 为日志导出密钥设置短周期轮换和专用服务身份。
* 对读取、导出和删除日志的行为再次审计。
* 按法律与合同要求设置留存和诉讼保全。

不要把“可审计”理解为“所有管理人员都能浏览员工提示词”。
审计访问同样需要业务必要性、审批和记录。

## 模型与成本控制

成本治理应同时看预算、业务价值和风险，不能只追求减少 token。

### 建立场景与模型目录

| 场景        | 默认策略           | 升级条件         |
| --------- | -------------- | ------------ |
| 代码解释、格式修改 | 成本较低的可用模型与标准推理 | 输出不稳定或涉及复杂依赖 |
| 常规修复与测试   | 组织标准模型与中等推理    | 多文件推理、疑难故障   |
| 架构迁移与安全分析 | 更强模型、受控高推理     | 经团队负责人批准     |
| 批量 CI 任务  | 固定模型、限制输入与并发   | 通过预算负责人评估    |

具体模型名称、上下文限制、推理档位和服务层级会变化，以官方模型文档和组织后台为准。
托管默认值用于引导大多数任务，不应妨碍经批准的复杂场景。

### 设置预算护栏

建议同时实施：

* 工作区月度预算和预警阈值。
* 按团队、产品、成本中心或服务身份归集。
* 每用户或每自动化流程的异常基线。
* CI 并发、超时、重试次数和每日任务上限。
* 高成本模型与高推理强度的受控授权。
* 大仓库任务的路径限制和输入裁剪。
* 失败任务的退避重试，防止无限循环。
* 定期清理无人负责的令牌与自动化任务。

用量数据可能不是实时数据。
不能只依靠后台报表止损，还应在 CI 编排器、密钥网关或内部代理层实施硬限制。

### 每周进行异常复盘

成本负责人每周至少检查：

1. 总用量与预算预测。
2. 按团队、用户、执行面和模型的变化。
3. 单次任务、失败重试和长会话异常。
4. 新增自动化、仓库和外部工具造成的增量。
5. 高成本任务是否产生可验证的业务结果。
6. 是否存在账号共享、令牌泄露或失控循环迹象。

成本异常也可能是安全事件。
不要在确认原因前只提高额度或关闭告警。

## CI Runner 治理

CI 中的 Codex 不应被当作“没有界面的开发者电脑”。
它需要更严格、可重复的执行边界。

### 使用隔离且一次性的 runner

推荐基线：

* 每个任务使用新建容器、VM 或临时 runner。
* 任务结束销毁文件系统和进程。
* 不挂载开发者主目录、SSH 目录或 Docker socket。
* 默认只检出必要仓库和最小历史。
* 使用非 root 用户，根文件系统尽量只读。
* 只给工作目录和专用临时目录写权限。
* 默认关闭出站网络，按任务开放白名单。
* 限制 CPU、内存、磁盘、运行时间和并发。
* 禁止 runner 直接访问生产控制面。

即使在容器内，也不要把完全访问视为绝对安全。
恶意仓库仍可能读取容器中的凭据并通过已开放的网络外传。

### 不在不可信 PR 中暴露密钥

来自 fork 或外部贡献者的代码，应按攻击者控制的输入处理。

1. 外部 PR 首次运行使用无密钥、只读 runner。
2. 不自动执行 PR 修改过的高权限脚本。
3. 需要密钥的阶段必须在受信任分支或人工批准后运行。
4. 审批后重新从受信任提交检出，避免竞态替换。
5. 不把令牌写入命令参数、环境转储、缓存或构建日志。
6. 对日志启用密钥掩码，但不能把掩码当作唯一防线。

### 选择自动化身份

不要让团队共用某个员工的长期个人令牌。
优先选择可归属、可吊销、可轮换并能限制范围的服务身份。

每个凭据应记录：

* 所有者和业务系统。
* 创建日期与过期日期。
* 允许的仓库、环境和操作。
* 存放的密钥管理器路径。
* 轮换方法和紧急吊销方法。
* 对应的成本中心和审计日志源。

ChatGPT 工作区访问令牌、API key 和代码托管平台令牌的审计归属可能不同。
具体认证方式、支持范围和日志行为以官方文档为准。

### 将生成与交付分离

```text theme={null}
只读分析
  -> 生成候选补丁
  -> 静态检查与测试
  -> 人工或策略审查
  -> 创建 PR
  -> 常规 CI 验证
  -> 独立发布审批
```

Codex 阶段不应直接持有生产部署凭据。
真正的发布由现有受控流水线完成，并继续遵守双人审批、变更窗口和回滚制度。

## 事件响应

Codex 事件应纳入企业现有安全事件响应体系，而不是由工具管理员私下处理。

### 需要启动响应的事件

* 代码、提示词、日志或密钥被发送到未批准目的地。
* 账号、令牌、API key 或 runner 凭据疑似泄露。
* 企业策略被绕过、关闭或错误下发。
* 代理执行了破坏性命令、异常推送或生产变更。
* 审计日志中断，关键时间段无法追踪。
* 发现大规模异常用量或未知自动化。
* 第三方 MCP、插件、依赖或仓库被确认恶意。
* 数据驻留、留存或合同边界可能被违反。

### 六步响应流程

**1. 识别与分级**

记录发现时间、报告人、账号、仓库、runner、任务 ID、模型、网络目的地和数据分类。
不要在未确认影响前把事件简单归类为“模型回答错误”。

**2. 立即遏制**

* 禁用相关账号或组。
* 吊销访问令牌、API key 和代码托管凭据。
* 暂停可疑 CI 工作流与 runner 池。
* 从白名单移除可疑域名。
* 将受影响团队策略临时收紧到只读和无网络。
* 必要时断开仓库、MCP 或云端环境连接。

**3. 保存证据**

导出可用的任务、审批、身份、网络、代码托管和 CI 日志。
记录时间范围、时区、哈希和导出操作者，避免在调查前销毁 runner 或覆盖日志。

**4. 分析影响**

确认攻击入口、实际执行命令、读取文件、外发内容、目标域名、提交变更和受影响身份。
区分“模型提出过动作”“用户批准过动作”和“系统实际执行成功”。

**5. 清除与恢复**

轮换所有可能暴露的凭据，清理恶意配置，恢复受保护策略，用干净镜像重建 runner。
代码通过审查后的反向提交恢复，不改写共享历史来掩盖事件。

**6. 通知与改进**

按合同、法律和内部制度评估通知义务。
完成根因分析，把改进落到策略、网络、培训、日志、runner 镜像和检测规则中。

### 事件记录模板

```text theme={null}
事件编号：
发现时间与时区：
当前级别：
受影响工作区、账号、仓库、runner：
数据分类与预计范围：
可疑任务、命令、域名、提交：
已完成的遏制动作：
已吊销或轮换的凭据：
证据位置与完整性校验：
恢复条件：
通知与法务负责人：
后续整改、负责人、截止日期：
```

## 分阶段落地

不要从零直接全员开放。
推荐按四个阶段实施。

### 阶段一：设计

* 完成执行面、身份和数据流梳理。
* 完成合同、训练、驻留、留存和删除评估。
* 明确责任矩阵、数据分类和禁止场景。
* 设计企业身份、权限组和最小策略基线。
* 选定日志、SIEM、预算和事件响应方案。

### 阶段二：小范围试点

* 选择低敏感仓库和受训用户。
* 默认 L0/L1 权限，无生产连接。
* 测试 SSO、SCIM、托管策略和拒绝路径。
* 验证日志字段、导出频率和查询能力。
* 建立用量基线，记录任务成功率和人工返工。

### 阶段三：受控扩展

* 按团队分批开放，不按个人口头申请扩散。
* 引入受控联网、内部镜像和 CI runner。
* 对机密仓库执行单独准入评审。
* 设置预算预警和异常检测。
* 每批上线后复盘权限、事件、成本和采用效果。

### 阶段四：常态运营

* 每季度复核管理员和权限组。
* 每月轮换或检查高价值凭据。
* 每季度演练离职、日志中断和令牌泄露。
* 跟踪官方能力变化并重新验证动态配置。
* 清理过期例外、闲置连接、无所有者自动化。
* 每年至少完成一次端到端治理审计。

## 落地检查表

### 身份与权限

* [ ] 企业 SSO 已启用并验证失败场景。
* [ ] MFA 和管理员条件访问符合企业基线。
* [ ] SCIM 已覆盖入职、转岗、离职和组同步。
* [ ] 禁止共享账号，个人与企业工作区边界明确。
* [ ] `Codex-Admins` 仅包含最少必要人员。
* [ ] 审计读取权限与策略修改权限已分离。
* [ ] 高风险权限有审批、理由和到期时间。
* [ ] 已完成模拟离职并确认所有访问被收回。

### 托管配置与终端

* [ ] 已区分强制要求、托管默认值、项目和用户配置。
* [ ] 禁止开发者本机使用完全访问加无审批组合。
* [ ] 普通用户只能选择批准的沙箱与审批模式。
* [ ] 敏感命令、路径和外部工具有禁止或审批规则。
* [ ] 策略源文件经过版本控制和双人审查。
* [ ] 配置已在各操作系统和客户端版本上验证。
* [ ] 策略冲突、离线和获取失败行为已经测试。
* [ ] 回滚负责人、触发条件和步骤清晰可执行。

### 数据与网络

* [ ] 本地、云端和 API 三种执行面分别完成数据流评估。
* [ ] 训练、留存、驻留、删除和分包商条款已书面确认。
* [ ] 仓库与任务使用的数据分类规则已发布。
* [ ] 严格受限数据默认禁止进入提示词或工作区。
* [ ] 已部署 secret scanning、DLP 或等效技术控制。
* [ ] 命令执行环境默认无出站网络。
* [ ] 域名白名单精确到业务所需范围并有到期时间。
* [ ] MCP、插件、网页和外部仓库按不可信输入治理。

### 审计与成本

* [ ] 已确认当前套餐支持的日志和分析能力。
* [ ] ChatGPT 身份与 API 身份的日志源已分别接入。
* [ ] 日志在源保留窗口内稳定导出到企业系统。
* [ ] 审计日志原文按敏感数据限制访问。
* [ ] 管理员、策略、令牌、网络和异常用量告警已启用。
* [ ] 已按团队、执行面、模型和自动化归集成本。
* [ ] 预算阈值、硬限制和告警负责人已明确。
* [ ] 每周异常复盘和每月管理报告已经排期。

### CI 与事件响应

* [ ] CI 使用一次性、非 root、资源受限的隔离 runner。
* [ ] runner 未挂载宿主敏感目录或 Docker socket。
* [ ] fork PR 和不可信代码运行时不暴露密钥。
* [ ] 自动化身份可归属、最小权限、有限期且可紧急吊销。
* [ ] Codex 生成补丁与生产发布凭据完全分离。
* [ ] 事件响应通讯录和升级路径已经确认。
* [ ] 已演练令牌泄露、异常外联和策略错误下发。
* [ ] 证据保存、通知义务、恢复条件和复盘流程已验证。

## 验收标准

企业治理上线不能以“后台开关已经打开”为验收。
至少需要拿出以下证据：

1. 一个测试员工完成自动开通、转组和离职回收的记录。
2. 一个普通用户尝试进入禁止模式并被拒绝的记录。
3. 一个未批准域名访问失败、批准域名成功的网络测试。
4. 一条测试任务从运行到 SIEM 查询的完整审计链路。
5. 一个 CI 任务在无密钥 fork 场景下被安全执行的证明。
6. 一个过期或吊销令牌不能继续使用的测试。
7. 一份按团队和执行面拆分的用量与成本报告。
8. 一次令牌泄露桌面演练及整改跟踪记录。
9. 一次策略回滚演练，证明可以在目标时间内恢复。
10. 一份由安全、数据、平台和业务负责人共同签署的准入结论。

## 持续复核

企业能力会持续变化，治理基线也必须跟着变化。
建议每次客户端大版本升级、套餐调整、合同续签、新模型开放或新执行面上线时重新检查：

* 新能力是否改变数据流、驻留或留存。
* 新配置是否绕过旧的强制要求。
* 新模型是否改变成本、质量和安全边界。
* 新日志是否需要调整采集字段与告警。
* 新认证方式是否进入正确的审计和计费组织。
* 预览功能是否已经成熟，或行为是否发生变化。

所有动态能力均以 OpenAI 官方文档、组织后台和实际合同为准。
在生产推广前，用测试账号、测试仓库和测试 runner 重新验证，而不是只阅读发布说明。

参考资料：`参考/codex/39-enterprise.md`、`参考/codex/15-permissions.md`、`参考/codex/16-security.md`。