以 OpenAI 內部使用 Codex 的治理實踐為例，理解受管配置、Sandbox 與審批、命令規則、網絡與身份控制，以及 Agent 日誌怎樣支持安全調查和策略改進。
上一篇解釋了操作系統怎樣約束工具進程。把 Agent 放到團隊開發流程裏，還需要回答另一組問題：不同開發者使用的權限是否一致？誰能批准例外？如果某次執行觸發告警，安全團隊能不能還原當時發生了什麼？
OpenAI 的《Running Codex safely at OpenAI》提供了一個組織級案例。本文沿着一次任務的完整過程整理：先確定統一運行策略，再檢查具體動作，隨後管理外部連接和身份，最後用執行記錄支持調查與策略調整。
仍以一個假設任務貫穿説明：開發者請 Agent 修復 CSV 解析錯誤、補測試並準備變更。正常工作包括讀取項目、修改源碼和運行測試；上傳原始數據到外部網站、修改項目外配置，則不能因為“可能有助於排查”就自動獲得許可。下面的情節用於説明治理關係，不代表已經在當前博客或電腦部署了這些控制。
一、組織怎樣統一 Agent 的運行策略h2
1. Managed Configuration：強制要求與默認設置h3
個人設置解決“我希望怎樣運行”，組織策略解決“在這裏運行至少必須滿足什麼條件”。兩者最重要的區別，是用户能不能改變它。
官方文檔將 Requirements 與 Configuration Defaults 分開：前者是管理員強制執行的要求，後者提供初始設置，允許用户在支持的範圍內調整。與強制要求衝突的本地配置，不能僅因來自用户文件或啓動參數就覆蓋它。來源：Managed configuration
例如，團隊可以默認讓開發任務在項目內寫入，同時強制限制可選的權限範圍。默認值讓開發者啓動後就能工作；強制要求則防止某個人為了少點幾次批准，直接把組織禁止的運行方式打開。
這也説明，統一分發配置，不等於統一執行約束。如果分發的是可修改的默認值，用户仍然能改；如果確實需要不可覆蓋的限制，就要把它放進對應的強制策略，而不是隻寫在操作手冊裏。
2. Policy Scope：客户端、執行環境與生效範圍h3
一條策略還要説明它約束誰、在哪裏生效。桌面客户端、CLI、IDE 擴展可能都能發起任務，但本機進程與雲端執行環境不是同一個落點。
OpenAI 的案例通過雲端管理、設備管理和本地要求文件組合下發配置。理解這裏的治理方式，關鍵不是記住所有配置來源的優先級，而是區分：誰管理策略，哪個客户端讀取策略，哪個執行環境實際落實限制。
對於 CSV 任務，可以先在一個受管環境裏檢查兩類行為：正常修改項目文件能否完成；嘗試寫入禁止位置時，是否確實被拒絕。同樣的檢查還要覆蓋組織實際使用的其他執行路徑，不能把本機驗證結果直接當作雲端也已受控。
這些檢查關注的是策略的有效範圍，不是讓各團隊自行繞開基線。允許差異化的部分可以按環境配置，但真正生效的要求仍需核對客户端版本、執行位置和管理層配置。
二、一次動作怎樣獲得執行許可h2
3. Sandbox 與 Approval：執行邊界和例外審查h3
Sandbox 描述當前執行環境允許做什麼；Approval Policy 決定什麼動作需要額外審查。兩者不是“嚴格模式”和“寬鬆模式”的二選一。
在 CSV 任務中，修改項目源碼可以在既有邊界內完成；寫入項目外配置則可能觸發權限請求。此時應該審查的是具體目標、動作和必要性，而不是給整個任務補一句“都可以”。
| 檢查層次 | 對 CSV 任務提出的問題 |
|---|---|
| 組織要求 | 當前環境允許申請這種權限嗎？ |
| 執行邊界 | 當前進程能否直接訪問目標資源？ |
| 審批判斷 | 這次額外訪問是否必要，是否得到相應授權？ |
| 實際執行 | 最終獲得的權限是否足夠完成獲准動作？ |
批准不是修改組織禁令的通用開關，也不保證操作系統或目標服務必然放行。它只在組織允許的例外機制內，對相應請求作出決定。
原文還介紹了 Auto-review：把待執行動作和近期上下文交給自動審查者，減少常規請求對用户的打斷。這裏需要區分的是，自動化的是部分審查工作，不是取消執行邊界。審查者仍然可能判斷錯誤，因此它不能替代 Sandbox 或組織要求。
4. Command Rules：命令匹配與放行範圍h3
除了結合上下文判斷，還可以把經常出現的命令模式寫成規則。Codex 的 Rules 用於控制命令在 Sandbox 外的執行，支持 allow、prompt、forbidden 等決定；多個規則匹配時採用更嚴格的結果。來源：Rules
這與提示詞裏的“謹慎操作”不同：規則匹配的是實際命令參數，而不是模型對命令的解釋。原文用只讀 PR 查詢説明可以預先放行的常見操作，但不能據此把整個 gh 命令入口都視為只讀。
以我們的任務為例，“查看 PR”與“合併 PR”會產生不同影響；“運行某個已知測試”與“運行任意項目腳本”，也不是同一個範圍。規則前綴越寬，覆蓋的行為就越多，不能只憑程序名字看起來熟悉就放行。
複合 Shell 命令還可能包含多個動作。官方規則機制會在可以安全解析時分別檢查子命令，不能安全拆分時則檢查完整調用。一個獲准命令出現在開頭，不代表後面附帶的動作也獲准。 因此，驗證規則時既要檢查應當匹配的樣例，也要檢查不應匹配的樣例。
三、Agent 的外部連接怎樣管理h2
5. Network Policy：連接目標與訪問通道h3
文件權限回答“能改哪裏”，網絡策略還要回答“能把信息送到哪裏、能從哪裏取回內容”。項目文件沒有被破壞，不代表數據沒有被上傳。
對於 CSV 修復，訪問批准的依賴服務與上傳原始數據，是不同的動作。即使二者都通過 HTTP 完成，也不能共享一個模糊的“允許聯網”判斷。
OpenAI 的內部案例對目的地進行區分：已知目標按策略處理，禁止目標阻斷，陌生目標需要額外審批。它還將 Web Search 限制為緩存模式。這裏包含兩類不同控制：命令進程的網絡訪問與搜索工具取得網頁內容的方式，後者不能替代前者。
當前官方文檔也強調：域名規則必須由對應的網絡執行機制落實，寫下允許列表本身不等於已經啓動約束；命令網絡策略也不自動覆蓋所有 Web Search、App 或 MCP 通道。若允許完整的 Sandbox 升級，還要檢查升級後的網絡路徑，不能只驗證普通執行時的代理限制。來源：Agent approvals & security
因此，在組織里檢查“這份數據能否出去”，需要先找到實際通道：Shell 啓動的程序、搜索工具，還是外部連接器。然後確認那個通道的策略，而不是看到某處配置了域名列表就結束。
域名獲准也只説明可以連接該目標，不證明發送的每份數據都合適。把原始 CSV 上傳到一個常用開發平台，仍然需要判斷內容和用途；從可信站點取回的頁面，也不能因此獲得指揮 Agent 的權限。
6. Identity 與 Credentials：使用身份和憑證保管h3
聯網目標確定後，還要知道以誰的身份訪問。用户的 Codex 登錄、工具進程的本機身份、外部服務的 OAuth 授權，是不同層次。
原文介紹了將 CLI 和 MCP OAuth 憑證保存在 OS Keyring，並把 Codex 登錄綁定到指定企業 Workspace 的做法。前者管理憑證的存儲位置，後者讓使用歸屬到相應組織控制下；二者不能互相替代。
官方認證文檔也區分登錄方式、Workspace 權限和憑證存儲。將憑證放進系統憑證庫，並不等於改變憑證本身在目標服務擁有的權限。來源：Authentication
例如，開發者使用企業 Workspace 登錄 Codex，不代表某個 GitHub 連接只擁有讀取權限；工具以受限本機用户運行，也不代表它持有的遠程憑證只能訪問測試環境。本機執行身份與遠程服務授權，需要分別檢查。
從這個區別出發，治理時就能把問題問具體：任務需要哪個賬號、哪些資源和哪些操作？憑證由誰保管，工具是否真的需要接觸它？不必把憑證正文放進 Prompt、項目文件或調查記錄，才能説明某個調用使用了什麼授權。
四、運行記錄怎樣支持審計與安全響應h2
7. Agent-native Telemetry：關聯任務、審批與執行結果h3
傳統終端記錄可以告訴安全團隊：哪個進程啓動了、哪個文件發生變化、是否出現異常連接。Agent 記錄補充的則是任務背景：用户要求什麼、工具請求是什麼、批准從哪裏來，以及調用返回了什麼結果。
兩者要關聯起來看。僅有進程告警，可能不知道動作對應哪個任務；僅有 Agent 的完成總結，又可能忽略實際執行失敗或未獲準的嘗試。
原文介紹了通過 OpenTelemetry 導出相關事件，並與集中安全日誌和合規記錄配合使用。以一個假設的上傳告警為例，調查需要串起下面這些信息，而不是隻看“任務最終成功了”：
| 記錄 | 幫助回答的問題 |
|---|---|
| 用户請求 | 修復 CSV 是否包含外傳數據的授權？ |
| 工具請求 | 準備執行什麼程序，目標是什麼？ |
| 審批決定 | 請求獲准還是被拒，決定來自哪裏？ |
| 網絡決定 | 哪個目的地被允許或阻斷？ |
| 工具與終端結果 | 請求停在檢查階段，還是發生了實際傳輸？ |
這是調查所需信息的示意，不是一套固定事件 Schema，也不意味着每種日誌默認保存全部內容。官方 OTel 文檔中，用户 Prompt 正文默認不記錄，工具結果也可能只是片段。缺失記錄時，不能把“沒有看到”直接寫成“沒有發生”。來源：Observability and telemetry
因此，日誌策略本身也需要治理：記錄哪些字段、誰能查、保留多久，以及如何減少敏感數據暴露。審計有用的前提是能關聯並核對關鍵事件，不是把全部對話和文件內容無限保存。
8. Security Triage：告警關聯與人工判斷h3
Security Triage 是對告警進行初步調查和分流：哪些屬於預期工作，哪些是誤操作，哪些需要進一步響應。它不是看到 Agent 參與就自動認定攻擊，也不是看到用户説過“修復問題”就為所有動作免責。
在 CSV 場景中，同一個外聯告警可能有不同解釋：獲准獲取依賴、誤把數據發送到錯誤目標，或受到外部內容誘導而嘗試上傳。要區分它們，需要核對請求、目標、授權和實際結果。
OpenAI 的案例使用安全分流 Agent 整理相關記錄，再由安全團隊審閲分析。自動化適合幫助檢索和關聯證據，但分析結論仍需要與真實執行記錄對照，不能把模型生成的解釋當作事件本身。
假如日誌顯示上傳被網絡策略阻斷，這説明該次嘗試沒有沿這條路徑完成，不説明嘗試本身符合授權，也不能證明其他路徑沒有傳輸。調查要同時回答“動作是否合適”和“實際造成了什麼影響”。
9. Rollout Feedback：從執行記錄調整治理策略h3
同一批記錄也可以服務於日常改進。某個目的地頻繁觸發審批，可能是正常開發依賴沒有配置完整；也可能是工具請求超出了任務需要。兩者都表現為“審批很多”，但處理方式不同。
前者適合核實用途後補充明確、有限的規則；後者需要收緊工具行為、修正任務指導，或繼續保留阻斷。不能為了降低打斷次數，一律擴大允許範圍。
同樣，攔截次數少也不能單獨證明策略有效：可能任務本來沒有碰到邊界，也可能相關通道沒有被覆蓋。更有價值的驗證，是把正常任務、明確禁止的動作和需要審批的例外一起檢查，確認三者確實進入預期處理路徑。
從這個角度看，治理形成的是一條反饋鏈：配置規定邊界，執行落實邊界，記錄解釋執行，再根據證據調整配置。 日誌不是安全控制的替代品，卻能幫助發現控制沒有覆蓋到的位置，以及真正妨礙正常工作的地方。
幾個關鍵問題，串起權限、審計與響應h2
給每個人發同一份配置文件，就算統一治理了嗎？
不一定。先看它是可覆蓋的默認值，還是強制要求，再看實際客户端與執行環境是否讀取並落實。統一文件內容解決分發問題；禁止行為確實被拒絕，才説明相應約束生效。
動作獲得批准，為什麼還可能不能執行？
審批只能在允許的機制中處理具體請求，不能自動覆蓋組織禁令、操作系統權限或目標服務授權。如果目標本來不可訪問，或者組織禁止申請該權限，用户點一次批准也不構成無限權限。
常用命令為什麼不能直接按程序名放行？
同一個程序可以讀取、修改或刪除資源。規則需要覆蓋實際參數與作用範圍，並處理複合命令；放行 PR 查詢，不等於放行合併或倉庫刪除。規則的質量取決於覆蓋了什麼，而不是前綴有多短。
已經限制網絡，為什麼還要檢查 MCP 和其他連接器？
限制的是具體執行通道，不是抽象的“Agent 整體”。命令代理、託管搜索和外部連接器可能分別受控。數據通過哪個通道出去，就要核對那個通道的策略；普通命令與獲准升級後的命令也可能不同。
憑證保存在 Keyring，是否就解決了身份安全？
它解決憑證保管的一部分問題，不決定遠程賬號能訪問哪些資源。組織歸屬、本機進程身份、外部服務授權仍需分別確認。安全存儲一個權限過大的憑證，不會讓它自動變成最小權限憑證。
Agent 日誌能證明它當時為什麼這樣想嗎？
日誌可以提供請求、動作、審批和結果，用來分析行為與任務的關係，但不是模型內部意圖的完整證明。還要考慮記錄缺失、脱敏和結果截斷，並與終端、網絡或服務端記錄核對。模型生成的事後解釋不能替代證據。
一次上傳被阻斷，調查是不是就結束了？
沒有沿已阻斷路徑完成上傳，只回答了這條路徑的結果。還要查動作為何出現、是否有其他路徑、是否需要響應，以及策略是否確實覆蓋同類請求。判斷影響與判斷授權，是調查中的兩個不同問題。