當我們在討論 AI Coding Agent（如 Codex）時，最令人不安的往往不是 AI 寫錯程式碼，而是給予 AI 執行權限後的風險。如果 AI 具備自動執行指令、修改檔案或存取網路的能力，一旦發生錯誤或產生非預期行為，可能會直接毀掉開發者的開發環境甚至洩漏敏感資料。
為了讓 AI 能在 Windows 上安全地運行，OpenAI 開發了一套專屬的沙盒（Sandbox）架構。所謂沙盒，是指一種隔離執行環境，讓程式在其中運行時，無法對外部系統造成不可控的影響。
Windows 缺乏單一且完美的隔離機制來滿足 AI Agent 的需求，這讓 OpenAI 必須在安全性、可用性與開發者體驗之間做權衡。
現有方案的限制與挑戰
在設計之初，OpenAI 評估了 Windows 內建的 Windows Sandbox（Windows 沙盒）以及 MIC（Mandatory Integrity Control，強制完整性控制）。
Windows Sandbox 雖然提供了強大的虛擬機隔離，但它是一個完全獨立且拋棄式的環境。對於 Coding Agent 來說，這並不實用，因為 AI 需要直接存取開發者的工作目錄、編譯工具以及 Git 儲存庫才能完成任務。如果將 AI 關在完全隔離的虛擬機中，它將無法讀取原始碼，失去了自動化開發的意義。
而 MIC 雖然能控制程序的權限等級，但仍不足以提供 AI Agent 所需的精細控制。當時開發者面臨的兩難是：要麼每一步操作都由人工核准（極其低效），要麼給予 AI 完全的系統權限（極其危險）。
第一階段：非提升權限沙盒（Unelevated Sandbox）
OpenAI 最初嘗試的方案是利用 Windows 的權限管理機制來限制寫入權限。他們結合了 SID（Security Identifier，安全識別碼，用於唯一標識使用者或群組）與 ACL（Access Control List，存取控制清單，定義誰能對資源做什麼）。
他們引入了一個名為 sandbox-write 的合成安全識別碼。透過這個機制，AI 只能在被明確指定為可寫入的目錄（例如目前的工作區）中進行操作。而對於敏感路徑（例如 Git 的元數據目錄 .git），則透過 ACL 強制執行唯讀或禁止存取，防止 AI 意外損壞版本控制紀錄。
第二階段：提升權限沙盒（Elevated Sandbox）
為了進一步強化隔離，OpenAI 將架構升級為提升權限沙盒。這次的設計核心在於建立獨立的本地 Windows 帳戶，例如 CodexSandboxOffline 與 CodexSandboxOnline。
在這種模式下，AI 執行的所有指令都運行在這些受限帳戶的身分下，並搭配限制權限的 Token（權限令牌）。這樣做的好處是，即使 AI 試圖執行高權限操作，也會被作業系統本身的帳戶權限擋下來。此外，透過防火牆規則，OpenAI 能夠精確控制 AI 的網路存取範圍，確保 AI 不會將私有代碼意外傳送到外部伺服器。
實務上的影響與啟發
這套設計解決了 AI Agent 在 Windows 上的核心痛點：它不再將開發者的整個檔案系統視為遊樂場，而是將其限制在一個可控的邊界內。
對於工程師而言，這意味著你可以讓 AI 執行複雜的開發任務，而不需要像緊張的父母一樣時刻盯著螢幕，擔心它刪除系統檔案或竄改配置。
這也給了我們一個啟發：面對 AI Agent 這類新型工作負載，單一的安全性工具（如單純的防火牆或單純的權限設定）通常是不夠的。真正的解決方案往往需要組合多種作業系統底層原語（Primitives），將身分驗證、檔案存取控制與網路隔離有機地結合在一起，才能在不犧牲開發效率的前提下，實現真正的安全性。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。