自動審查

自動審查使用單獨的審查智能體，取代沙箱邊界處的人工核准。 Codex 主智能體仍在同一個沙箱內執行，採用相同的核准策略，以及相同的網路和檔案系統限制。 不同之處在於由誰審查符合條件的權限提升請求。

在 ChatGPT 桌面應用中，選擇獲准的 Daybreak 模型時， 如果你的賬戶可使用 Approve for me 模式且組織策略允許， 權限控制項會自動切換到該模式。使用桌面應用的 /model 命令時也會如此。如果該模式 不可用，當前權限模式將保持不變。模型選擇 絕不會覆蓋組織管理要求。

在為獲准的安全模型啟用 Full Access 之前， ChatGPT 桌面應用會顯示關於危險操作的模型專屬警告。該 警告建議改用 Approve for me，並連結到 審查策略設定。該警告不會恢復 沙箱邊界，也不會覆蓋組織策略。

自動審查的工作原理

概括而言，流程如下：

1. 主智能體在 read-only 或 workspace-write 內工作。
2. 當它需要跨越沙箱邊界時，會請求核准。
3. 如果 approvals_reviewer = "auto_review"，Codex 會將該核准請求 傳送給單獨的審查智能體，而不是停下來等待人工處理。
4. 審查智能體決定是否應執行該操作，並返回理由。
5. 如果操作獲得核准，則繼續執行。如果被拒絕，主 智能體會收到指示，要求尋找實質上更安全的路徑，或者停止並詢問 使用者。

自動審查只是更換審查者，並非授予權限。它不會擴充套件 writable_roots、啟用網路存取或放寬受保護路徑。它只會 改變 Codex 處理原本就需要核准的操作的方式。

觸發時機

自動審查會評估原本會暫停並等待人工處理的核准請求。 其中包括：

• 請求提升沙箱權限的 Shell 或 exec 工具呼叫。
• 被當前沙箱或策略阻止的網路請求。
• 對允許寫入的根目錄之外檔案的編輯。
• 因工具註解或所設定的核准模式而需要核准的 MCP 或應用工具呼叫。
• Computer Use 對新網站或域名的存取。

對於沙箱內已允許的常規操作，自動審查不會執行。 如果命令可以在當前 sandbox_mode 下執行，或者工具呼叫 未超出允許的策略，主智能體會繼續執行而無需審查。

Computer Use 是一種特殊情況。Computer Use 的應用核准仍會 直接向用戶顯示，因此自動審查不會取代這些應用層提示。

自動審查會阻止哪些操作

概括而言，自動審查旨在阻止以下操作：

• 將私有資料、金鑰或憑據傳送到不可信目的地
• 探查憑據、token、cookie 或會話材料
• 大範圍或持久地削弱安全性
• 存在重大不可逆損害風險的破壞性操作

確切策略位於開源 Codex 儲存庫中： policy_template.md 和 policy.md。 企業可以使用 guardian_policy_config 自定義該策略，使用者也可以通過本機 [auto_review].policy進行自定義。

審查智能體看到的內容

審查智能體本身也是 Codex 智能體，但其職責比主智能體更窄： 決定是否應執行某項跨越邊界的具體操作。

審查智能體會看到一份精簡的對話記錄和確切的核准請求。其中 通常包括使用者訊息、向用戶顯示的助手更新、相關工具 呼叫及工具輸出，以及當前擬核准的操作。它還可以 執行只讀檢查以收集缺失的上下文，但很少這樣做。

其中不包含隱藏的助手推理。自動審檢視到的是保留的 聊天專案和工具證據，而非私有思維鏈。

拒絕與失敗行為

明確拒絕不會被視為普通的沙箱錯誤。Codex 會將 審查理由返回給主智能體，並新增更嚴格的指示：

• 不要通過變通方法、間接執行或規避策略來追求同一結果。
• 僅在有實質上更安全的替代方案時繼續。
• 否則，停止並詢問使用者。

Codex 還會在每輪中應用拒絕熔斷器。在當前 開源實現中，如果同一輪內連續拒絕 3 次，或最近 50 次 審查的滾動視窗內拒絕 10 次，自動審查會中斷該輪。

任何非拒絕結果都會重置連續拒絕計數器。觸發熔斷器時， Codex 會發出警告並通過中斷終止當前輪次，而不是 讓智能體迴圈嘗試更多權限提升請求。

超時會與明確拒絕分開顯示，並且主智能體會 得知僅憑超時並不能證明操作不安全。

對於遭拒操作，還有一條明確的覆蓋路徑。在當前 開源 TUI 中，執行 /approve 開啟 Auto-review Denials 選擇器，然後 選擇一項近期被拒絕的操作，核准進行一次重試。Codex 每項任務最多記錄 10 項 近期拒絕。該核准的範圍很窄：它只適用於確切的 被拒操作，不適用於未來類似的操作；它記錄為在 同一上下文中重試一次；並且重試仍會經過自動審查。其底層機制是， Codex 會為該確切操作注入開發者範圍的核准標記。 審查智能體隨後會將該明確的使用者覆蓋作為上下文，但仍會遵循 策略；如果策略規定使用者無法覆蓋該類 拒絕，它仍可再次拒絕。

