Skip to main content

本页目标

个人使用 Codex,重点是任务能否完成;企业使用 Codex,首先要回答另一组问题:
  • 谁可以使用,离职后能否及时收回访问?
  • 哪些配置由组织强制,哪些允许开发者自行调整?
  • 代码、提示词、输出和日志会流向哪里,保留多久?
  • 谁批准了联网、提权、推送、部署或敏感数据访问?
  • 自动化任务以谁的身份运行,凭据泄露后如何止损?
  • 模型、额度和高成本功能怎样分级开放?
  • 发生越权、泄露或异常消耗时,能否快速调查和恢复?
本页面向工作区所有者、平台工程、安全、合规、研发效能和团队负责人。 目标不是列出一组后台开关,而是建立一套可以持续执行、审计和改进的控制体系。
Codex 的套餐名称、管理后台路径、角色名称、模型、策略键、日志字段、保留期限、数据驻留区域、API 端点及预览功能会变化。 涉及这些动态能力时,以组织合同、当前管理后台、已安装版本的 codex --help 和 OpenAI 官方文档为准。 上线前应由安全、法务和采购共同核对,不要把本文示例当作合同承诺。

先建立治理边界

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

区分三种执行面

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

建立责任矩阵

至少指定以下责任人,并为每个角色安排替补: 最重要的原则是职责分离。 能修改全员策略的人,不应成为唯一的审计者;能创建自动化令牌的人,不应独自批准无限期使用。

企业身份与生命周期

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

强制企业身份

生产性使用应优先采用企业控制的身份体系:
  1. 将企业工作区连接到组织的身份提供商(IdP)。
  2. 配置 SSO,并按企业基线强制 MFA。
  3. 禁止用共享账号代表团队运行日常任务。
  4. 明确个人账号与企业账号的切换规则。
  5. 对管理员使用更强认证策略和条件访问。
  6. 对高风险登录启用 IdP 侧告警与会话撤销。
SSO 解决“如何认证”,SCIM 解决“成员如何自动增删”,RBAC 解决“成员能做什么”。 三者需要一起实施,不能用其中一个替代另外两个。

用组管理授权

建议从少量清晰的组开始: 项目访问应尽量沿用代码托管平台已有的团队和仓库权限。 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 或 L1 开始。 权限提升应绑定明确场景、负责人、到期时间和补偿控制,不能因“审批太多”永久放宽。

沙箱与审批是两个控制面

沙箱决定进程技术上能访问什么;审批决定何时必须停下来等待授权。 企业基线通常应限制成员可选择的沙箱和审批组合。 以下是说明意图的策略示例,不保证适用于所有版本:
配置键和取值属于动态能力。 部署前必须对照官方“企业托管配置”文档和当前客户端版本验证。 不要在开发者本机或生产主机上允许同时关闭沙箱与审批。 确需高权限自动化时,把权限放在一次性、隔离、无持久凭据的 runner 内,而不是放宽员工设备。

高风险动作的固定规则

下列动作应被禁止,或至少强制人工批准:
  • 读取 .env、SSH 私钥、云凭据目录或浏览器凭据。
  • 修改 shell 启动文件、系统服务、计划任务和登录项。
  • 使用 sudo、管理员权限或绕过沙箱。
  • 删除大量文件、覆盖备份或改写共享 Git 历史。
  • 直接推送受保护分支、合并 PR 或触发生产发布。
  • 向未批准域名上传代码、日志、提示词或构建产物。
  • 安装来源不明的 MCP、插件、Skill、包或二进制文件。
  • 关闭安全扫描、分支保护、签名验证或审计采集。
命令规则只是一层补充控制。 最终还要依赖操作系统权限、代码托管平台保护、网络出口和流水线审批形成纵深防御。

托管配置与变更管理

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

配置优先级要可解释

管理员应维护一份配置优先级说明,至少包含:
  1. 哪一层拥有最高优先级。
  2. 冲突时客户端如何处理。
  3. 用户在哪里查看实际生效值。
  4. 不合规值是报错、回退还是被忽略。
  5. 离线设备多久必须重新获取企业策略。
  6. 策略获取失败时是继续运行还是故障关闭。
云端策略、系统级文件、MDM 分发路径和客户端支持范围会随平台变化。 Windows、macOS、Linux 的路径和能力也可能不同,应以官方托管配置文档为准。

把策略当代码管理

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

验证拒绝路径

