摘要： OpenAI在2026年5月8日發表內部Codex部署說明，用沙箱、審批政策、受管網路、企業身分綁定與代理原生遙測界定代理活動範圍。這套做法讓低風險操作保持順暢，把超出邊界或危險動作交給審查，並用日誌還原提示、工具活動、審批與網路決策。文章描述的是OpenAI企業環境的內部框架，且假設組織已有身分與合規基礎，不能直接讀成所有Codex的預設行為。
程式庫審查、指令執行、開發工具操作——當這些工作逐漸交到 coding agent 手上，安全團隊該問的問題也跟著改變：焦點從「這個人做了什麼」，轉向「代理為何做出這個決定」。2026 年 5 月 8 日，OpenAI 發表一篇文章，對外說明自家內部如何部署 Codex；整套框架的重心不在處處設限，而在替代理劃出清楚的活動範圍，讓它在範圍內全力發揮，並留下可供稽核的紀錄。
對正打算把 AI 代理帶進工作流程的團隊來說，這份文件值得細讀：它揭示的控制思維，目的從來不是拖累開發速度，而是讓無風險的操作一路暢行，危險的操作自動剎車、進入審查。
沙箱與審批機制：範圍內行動自如，越線先請示
OpenAI 內部運行 Codex 時守著一條中心思想：代理在受控環境裡必須維持產能，日常的低風險操作不該有任何阻礙，風險一升高就得停下來接受審查。
沙箱劃出技術上的執行界線，決定 Codex 能寫入哪些路徑、可不可以連上網路，以及哪些目錄屬於保護區。審批政策則管另一件事：Codex 什麼時候該回頭徵詢使用者，典型情況是下一步動作超出沙箱涵蓋範圍。面對徵詢，使用者可以只點頭這一次，也可以讓同一工作階段裡的同類動作一併放行。
打斷次數要壓低，靠的是 Auto-review 模式。請求一旦越過沙箱邊界，Codex 便把打算執行的動作連同近期上下文，交給一個自動審批子代理判斷：低風險動作可以直接核可；使用者授權足夠時，高風險動作同樣放行。結果是例行任務不再反覆打擾使用者，真正危險的操作照樣會被攔下。
網路、身分與規則：一層疊一層的防線
對外連線這一塊，Codex 拿到的是受限而非開放式的網路存取。OpenAI 的受管網路政策只放行預期中的目的地，不想讓 Codex 接觸的網站一律擋下，碰上陌生網域則必須先取得審批。既定且常見的工作流程照樣跑得完，網路暴露面卻不會失控。
身分與憑證這一關同樣把得緊。CLI 與 MCP 的 OAuth 憑證統一收進安全的 OS 鑰匙圈；登入只能走 ChatGPT，帳號還綁定企業工作區。Codex 的每一次活動都會寫進 ChatGPT Compliance Logs Platform，日後稽核都有據可查。
規則則被拿來替 shell 指令分風險等級。開發日常會用到的無害指令，在沙箱外執行也不必審批；名列危險的特定指令，不是直接封鎖，就是必須送審。執行這些規則的管道有三：雲端受管設定、macOS 受管偏好設定，以及本地 requirements 檔案。使用者改不了規則，不過團隊或環境不同時，規則本身可以各自調整。
代理原生遙測：不只記錄「發生什麼」，還要還原「為什麼」
傳統安全日誌頂多告訴你發生什麼：哪個程序啟動了、哪個檔案遭到修改、哪次網路連線遭到嘗試。安全團隊真正想掌握的，卻是 Codex 當下為何這麼做，以及使用者心裡的意圖。
為此，Codex 提供 OpenTelemetry 日誌匯出，記錄範圍含使用者提示、工具審批決策、工具執行結果、MCP 伺服器使用情況，還有網路代理放行或封鎖的每一筆事件。這些紀錄可以彙整進 SIEM 或合規日誌系統保存。
OpenAI 內部讓一個 AI 安全分流代理搭配這些日誌運作。端點警報一指出 Codex 行為有異，這個代理就調出 Codex 日誌，逐一檢視原始請求、工具活動、審批決策和網路政策決定，再把分析結論交給安全團隊，判斷那究竟是預期中的行為、無傷大雅的失誤，還是該往上通報的事件。
同一套遙測在營運面也派得上用場：內部採用率的消長、哪些工具與 MCP 伺服器最受倚重、網路沙箱多常跳出封鎖或提示、哪裡的設定該修，都能從中看出端倪。
要導入的團隊可以從哪裡開始
從 OpenAI 的實戰經驗看下來，想安全部署 coding agent，沒有哪一套工具單獨夠用，得靠控制面、設定管理、沙箱與遙測一起補位。準備導入的團隊不妨從以下幾件事做起：
- 先替代理劃定清楚的執行邊界，並設法讓低風險動作一路暢通。
- 別把指令全部封死或全部放行，改用規則替風險分級。
- 日誌必須答得出「為什麼」，光記「做了什麼」並不夠。
另外要留意這套框架的前提：它預設組織早已具備一定程度的企業級身分與合規基礎。條件還沒到位的團隊，恐怕得先把基礎建設補齊，才輪得到代理上場。