推薦設定

適用於網路安全工作流程的安全控制取決於模型、模型可以執行的操作、模型可以存取的系統，以及所涉及資料的敏感程度。

對於大多數 Daybreak Blue 工作流程，組織現有的安全實踐（例如存取控制、憑據保護以及敏感操作審查）可能已經足夠。

Daybreak Red 工作流程、自主安全測試，以及涉及生產系統、敏感資料或外部工具的活動，可能需要更強的防護措施。以下建議主要面向這些風險較高的場景。

Trusted Access 管理獲核准的模型存取，但不會設定你的環境，也不會對獲核准的系統和操作強制實施限制。你的團隊必須設定適當的隔離、權限、審查、監控和人工監督控制。應假設模型、其工具及每個已連線系統都可能遭到入侵，然後設定環境，確保即使發生這種情況，它們仍無法存取未經授權的系統、洩露憑據、停用防護措施，或在工作結束後保持駐留。

隔離環境

在專用實驗室或沙箱中開展攻擊性安全工作。初始環境不應具備不受限制的網際網路存取權限，也不應能夠存取敏感的生產系統、企業網路、無關工作負載或主機管理介面。除非獲核准的工作明確要求並授權使用，否則應確保機密、憑據、持久存取權限和永續性系統變更無法觸及。

對於風險較高或防護措施有所減少的工作，每次嘗試都應使用全新且高度隔離的環境。分別隔離計算、儲存、網路和身份，並在工作結束後銷燬環境，而不是重置或重複使用。

開始風險較高的工作前，應測試檔案系統和網路邊界。測試範圍應包括每臺可存取的主機、每個已連線工具、受委派的智能體和下游服務。即使模型或審查者核准了某項操作，也應繼續隔離主機環境。

定義並強制實施獲核准的邊界

模型開始工作前，應記錄獲准用於此項工作的系統、工具、操作和時間限制。包括：

• 獲核准的目標系統、主機和環境。
• 排除的系統，包括生產系統和無關基礎設施。
• 獲核准的工具和已連線服務。
• 獲核准和禁止的操作。
• 獲核准的開始和結束時間，以及資料處理要求。
• 漏洞披露、補丁核准和維護者協調流程。
• 停止條件以及需要明確人工核准的操作。

將這些獲核准的邊界作為任務上下文提供給智能體。僅記錄這些邊界並不能強制實施它們：應採用獨立的檔案系統、網路、身份和工具控制，在可行情況下使未經授權的操作無法執行。

使用 Codex 權限設定檔建立最小權限邊界。任務不需要進行更改時，選擇 :read-only；工作需要編輯工作區時，則擴充套件 :workspace。例如：

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "cyber-lab"

[features]
network_proxy = true

[permissions.cyber-lab]
description = "Limit security testing to the approved lab and workspace."
extends = ":workspace"

[permissions.cyber-lab.filesystem]
glob_scan_max_depth = 3

[permissions.cyber-lab.filesystem.":workspace_roots"]
"**/.env*" = "deny"
"**/*.pem" = "deny"

[permissions.cyber-lab.network]
enabled = true
# Uncomment only for an approved host that resolves to a private address.
# allow_local_binding = true

[permissions.cyber-lab.network.domains]
"lab.example.com" = "allow"

network_proxy 功能會強制限定獲核准的域。如果沒有此功能， network.enabled = true 會允許直接存取網路，且實驗室允許列表 不會限制目標位置。Web 搜尋、應用、連接器、MCP 伺服器、 瀏覽器活動和 Codex 雲端分別使用不同的控制；應限制或關閉 獲核准工作流程不需要的每個入口。

將 lab.example.com 替換為獲核准的目標。限定範圍的檔案系統掃描旨在避免搜尋 Linux、WSL 和 Windows 上的整個工作區；如果敏感檔案位於更深層級，請增加深度或使用精確的拒絕路徑。不要將權限設定檔與舊版 sandbox_mode 設定結合使用；請遵循權限設定檔設定指南。

如果獲核准的實驗室主機解析為私有地址，即使該主機位於允許列表中，Codex 預設仍會阻止它。僅針對明確獲核准的私有網路工作設定 allow_local_binding = true，保持較窄的目標允許列表，並檢視本機和私有網路指南。你也可以將獲核准的確切私有 IP 地址加入允許列表。

預設阻止存取開放網際網路和生產網路。如果必須存取外部資源，請通過獨立強制實施的閘道器或代理進行路由，並採用嚴格的允許列表、請求檢查和日誌記錄。對於通過軟體包管理器、Webhook、URL 取得服務、重定向、雲 API 和已連線工具建立的間接連線，也應實施相同限制。在執行前載入依賴項，或使用管理員核准的依賴項。

保護憑據和敏感資料