設定

有關設定詳情，請參閱 託管設定。

預設審查策略位於開源 Codex 儲存庫中： core/src/guardian/policy.md。 企業可以使用託管要求中的 guardian_policy_config 替換其租戶專屬部分。 個人使用者也可以在自己的 config.toml 中設定本機 [auto_review].policy， 但託管要求優先：

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

若要自定義策略，請先複製完整的預設策略文本，然後 根據你的個人風險狀況進行迭代。

設定已授權的網路安全專案

對於已授權的安全工作，請將自動審查與書面 專案範圍和最小權限權限設定檔結合使用。 使用獲准的實驗室目標，記錄操作和專案時間視窗，並將 生產系統、無關主機、憑據和持久更改 排除在範圍之外，除非已明確授權。

[auto_review].policy 和 guardian_policy_config 都會替換當前的 審查策略。它們不會與模型捆綁的策略或 組織管理的策略合併。內建審查指令和響應 格式仍然適用。使用任一範例之前，請複製完整的當前 策略，保留每條現有規則，並新增適用於已核准工作的規則。 將大寫佔位符替換為該完整策略。如果無法 存取當前策略，請勿覆蓋它。

以下本機 config.toml 模板會啟用審查，並在現有審查策略之後新增有範圍限制的 條件：

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = ":workspace"

[auto_review]
policy = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.
- Approved actions: inspect the target, reproduce authorized vulnerabilities,
  and validate fixes within the documented engagement window.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only actions against the approved target that match the documented
  engagement scope and approved actions.
- Deny out-of-scope or unknown hosts, production access, credential theft,
  persistence, data exfiltration, destructive operations, and policy bypass.
- Deny ambiguous actions and high-impact changes until a human explicitly
  approves the exact target, action, and side effects.
"""

請將範例目標和允許的操作替換為實際獲批的範圍。 使用獨立的檔案系統和網路規則強制執行目標限制； 審查指令無法取代這些邊界。

組織可以在託管 requirements.toml 中強制執行相同條件：

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
default_permissions = ":workspace"

guardian_policy_config = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only approved actions against the documented engagement target.
- Deny out-of-scope hosts, production access, credential theft, persistence,
  data exfiltration, destructive operations, and attempts to bypass policy.
- Deny ambiguous or high-impact actions until a human explicitly approves the
  exact target, action, and side effects.
"""

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

allowed_permission_profiles 控制當前權限設定檔。 在仍使用舊版 sandbox_mode 的部署中，allowed_sandbox_modes 也會阻止完全存取。

託管 guardian_policy_config 的優先順序高於使用者的本機 [auto_review].policy。請保留 approval_policy = "on-request" 或其他 符合條件的互動式核准策略，並保留可強制執行的沙箱邊界。 使用 approval_policy = "never"、:danger-full-access 或 --yolo 時，操作 可能不會建立審查所需的跨邊界核准請求。

僅將網路目的地加入允許列表並不會觸發審查。當沙箱內的操作仍必須交由審查智能體處理時， 請新增帶有 decision = "prompt" 的明確命令規則， 或將敏感 MCP 工具設定為需要核准。

有關模型存取、engagement 設定和自定義智能體工作流程，請參閱模型與 Trusted Access和推薦設定；有關企業優先順序和支援的客戶端版本，請參閱託管設定。對於自定義 API 或 Agents SDK 執行框架，請使用防護措施與人工審查。

在不削弱安全性的情況下減少審查量

當沙箱已經覆蓋常見的安全工作流程時，自動審查的效果最佳。 如果太多日常操作需要審查，請先修正邊界， 而不是教審查智能體永遠核准嘈雜的權限提升請求。

在實踐中，影響最大的更改包括：

• 為你有意使用的暫存目錄或相鄰儲存庫新增範圍嚴格的 writable_roots。
• 新增範圍嚴格的字首規則。與 ["python"] 或 ["curl"] 等寬泛 模式相比，應優先使用 ["cargo", "test"] 或 ["pnpm", "run", "lint"] 等精確命令 字首。寬泛規則往往會抹去自動審查原本要守護的 邊界。

預設情況下，自動審查會話記錄保留在 ~/.codex/sessions 下， 因此你可以在更改策略或權限前，讓 Codex 分析其中的歷史流量。

限制

自動審查改善了長時間執行的智能體工作的預設執行狀態， 但它並非確定性的安全保證。

• 它只評估請求跨越邊界的操作。
• 它仍可能出錯，尤其是在對抗性或異常上下文中。
• 它應當補充而非取代良好的沙箱設計、監控和 組織專屬策略。

有關研究依據和已釋出的評估結果，請參閱 Alignment Research 關於自動審查的文章。