本页目标
个人使用 Codex,重点是任务能否完成;企业使用 Codex,首先要回答另一组问题:- 谁可以使用,离职后能否及时收回访问?
- 哪些配置由组织强制,哪些允许开发者自行调整?
- 代码、提示词、输出和日志会流向哪里,保留多久?
- 谁批准了联网、提权、推送、部署或敏感数据访问?
- 自动化任务以谁的身份运行,凭据泄露后如何止损?
- 模型、额度和高成本功能怎样分级开放?
- 发生越权、泄露或异常消耗时,能否快速调查和恢复?
先建立治理边界
企业治理不是“给所有人装好 CLI”之后再补一份制度。 应先划清系统边界,再决定是否开放能力。区分三种执行面
不要假定三种执行面的权限、留存和审计完全相同。
尤其要区分 ChatGPT 工作区身份产生的活动与 API 组织身份产生的活动。
两者可能进入不同的管理后台、日志源和计费口径。
建立责任矩阵
至少指定以下责任人,并为每个角色安排替补:
最重要的原则是职责分离。
能修改全员策略的人,不应成为唯一的审计者;能创建自动化令牌的人,不应独自批准无限期使用。
企业身份与生命周期
身份治理的目标不是“大家能登录”,而是每次访问都能回答:这个人是谁、为什么有权限、权限何时失效。强制企业身份
生产性使用应优先采用企业控制的身份体系:- 将企业工作区连接到组织的身份提供商(IdP)。
- 配置 SSO,并按企业基线强制 MFA。
- 禁止用共享账号代表团队运行日常任务。
- 明确个人账号与企业账号的切换规则。
- 对管理员使用更强认证策略和条件访问。
- 对高风险登录启用 IdP 侧告警与会话撤销。
用组管理授权
建议从少量清晰的组开始:
项目访问应尽量沿用代码托管平台已有的团队和仓库权限。
Codex 权限用于补充产品能力边界,不要制造另一套互相冲突的仓库授权体系。
入职、转岗与离职
身份生命周期应成为可测试的自动化流程。 入职:- HR 系统创建人员记录。
- IdP 根据部门、岗位和地区加入基础组。
- SCIM 将成员同步到对应工作区或权限组。
- 团队负责人确认业务场景和数据级别。
- 成员完成安全培训后才进入正式组。
- 首次使用只开放低风险配置和测试仓库。
- 旧组权限先回收,再授予新组权限。
- 检查个人创建的令牌、云端环境和仓库连接。
- 转移仍需保留的自动化任务所有权。
- 复核管理员、审计读取者等高权限角色。
- IdP 禁用账号并撤销活跃会话。
- SCIM 从工作区和授权组移除成员。
- 吊销其创建或保管的令牌和密钥。
- 检查 CI、定时任务、机器人和共享 runner 是否仍引用旧凭据。
- 转移必要资产并保留合规所需记录。
- 在规定时限内验证访问已真正失效。
团队权限模型
权限设计应从业务场景出发,而不是从“工具能开什么”出发。按风险分层
默认成员从 L0 或 L1 开始。
权限提升应绑定明确场景、负责人、到期时间和补偿控制,不能因“审批太多”永久放宽。
沙箱与审批是两个控制面
沙箱决定进程技术上能访问什么;审批决定何时必须停下来等待授权。 企业基线通常应限制成员可选择的沙箱和审批组合。 以下是说明意图的策略示例,不保证适用于所有版本:高风险动作的固定规则
下列动作应被禁止,或至少强制人工批准:- 读取
.env、SSH 私钥、云凭据目录或浏览器凭据。 - 修改 shell 启动文件、系统服务、计划任务和登录项。
- 使用
sudo、管理员权限或绕过沙箱。 - 删除大量文件、覆盖备份或改写共享 Git 历史。
- 直接推送受保护分支、合并 PR 或触发生产发布。
- 向未批准域名上传代码、日志、提示词或构建产物。
- 安装来源不明的 MCP、插件、Skill、包或二进制文件。
- 关闭安全扫描、分支保护、签名验证或审计采集。
托管配置与变更管理
企业需要区分“强制要求”和“托管默认值”。配置优先级要可解释
管理员应维护一份配置优先级说明,至少包含:- 哪一层拥有最高优先级。
- 冲突时客户端如何处理。
- 用户在哪里查看实际生效值。
- 不合规值是报错、回退还是被忽略。
- 离线设备多久必须重新获取企业策略。
- 策略获取失败时是继续运行还是故障关闭。
把策略当代码管理
即使最终通过管理后台下发,也建议把策略源文件放在受控私有仓库中:- 使用代码审查和受保护分支。
- 标注策略版本、所有者、适用组和生效日期。
- 每次变更附风险说明、测试证据和回滚方案。
- 禁止同一人提出、批准并发布高风险放宽。
- 在测试组验证后再分批扩大范围。
- 保留管理后台中的变更记录或截图证据。
- 定期比较源文件、后台配置和终端实际状态。
验证拒绝路径
策略测试不能只验证“允许的任务能成功”,还要验证“不允许的任务确实失败”。 每次策略发布至少测试:- 标准用户不能进入未批准的完全访问模式。
- 未批准域名无法访问。
- 敏感路径不能读取或外发。
- 普通用户不能修改托管要求。
- 管理员组之外看不到管理能力。
- 过期令牌和离职账号不能继续运行任务。
- 受保护分支不能被代理直接推送。
- 策略获取失败时行为符合组织预期。
数据治理
“企业数据不用于训练”并不等于“不产生任何数据”。 治理评估必须按数据类型、执行面和生命周期逐项确认。建立数据分类
数据分类应写入研发规范、仓库标签和培训材料。
不要依赖开发者临时判断“这段内容应该没关系”。
绘制数据流
对每个准入场景画出以下路径:核对训练、留存与驻留
采购和上线评审至少应获得以下书面结论:- 企业输入和输出是否用于训练模型。
- 各执行面的服务端数据是否保留以及保留多久。
- 零数据留存是否适用于当前套餐、功能和地区。
- 审计日志是否独立保留,期限是否不同。
- 可选择哪些数据驻留区域,覆盖哪些数据类型。
- 支持请求、滥用监测和安全日志是否存在例外。
- 删除工作区、成员、任务或仓库连接后如何删除数据。
- 分包商、跨境传输和合同附件如何约定。
最小化发送内容
即使合同允许,也应执行数据最小化:- 用最小相关文件代替整个仓库。
- 用脱敏样本代替真实客户记录。
- 删除日志中的 cookie、令牌、邮箱和请求正文。
- 不把生产数据库导出到开发目录。
- 不将密钥放入提示词、代码注释、测试夹具或
/tmp。 - 对 PR 评论、Issue 和网页内容按不可信输入处理。
- 对输出再次扫描,防止复述输入中的敏感值。
网络白名单与外部连接
网络权限决定代理能否把已读取的数据带出当前边界,也决定它能否下载恶意依赖或接受提示注入内容。默认拒绝,按需开放
企业网络策略建议采用以下顺序:- 默认关闭命令执行环境的出站网络。
- 为确有需要的场景建立精确域名白名单。
- 按用户组、环境和用途分别维护白名单。
- 禁止直接访问裸 IP,除非有明确业务依据。
- 通过企业代理、DNS 和防火墙记录出口日志。
- 对上传、Webhook、文件分享和匿名存储域名重点拦截。
- 定期清理不再使用的域名和通配符。
建立域名申请单
对于包管理器,优先使用企业制品库和依赖代理。
这样既能缩小域名范围,也能执行恶意包扫描、许可证审查和版本固定。
把 MCP 和插件视为第三方应用
MCP、插件和其他外部工具可能读取会话上下文、访问外部系统并执行有副作用的动作。 接入前应评估:- 发布者和代码来源是否可信。
- 工具声明的权限是否与实际行为一致。
- 能读取哪些数据,能调用哪些写操作。
- 使用什么身份,令牌由谁保管。
- 是否支持只读模式、审批和细粒度范围。
- 日志是否进入企业 SIEM。
- 撤销集成后令牌和缓存是否删除。
审计与合规
审计的目标是重建事实,而不是单纯统计活跃人数。区分三类记录
Analytics 仪表盘、Analytics API、Compliance API 或管理后台的实际可用范围、字段和延迟属于动态能力。
应以当前套餐和官方文档为准,并在试点期用真实测试事件验证。
设计日志管道
- 管理员、所有者或审计角色被新增。
- 企业策略被放宽或分配范围扩大。
- 新建、导出、轮换或吊销访问令牌。
- 大量访问新仓库或敏感项目。
- 非工作时间出现异常高用量。
- 突然切换到高成本模型或高推理强度。
- 大量审批绕过、提权或完全访问尝试。
- 向新域名发送请求或出现大流量上传。
- 离职账号、禁用账号或过期令牌仍有活动。
保护审计数据
审计日志本身可能包含提示词、响应、代码片段、用户标识和安全事件细节。 因此必须:- 按敏感数据保护,不向所有管理员默认开放原文。
- 对日常报表使用聚合数据和最小字段。
- 将调查访问与普通用量查看分开授权。
- 为日志导出密钥设置短周期轮换和专用服务身份。
- 对读取、导出和删除日志的行为再次审计。
- 按法律与合同要求设置留存和诉讼保全。
模型与成本控制
成本治理应同时看预算、业务价值和风险,不能只追求减少 token。建立场景与模型目录
具体模型名称、上下文限制、推理档位和服务层级会变化,以官方模型文档和组织后台为准。
托管默认值用于引导大多数任务,不应妨碍经批准的复杂场景。
设置预算护栏
建议同时实施:- 工作区月度预算和预警阈值。
- 按团队、产品、成本中心或服务身份归集。
- 每用户或每自动化流程的异常基线。
- CI 并发、超时、重试次数和每日任务上限。
- 高成本模型与高推理强度的受控授权。
- 大仓库任务的路径限制和输入裁剪。
- 失败任务的退避重试,防止无限循环。
- 定期清理无人负责的令牌与自动化任务。
每周进行异常复盘
成本负责人每周至少检查:- 总用量与预算预测。
- 按团队、用户、执行面和模型的变化。
- 单次任务、失败重试和长会话异常。
- 新增自动化、仓库和外部工具造成的增量。
- 高成本任务是否产生可验证的业务结果。
- 是否存在账号共享、令牌泄露或失控循环迹象。
CI Runner 治理
CI 中的 Codex 不应被当作“没有界面的开发者电脑”。 它需要更严格、可重复的执行边界。使用隔离且一次性的 runner
推荐基线:- 每个任务使用新建容器、VM 或临时 runner。
- 任务结束销毁文件系统和进程。
- 不挂载开发者主目录、SSH 目录或 Docker socket。
- 默认只检出必要仓库和最小历史。
- 使用非 root 用户,根文件系统尽量只读。
- 只给工作目录和专用临时目录写权限。
- 默认关闭出站网络,按任务开放白名单。
- 限制 CPU、内存、磁盘、运行时间和并发。
- 禁止 runner 直接访问生产控制面。
不在不可信 PR 中暴露密钥
来自 fork 或外部贡献者的代码,应按攻击者控制的输入处理。- 外部 PR 首次运行使用无密钥、只读 runner。
- 不自动执行 PR 修改过的高权限脚本。
- 需要密钥的阶段必须在受信任分支或人工批准后运行。
- 审批后重新从受信任提交检出,避免竞态替换。
- 不把令牌写入命令参数、环境转储、缓存或构建日志。
- 对日志启用密钥掩码,但不能把掩码当作唯一防线。
选择自动化身份
不要让团队共用某个员工的长期个人令牌。 优先选择可归属、可吊销、可轮换并能限制范围的服务身份。 每个凭据应记录:- 所有者和业务系统。
- 创建日期与过期日期。
- 允许的仓库、环境和操作。
- 存放的密钥管理器路径。
- 轮换方法和紧急吊销方法。
- 对应的成本中心和审计日志源。
将生成与交付分离
事件响应
Codex 事件应纳入企业现有安全事件响应体系,而不是由工具管理员私下处理。需要启动响应的事件
- 代码、提示词、日志或密钥被发送到未批准目的地。
- 账号、令牌、API key 或 runner 凭据疑似泄露。
- 企业策略被绕过、关闭或错误下发。
- 代理执行了破坏性命令、异常推送或生产变更。
- 审计日志中断,关键时间段无法追踪。
- 发现大规模异常用量或未知自动化。
- 第三方 MCP、插件、依赖或仓库被确认恶意。
- 数据驻留、留存或合同边界可能被违反。
六步响应流程
1. 识别与分级 记录发现时间、报告人、账号、仓库、runner、任务 ID、模型、网络目的地和数据分类。 不要在未确认影响前把事件简单归类为“模型回答错误”。 2. 立即遏制- 禁用相关账号或组。
- 吊销访问令牌、API key 和代码托管凭据。
- 暂停可疑 CI 工作流与 runner 池。
- 从白名单移除可疑域名。
- 将受影响团队策略临时收紧到只读和无网络。
- 必要时断开仓库、MCP 或云端环境连接。
事件记录模板
分阶段落地
不要从零直接全员开放。 推荐按四个阶段实施。阶段一:设计
- 完成执行面、身份和数据流梳理。
- 完成合同、训练、驻留、留存和删除评估。
- 明确责任矩阵、数据分类和禁止场景。
- 设计企业身份、权限组和最小策略基线。
- 选定日志、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 生成补丁与生产发布凭据完全分离。
- 事件响应通讯录和升级路径已经确认。
- 已演练令牌泄露、异常外联和策略错误下发。
- 证据保存、通知义务、恢复条件和复盘流程已验证。
验收标准
企业治理上线不能以“后台开关已经打开”为验收。 至少需要拿出以下证据:- 一个测试员工完成自动开通、转组和离职回收的记录。
- 一个普通用户尝试进入禁止模式并被拒绝的记录。
- 一个未批准域名访问失败、批准域名成功的网络测试。
- 一条测试任务从运行到 SIEM 查询的完整审计链路。
- 一个 CI 任务在无密钥 fork 场景下被安全执行的证明。
- 一个过期或吊销令牌不能继续使用的测试。
- 一份按团队和执行面拆分的用量与成本报告。
- 一次令牌泄露桌面演练及整改跟踪记录。
- 一次策略回滚演练,证明可以在目标时间内恢复。
- 一份由安全、数据、平台和业务负责人共同签署的准入结论。
持续复核
企业能力会持续变化,治理基线也必须跟着变化。 建议每次客户端大版本升级、套餐调整、合同续签、新模型开放或新执行面上线时重新检查:- 新能力是否改变数据流、驻留或留存。
- 新配置是否绕过旧的强制要求。
- 新模型是否改变成本、质量和安全边界。
- 新日志是否需要调整采集字段与告警。
- 新认证方式是否进入正确的审计和计费组织。
- 预览功能是否已经成熟,或行为是否发生变化。
参考/codex/39-enterprise.md、参考/codex/15-permissions.md、参考/codex/16-security.md。