不要在提示、儲存庫、環境變數、共享檔案系統和模型可存取的日誌中存放可重複使用的 API key、雲憑據、密碼和服務帳號令牌。需要身份驗證時，應使用獨立的代理程式或閘道器，提供僅限確切目標和獲准操作的短期憑據，且不向模型暴露該憑據。

僅提供獲核准任務所需的資料。移除不必要的敏感資訊，阻止存取雲後設資料和憑據端點，並將模型生成的檔案視為不可信內容。

在網路安全工作流程中，應避免使用 :danger-full-access 和 --yolo。Full Access 會移除自動審查賴以實施的沙箱邊界。託管組織可以排除 :danger-full-access 和 --yolo、限制允許使用的核准策略，並通過企業託管設定要求進行自動審查。

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

防護規則可為受控的網路安全工作流程新增基於策略的審查。它們無法取代環境隔離、最小權限、明確定義的邊界、監控或人工監督。

審查 Codex 的敏感操作

自動審查會在擬議操作執行前，將符合條件的沙箱邊界核准請求轉交給獨立的審查者。審查者會考慮擬議操作、限定範圍的任務上下文和適用策略，然後允許或拒絕請求。組織可以根據獲核准的目標、禁止的操作以及必須人工審查的條件，自定義該策略。

對於影響生產環境、外部系統、敏感資料、權限提升、持久存取或不可逆更改的操作，應要求明確的人工核准。將網站、儲存庫、文件和工具輸出中嵌入的指令視為不可信內容；這些指令無法擴大授權範圍或覆蓋存取控制。

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

要執行自動審查，請確保以下三項控制均已啟用：

1. 使用互動式核准策略，例如 approval_policy = "on-request"。
2. 設定 approvals_reviewer = "auto_review"。
3. 保留可強制實施的沙箱或權限設定檔邊界。

對網路允許列表中目標的請求會保持在網路邊界內，不會自動觸發自動審查。即使目標位於允許列表中，如需審查敏感命令，請在 ~/.codex/rules/ 下建立明確的命令規則：

prefix_rule(
    pattern = ["curl"],
    decision = "prompt",
    justification = "Review requests to the approved cybersecurity target.",
)

新增規則後，重啟 Codex。使用 approvals_reviewer = "auto_review" 時，匹配的命令會在執行前轉交給審查者。為每條敏感命令新增對應的提示規則，或對單獨的 MCP 工具使用 approval_mode = "prompt"。需要由人員做出決定的操作仍須獲得明確的人工核准。

自動審查不會檢查沙箱內已獲准執行的常規操作。使用 approval_policy = "never" 或 Full Access 時，敏感操作可能不會產生可審查的核准請求。自動審查可能出錯，且無法取代隔離、明確定義的邊界、監控或明確的人工監督。

有關限定範圍的策略和組織範圍內的強制實施，請參閱設定獲授權的網路安全工作流程。

獨立監控並採用故障關閉機制

記錄模型請求、工具呼叫、網路活動、憑據使用情況以及與安全相關的更改。將日誌和監控系統置於模型控制的環境之外。針對未經授權的目標、意外網路請求、憑據暴露、策略更改、日誌缺失以及繞過防護措施的嘗試發出警報。

確保策略實施機制、憑據代理程式、審查系統和緊急關閉控制項獨立於智能體。如果關鍵控制或監控系統發生故障，應停止工作流程。

為自定義智能體工作流程新增防護規則

如果使用 Responses API、Agents SDK 或其他執行框架進行建置，請在工具執行邊界新增審查。執行前，應根據獲核准的系統、操作和時間限制檢查擬議的敏感操作；將含糊或高風險的操作轉交給人員；強制實施獨立的檔案系統和網路限制；保留審計日誌；如果審查者或策略不可用，則採用故障關閉機制。

Codex 自動審查不會自動保護自定義工具或外部執行框架。請參考 Agents SDK 模式的防護規則與人工審查，並將開源審查者策略作為參考。

Codex 產品端的沙箱和審查獨立於 API 網路安全檢查。API 防護措施可能會傳回 cyber_policy 錯誤，而按使用者設定的 safety_identifier 值有助於限制防護操作的影響。

清理並驗證結果

工作結束後，撤銷臨時憑據、終止後臺程序、移除持久存取權限，並銷燬風險較高的環境。驗證是否仍存在回撥、暴露的工件、共享狀態或跨執行存取，並隔離不同的使用者、會話和評估。

在根據發現採取行動前進行驗證，遵循協同披露實踐，並確保由人員對修復和更改負責。

開始之前

確認獲核准的系統和操作、適當的模型、隔離環境、最小權限、受限的網路存取、受保護的憑據、操作審查、獨立監控、緊急停止機制和清理計劃。模型防護措施、隔離、限定範圍的權限、操作審查、監控和人工監督相輔相成；不應將其中任何一項作為唯一的控制措施。