跳到主要内容

本文为非官方中文翻译，内容以 OpenAI 官方英文文档为准。
官方来源：https://developers.openai.com/codex/concepts/sandboxing/auto-review

自动审查

Codex 如何通过审查代理路由沙箱边界审批

自动审查会用一个独立的审查代理替代沙箱边界上的人工审批。主 Codex 代理仍然在同一个沙箱内运行，具有相同的审批策略，以及相同的网络和文件系统限制。区别在于，由谁来审查符合条件的提权请求。

自动审查仅在审批是交互式时适用。实际上，这意味着 approval_policy = "on-request"，或仍会显示相关提示类别的细粒度审批策略。使用 approval_policy = "never" 时，没有任何内容可供审查。

自动审查如何工作​

从高层看，流程如下：

  1. 主代理在 read-only 或 workspace-write 内工作。
  2. 当它需要跨越沙箱边界时，会请求审批。
  3. 如果 approvals_reviewer = "auto_review"，Codex 会将该审批请求路由给一个独立的审查代理，而不是停下来等待人工处理。
  4. 审查代理决定该操作是否应执行，并返回理由。
  5. 如果该操作获批，执行将继续。如果被拒绝，主代理会被指示寻找实质上更安全的路径，或停止并询问用户。

自动审查是审查者的替换，不是权限授予。它不会扩展 writable_roots、启用网络访问或削弱受保护路径。它只会改变 Codex 处理那些本来就需要审批的操作的方式。

何时触发​

自动审查会评估那些原本会暂停以等待人工处理的审批请求。这些包括：

  • 请求提升沙箱权限的 shell 或 exec 工具调用。
  • 被当前沙箱或策略阻止的网络请求。
  • 对允许的可写根目录之外文件的编辑。
  • 基于其工具注解或已配置审批模式而需要审批的 MCP 或应用工具调用。
  • Browser Use 访问新网站或新域名。

自动审查不会针对沙箱内已允许的常规操作运行。如果某个命令可以在当前 sandbox_mode 下运行，或者某个工具调用保持在允许的策略范围内，主代理会继续执行而无需审查。

Computer Use 是一个单独的情况。Computer Use 的应用审批仍会直接展示给用户，因此自动审查不会替代这些应用级提示。

自动审查会拦截什么​

从高层看，自动审查旨在拦截如下操作：

  • 将私人数据、密钥或凭据发送到不受信任的目标
  • 探查凭据、令牌、cookie 或会话材料
  • 广泛或持久地削弱安全性
  • 带有严重不可逆损害风险的破坏性操作

确切策略位于开源 Codex 仓库中： policy_template.md 和 policy.md。 该策略可以通过 guardian_policy_config 按企业定制，或通过本地 [auto_review].policy 按用户定制。

审查者能看到什么​

审查者本身也是一个 Codex 代理，但其职责比主代理更窄：决定某个特定的越界操作是否应当执行。

审查者会看到一份精简的转录内容，以及精确的审批请求。这通常包括用户消息、展示给用户的助手更新、相关工具调用和工具输出，以及当前被提议批准的操作。它也可以执行只读检查来收集缺失的上下文，但很少这样做。

隐藏的助手推理不会包含在内。自动审查看到的是保留的对话条目和工具证据，而不是私有的 chain-of-thought。

拒绝与失败行为​

明确拒绝不会被视为普通的沙箱错误。Codex 会将审查理由返回给主代理，并添加一条更强的指令：

  • 不要通过变通方法、间接执行或规避策略来追求同样的结果。
  • 仅在存在实质上更安全的替代方案时继续。
  • 否则，停止并询问用户。

Codex 还会对每个 turn 应用一个拒绝断路器。在当前开源实现中，同一个 turn 内连续 3 次拒绝，或同一个 turn 中最近 50 次审查的滚动窗口内出现 10 次拒绝时，自动审查会中断该 turn。

任何非拒绝结果都会重置连续拒绝计数器。当断路器触发时，Codex 会发出警告，并通过中断终止当前 turn，而不是让代理继续循环发起更多提权尝试。

超时会与明确拒绝分开呈现，并且主代理会被告知：仅凭超时本身并不能证明该操作不安全。

对于被拒绝的操作，还存在一条显式覆盖路径。在当前开源 TUI 中，运行 /approve 以打开 Auto-review Denials 选择器，然后选择一个最近被拒绝的操作，为其批准一次重试。Codex 会为每个线程最多记录 10 个最近拒绝项。该批准是狭义的：它仅适用于被拒绝的那个精确操作，而不适用于未来类似操作；它只会在相同上下文中记录一次重试；并且该重试仍然会经过自动审查。在底层，Codex 会为该精确操作注入一个开发者作用域的审批标记。审查者随后会将该显式用户覆盖视为上下文的一部分，但仍然遵循策略；如果策略规定用户不能覆盖该类拒绝，它仍然可以再次拒绝。

配置​

有关设置细节，请参见 托管配置。

默认审查策略位于开源 Codex 仓库中： core/src/guardian/policy.md。 企业可以在托管 requirements 中使用 guardian_policy_config 替换其租户特定部分。个人用户也可以在其 config.toml 中设置本地 [auto_review].policy，但托管 requirements 具有更高优先级：

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

要自定义该策略，请先复制整个默认策略措辞，然后根据你的个人风险画像逐步调整。

在不削弱安全性的情况下减少审查量​

当沙箱已经覆盖你常见的安全工作流时，自动审查效果最佳。如果有太多日常操作需要审查，应先修复边界，而不是教审查者永远批准这些高噪声提权请求。

在实践中，最有效的改动是：

  • 为临时目录或你有意使用的相邻仓库添加收窄范围的 writable_roots。
  • 添加范围收窄的 前缀规则。优先使用精确的命令前缀，例如 ["cargo", "test"] 或 ["pnpm", "run", "lint"]，而不是宽泛模式，如 ["python"] 或 ["curl"]。宽泛规则往往会抹掉自动审查本应守护的那道边界。

自动审查会话转录默认保留在 ~/.codex/sessions 下，因此你可以先让 Codex 分析那里的历史流量，再更改策略或权限。

限制​

自动审查改进了长时间运行的 agentic 工作的默认运行状态，但它并不是确定性的安全保证。

  • 它只评估那些请求跨越边界的操作。
  • 它仍然可能出错，尤其是在对抗性或异常上下文中。
  • 它应当作为良好沙箱设计、监控和组织特定策略的补充，而不是替代。

关于研究动机和已发布的评估结果，请参见 Alignment Research 关于自动审查的文章。