當 coding agent 開始自主審查程式庫、執行指令、操作開發工具，安全團隊面對的不再只是「人做了什麼」，而是「代理為什麼這樣做」。OpenAI 在 2026 年 5 月 8 日發布的文章中，公開了他們內部部署 Codex 的安全框架，重點不是禁止代理行動，而是讓它在明確邊界內高效工作，同時保留可稽核的軌跡。
這套做法對任何準備導入 AI 代理的團隊都有參考價值：控制不是為了拖慢開發，而是為了讓低風險動作順暢、高風險動作停下來審查。
沙箱與審批：邊界內自由，邊界外暫停
OpenAI 部署 Codex 的核心原則是：在受控環境內保持生產力，日常低風險動作零摩擦，高風險動作必須停下審查。
沙箱定義了技術執行邊界，包括 Codex 可以寫入哪些路徑、能否存取網路、哪些目錄受到保護。審批政策則決定何時 Codex 必須詢問使用者，例如當它需要執行超出沙箱範圍的動作時。使用者可以選擇單次批准，或是在該工作階段內批准同類型動作。
為了減少打斷，OpenAI 使用了 Auto-review 模式：當請求跨越沙箱邊界時，Codex 會將計畫動作與近期上下文送給自動審批子代理，後者可以自動批准低風險動作，或在足夠授權下批准高風險動作。這樣一來，例行工作不會頻繁打斷使用者，但真正有風險的操作仍會停下來。
網路、身分與規則：多層防護
OpenAI 沒有給 Codex 開放式的對外網路存取。他們的受管網路政策允許預期目的地、封鎖不希望 Codex 觸及的站點，並要求對陌生網域進行審批。這讓 Codex 能完成常見的已知工作流程，同時避免過大的網路暴露。
身分與憑證管理同樣嚴格：CLI 與 MCP 的 OAuth 憑證存放在安全 OS 鑰匙圈，登入強制透過 ChatGPT，並綁定到企業工作區。所有 Codex 活動都會進入 ChatGPT Compliance Logs Platform，方便稽核。
此外，OpenAI 用規則來區分 shell 指令的風險等級。常見的無害指令在沙箱外不需審批即可執行，特定危險指令則會被封鎖或要求審批。這些規則透過雲端受管設定、macOS 受管偏好設定與本地 requirements 檔案強制執行，使用者無法覆寫，但可以依團隊或環境調整。
代理原生遙測：從「發生什麼」到「為什麼」
傳統安全日誌只能回答「發生什麼」：某個程序啟動、某個檔案被修改、某次網路連線被嘗試。但安全團隊更需要知道「為什麼 Codex 這樣做」，以及使用者的意圖。
Codex 支援 OpenTelemetry 日誌匯出，涵蓋使用者提示、工具審批決策、工具執行結果、MCP 伺服器使用情況，以及網路代理的允許或封鎖事件。這些日誌可以集中到 SIEM 或合規日誌系統。
OpenAI 內部還用這些日誌搭配 AI 安全分流代理：當端點警報顯示 Codex 有異常行為，安全代理會查閱 Codex 日誌，檢查原始請求、工具活動、審批決策與網路政策決定，然後將分析結果交給安全團隊判斷是預期行為、無害錯誤，還是需要升級的事件。
同樣的遙測也用於營運：了解內部採用變化、哪些工具與 MCP 伺服器被使用、網路沙箱多常觸發封鎖或提示，以及哪些地方需要調整。
給導入團隊的務實建議
OpenAI 的經驗顯示，安全部署 coding agent 不是單一工具能解決的事，而是控制面、設定管理、沙箱與遙測的組合。對準備導入的團隊，可以先從這幾點著手：
- 明確畫出代理的執行邊界，並讓低風險動作盡量順暢。
- 用規則區分指令風險，而不是一律封鎖或一律放行。
- 確保日誌能回答「為什麼」，而不只是「做了什麼」。
這套框架的侷限在於，它假設組織已有一定的企業級身分與合規基礎。若團隊尚未具備這些條件，可能需要先補齊基礎建設，再讓代理上線。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。