策略测试不能只验证“允许的任务能成功”,还要验证“不允许的任务确实失败”。 每次策略发布至少测试:
  • 标准用户不能进入未批准的完全访问模式。
  • 未批准域名无法访问。
  • 敏感路径不能读取或外发。
  • 普通用户不能修改托管要求。
  • 管理员组之外看不到管理能力。
  • 过期令牌和离职账号不能继续运行任务。
  • 受保护分支不能被代理直接推送。
  • 策略获取失败时行为符合组织预期。

数据治理

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

建立数据分类

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

绘制数据流

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

核对训练、留存与驻留

采购和上线评审至少应获得以下书面结论:
  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、包管理镜像和登录域名可能需要单独验证。

建立域名申请单

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

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

MCP、插件和其他外部工具可能读取会话上下文、访问外部系统并执行有副作用的动作。 接入前应评估:
  • 发布者和代码来源是否可信。
  • 工具声明的权限是否与实际行为一致。
  • 能读取哪些数据,能调用哪些写操作。
  • 使用什么身份,令牌由谁保管。
  • 是否支持只读模式、审批和细粒度范围。
  • 日志是否进入企业 SIEM。
  • 撤销集成后令牌和缓存是否删除。
未知网页、README、Issue、工具返回值和依赖安装脚本都可能包含提示注入。 代理读到的内容不是管理员授权,不能因为文档写着“必须执行”就自动提高权限。

审计与合规

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

区分三类记录

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

设计日志管道

采集任务要监控自身健康状态。 如果官方源日志保留窗口较短,导出失败可能导致不可恢复的审计缺口。 至少对以下事件告警:
  • 管理员、所有者或审计角色被新增。
  • 企业策略被放宽或分配范围扩大。
  • 新建、导出、轮换或吊销访问令牌。
  • 大量访问新仓库或敏感项目。
  • 非工作时间出现异常高用量。
  • 突然切换到高成本模型或高推理强度。
  • 大量审批绕过、提权或完全访问尝试。
  • 向新域名发送请求或出现大流量上传。
  • 离职账号、禁用账号或过期令牌仍有活动。

保护审计数据

审计日志本身可能包含提示词、响应、代码片段、用户标识和安全事件细节。 因此必须:
  • 按敏感数据保护,不向所有管理员默认开放原文。
  • 对日常报表使用聚合数据和最小字段。
  • 将调查访问与普通用量查看分开授权。
  • 为日志导出密钥设置短周期轮换和专用服务身份。
  • 对读取、导出和删除日志的行为再次审计。
  • 按法律与合同要求设置留存和诉讼保全。
不要把“可审计”理解为“所有管理人员都能浏览员工提示词”。 审计访问同样需要业务必要性、审批和记录。

模型与成本控制

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

建立场景与模型目录

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

设置预算护栏

建议同时实施:
  • 工作区月度预算和预警阈值。
  • 按团队、产品、成本中心或服务身份归集。
  • 每用户或每自动化流程的异常基线。
  • 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 和代码托管平台令牌的审计归属可能不同。 具体认证方式、支持范围和日志行为以官方文档为准。

将生成与交付分离

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

事件响应

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

需要启动响应的事件

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

六步响应流程

1. 识别与分级 记录发现时间、报告人、账号、仓库、runner、任务 ID、模型、网络目的地和数据分类。 不要在未确认影响前把事件简单归类为“模型回答错误”。 2. 立即遏制
  • 禁用相关账号或组。
  • 吊销访问令牌、API key 和代码托管凭据。
  • 暂停可疑 CI 工作流与 runner 池。
  • 从白名单移除可疑域名。
  • 将受影响团队策略临时收紧到只读和无网络。
  • 必要时断开仓库、MCP 或云端环境连接。
3. 保存证据 导出可用的任务、审批、身份、网络、代码托管和 CI 日志。 记录时间范围、时区、哈希和导出操作者,避免在调查前销毁 runner 或覆盖日志。 4. 分析影响 确认攻击入口、实际执行命令、读取文件、外发内容、目标域名、提交变更和受影响身份。 区分“模型提出过动作”“用户批准过动作”和“系统实际执行成功”。 5. 清除与恢复 轮换所有可能暴露的凭据,清理恶意配置,恢复受保护策略,用干净镜像重建 runner。 代码通过审查后的反向提交恢复,不改写共享历史来掩盖事件。 6. 通知与改进 按合同、法律和内部制度评估通知义务。 完成根因分析,把改进落到策略、网络、培训、日志、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。