當 AI 系統從單純的對話機器人進化為能夠自主執行任務的 Coding Agent（編碼代理人）時，安全風險會大幅增加。以往的 AI 只能提供建議，但現在的 Codex 可以直接讀取程式碼庫、執行終端機指令以及操作開發工具。對於企業安全團隊來說，這意味著 AI 擁有了相當於一名工程師的權限，如果缺乏管控，可能會導致敏感資料外洩或系統被誤刪。
為了在提升開發效率與維持安全性之間取得平衡，OpenAI 在內部部署 Codex 時採取了一套完整的治理框架，核心邏輯是將環境隔離、風險分級與行為紀錄結合在一起。
建立技術邊界與風險分級
安全部署的第一步是定義邊界。OpenAI 使用 Sandbox（沙箱，一種將程式執行環境與主系統隔離的技術，確保程式碼在受限範圍內運行，不會影響到外部系統）來限制 Codex 的操作範圍。
沙箱定義了 Codex 可以寫入哪些路徑、是否能訪問網路以及哪些系統路徑是絕對禁區。配合沙箱的是 Approval Policy（審核策略），這決定了 AI 在執行某個動作前是否需要經過人類同意。
為了避免頻繁的審核請求打斷工程師的工作流程，OpenAI 引入了 Auto-review（自動審核）模式。系統會由一個專門的子代理人分析當前的上下文與計畫執行的動作，如果判定為低風險的日常操作，則會自動核准；而高風險或可能產生不可逆後果的操作，則必須強制停止並等待人工審核。
精細化的網路與權限管理
AI 代理人如果擁有不受限的網路訪問權限，可能會將內部機密傳送到外部伺服器。因此，OpenAI 並不給予 Codex 開放式的出站訪問權限，而是採用 Managed Network Policy（管理式網路策略）。
這種策略將網路目的地分為三類：預期內的已知目的地（直接允許）、明確禁止的危險域名（直接封鎖），以及不熟悉的域名（要求人工審核）。此外，透過設定 Web Search 模式為 Cached（快取模式），可以確保 AI 獲取的資訊經過篩選，而非直接與不可控的外部網站即時互動。
在身分驗證方面，Codex 的憑證（如 CLI 或 MCP 協議的 OAuth 令牌）被儲存在作業系統的安全金鑰庫（Keyring）中，且強制要求透過 ChatGPT 企業版工作區進行登入。這樣能確保所有 AI 的操作都能追溯到特定的使用者與組織權限，並記錄在合規日誌平台中。
指令級別的規則控管
並非所有的 Shell 指令都具有相同的風險。為了讓開發者能快速地進行除錯，OpenAI 設定了指令規則（Rules），將常見的良性指令設為白名單。
例如，使用 GitHub CLI 檢視 Pull Request（gh pr view）或使用 Kubernetes 指令查看日誌（kubectl logs）這類唯讀操作，即使在沙箱之外執行，也可以被允許。但若涉及修改設定或刪除資源的指令，則會觸發審核或直接被攔截。
從傳統日誌到代理人感知遙測
對於安全團隊來說，傳統的系統日誌（例如：某個行程啟動了、某個檔案被修改了）只能告訴我們發生了什麼（What），但無法解釋為什麼發生（Why）。在 AI 驅動的環境中，理解 AI 的意圖（Intent）至關重要。
為了補足這一點，Codex 支援 OpenTelemetry（一套標準化的可觀測性框架，用於收集追蹤、指標與日誌），提供 Agent-native Telemetry（代理人原生遙測）。這類日誌會記錄使用者輸入的提示詞、工具核准的決策過程、執行結果以及網路代理的攔截事件。
當端點安全工具偵測到異常行為時，安全團隊可以使用 AI 驅動的 Triage Agent（分診代理人）來分析這些遙測日誌。透過回溯 AI 的思考路徑與操作邏輯，安全人員可以快速區分這是一個良性的操作失誤，還是真正的安全威脅。
總結與實務啟發
將 AI 代理人引入生產環境，不能僅依賴 AI 自身的對齊（Alignment），而必須在基礎設施層面建立硬性的控制面。透過沙箱隔離、指令白名單、精細的網路策略以及具備意圖分析的遙測系統，企業才能在賦予 AI 自主權的同時，依然保有對系統的絕對掌控力。
來源：openai.com - Running Codex safely at OpenAI
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。