当 Agent 自己审批 Agent：OpenAI 是怎么管住 Codex 的？
TL;DR · AI 摘要
OpenAI 用四层框架控制 Codex Agent，包括沙箱、网络策略、身份治理和 Agent-Native Telemetry，实现高效又安全的自动化开发。
核心要点
- 四层控制框架：沙箱+审批、网络策略、身份绑定、命令分级，兼顾效率与安全
- Auto-review 模式让 AI 审 AI，低风险请求自动放行，高风险需人工干预
- Agent-Native Telemetry 提供完整因果链日志，支持安全分析和运营优化
结构提纲
按章节快速跳转。
当 Coding Agent 能读写仓库和调用工具时，如何平衡研发效率与企业安全？
OpenAI 设计了受限执行、网络策略、身份治理和 Agent-Native Telemetry 四个层面来管控 Codex 行为。
定义技术边界并设置自动审批规则，使用子代理进行 Auto-review 实现智能审查。
默认拒绝出站连接，仅允许已知合规域名，陌生域名需显式审批。
强制 OAuth 凭证存储于系统密钥环，并绑定企业工作区 UUID，实现统一审计。
提供从用户意图到执行结果的完整因果链日志，解决传统 EDR 日志无法解释‘为什么’的问题。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- Codex Agent 安全管控框架
- 受限执行
- 沙箱定义边界
- Auto-review 子代理自动审批
- 网络策略
- 默认拒绝出站连接
- 拉黑高危域名
- 身份治理
- OAuth 凭证存入 OS keyring
- 绑定企业工作区 UUID
- Agent-Native Telemetry
- 记录用户原始提示
- 追踪工具调用链路
金句 / Highlights
值得收藏与分享的关键句。
Auto-review 模式让一个独立子代理审阅 Codex 的动作，对低风险请求自动放行，仅在风险升高时打断用户。
网络策略采用默认拒绝模型，只允许已知合规目的地，拉黑如 pastebin.com 这类数据外泄渠道。
Agent-Native Telemetry 导出用户提示词、工具审批决策、执行结果等事件，构建完整的因果链日志。
当 Codex 这样的 Coding Agent 能读写仓库、运行命令、调用开发工具，它进入研发流水线，你如何同时保住效率和可控性？保证企业安全？
OpenAI 给出的答案是一套四层框架：受限执行 + 网络策略 + 身份治理 + Agent-Native https://t.co/g4bMhudefN" / X
当 Agent 自己审批 Agent：OpenAI 是怎么管住 Codex 的？ 当 Codex 这样的 Coding Agent 能读写仓库、运行命令、调用开发工具，它进入研发流水线，你如何同时保住效率和可控性？保证企业安全？ OpenAI 给出的答案是一套 四层框架：受限执行 + 网络策略 + 身份治理 + Agent-Native Telemetry。指导原则：让低风险的日常操作零摩擦，让高风险操作必须显式停下来等审查。 openai.com/index/running-# 四个控制面 1. 沙箱 + 审批 · 沙箱定义"技术执行边界"：能写哪里、能不能联网、哪些路径只读。 · 审批策略定义"什么情况下必须停下来问人"：通常是越界沙箱时触发。 值得关注的新机制是 Auto-review 模式：一个独立的子代理负责审阅 Codex 的待执行动作和上下文，对低风险请求自动放行，仅在风险升高时才打断用户。这是用 AI 审 AI，把审批本身做成了智能层。 2. 网络访问 OpenAI 不允许 Codex 拥有开放出站权限。策略是三段式： · 允许已知合规目的地 · 拉黑明确不希望访问的域名（示例中是 pastebin. com，典型的数据外泄渠道） · 对陌生域名要求审批 这是默认拒绝、显式允许的网络模型，配合 proxy 实施。 3. 身份与凭证 控制点： · CLI 和 MCP 的 OAuth 凭证强制存入 OS keyring（macOS Keychain） · 强制通过 ChatGPT 登录 · 锁定到指定的企业工作区 UUID 效果：Codex 的所有活动都被绑回工作区级别的统一管控，并自动落入 ChatGPT 合规日志平台。这一步把"Codex 是谁在用、属于哪个组织"变成不可绕过的事实。 4. 命令规则 不是把 shell 命令一视同仁。gh pr view、kubectl get 这类只读命令直接放行；危险命令显式拦截或要求审批。这种"按命令语义分级"的做法，让代理在常规工程流程里几乎感觉不到摩擦，同时保留对危险动作的强制刹车。 5. 配置分发 OpenAI 用三层分发：云端 managed requirements + macOS 托管偏好 + 本地 requirements 文件。其中 requirements 是管理员强制项，用户无法覆盖。这套机制保证全公司基线一致，又允许按团队/环境差异化测试。 # 真正的重点：Agent-Native Telemetry 传统日志的局限 传统 EDR、审计日志只能告诉你"发生了什么"：进程起来了、文件改了、连接尝试了。但面对 AI Agent，安全团队真正缺的信息是 "为什么"——用户的原始意图、Agent 的推理路径、审批决策、工具调用链。 Codex 给的东西 通过 OpenTelemetry 导出以下事件： · 用户原始提示词 · 工具审批决策 · 工具执行结果 · MCP 服务器使用情况 · 网络代理放行/拒绝事件 也就是说，安全团队可以重建 "用户说了什么 → Agent 打算做什么 → 系统批准了什么 → 实际发生了什么 → 网络层是否拦下" 的完整因果链。 # 实战用法：AI 审 AI OpenAI 自己的做法非常具体：当 EDR 报警提示 Codex 行为异常，他们的 AI 安全三角分诊 Agent 会主动拉取 Codex 的遥测，自动区分三类情况： · 预期内的 Agent 行为 · 良性失误 · 真正需要升级响应的事件 只把第三类推给人。这是一个"Agent 的行为由另一个 Agent 来解释"的安全运营范式。 同一份遥测还被复用于运营分析：内部采用率、工具/MCP 使用分布、网络沙箱拦截频率、配置调优方向。一份数据同时服务安全和增长。
Quote
Fotis Chantzis
@ithilgore
10h
We’ve spent a lot of time on the framework underneath Codex, so it can move quickly on routine work while stopping for review when the risk changes. Here’s how we use sandboxing, approvals, network policy, and telemetry to run Codex safely @OpenAI: openai.com/index/running-