微軟在近期舉辦的 BUILD 科技大會上，正式對外公開了名為 「Microsoft eXecution Containers（簡稱 MXC）」 的全新開源專案，並於 GitHub 放出大眾預覽版本。這項技術解決當前自主 AI 代理人（AI Agents）在執行自動化任務時所面臨的核心安全問題。隨著 AI 代理人開始深入企業與個人的自動化工作流程，它們經常被賦予自動生成程式碼、執行腳本、操作本機檔案以及呼叫第三方工具的能力。然而，這也帶來了惡意輸入劫持（Prompt Injection）以及惡意程式碼執行等資訊安全風險。
MXC 專案的核心定位是一個原則導向（Policy-driven）、多層次隔離的沙盒執行系統。它允許開發者透過統一的 JSON 設定檔結構與 TypeScript SDK，在 Windows、Linux 以及 macOS 等多種作業系統上，輕鬆為未受信任的程式碼（例如 AI 模型的輸出內容、外部插件或工具）建立安全的邊界。微軟官方說明指出，這項技術能確保 AI 代理人雖然能幫使用者完成實用的工作，卻不會被授予超出當前使用者權限範圍的系統存取能力。
目前，許多指標性的 AI 應用與硬體大廠都已經開始導入這項技術。例如 GitHub Copilot CLI 已經整合了 MXC 的處理程序隔離機制，藉此限制動態生成的指令碼對系統所能造成的影響。
同時，晶片大廠輝達（NVIDIA）也宣布與微軟深度合作，將其 OpenShell 執行時期環境建立在 MXC 之上，為開發者提供更易於整合的自主代理人防護方案，內容涵蓋原則管理、推論路由以及個人隱私資料的去識別化遮罩。
儘管微軟 AI 安全帶來了創新的基礎建設，但專案團隊也在 GitHub 的說明文件中提出誠懇的提醒。目前 MXC 還處於早期大眾預覽階段，現階段所產生的防護原則在部分平台（例如 Windows 上的某些網路限制或路徑拒絕清單）可能仍不夠嚴密。因此，團隊強調目前的設定檔不應直接視為牢不可破的安全邊界，並熱烈歡迎資安研究社群共同參與開發，協助這套框架走向成熟。
微軟 MXC SDK 實戰教學：動態建立不受信任程式碼的隔離沙盒
在開發 AI 工具或自動化代理人時，如何安全地執行 AI 隨機生成的 Python 腳本或 Shell 指令，是每位工程師都必須面對的工程問題。微軟開源的 MXC 提供了一套 TypeScript SDK，讓開發者不需要深入底層繁瑣的作業系統虛擬化細節，就能用簡潔的程式碼動態建構出安全的隔離防護罩。CyberQ 進行實作與測試，這套雖然是早期版本，但已經是堪用了。
在開始撰寫程式碼之前，開發者必須先完成本機的建置準備。由於 MXC 的核心底層是由 Rust 語言所撰寫的整合核心，因此在下載專案後，需要透過建置腳本將其編譯為適用於目前系統平台的原生二進位檔案。編譯完成後，該執行檔會自動複製到 SDK 的指定二進位目錄中，接著即可在專案中透過套件管理工具安裝官方提供的 @microsoft/mxc-sdk 套件。
微軟的 MXC SDK 提供了數種建立沙盒的方式，包含官方最推薦的設定檔導向模式、便利的同步產生模式以及 Promise 風格的非同步產生模式。在預設狀態下，MXC 採取「預設拒絕」的嚴格安全準則，即使是 Node.js 目前的工作目錄，在沙盒內部也不會自動獲得檔案讀寫權限，開發者必須顯式地賦予每項資源權限。
若要限制檔案系統的存取，開發者可以撰寫一組 JSON 設定原則。例如，當您希望 AI 只能在特定的暫存資料夾中進行讀寫，同時必須嚴格禁止存取系統核心目錄時，可以在設定檔的 filesystem 區塊中，將允許的路徑加入到 readwritePaths 清單中，並將敏感路徑加入 deniedPaths 拒絕清單。如此一來，沙盒內執行的未授權程式碼便無法對外部關鍵資料進行篡改或竊取。
在網路限制方面，MXC 同樣展現了強大的原則控制能力。假設我們開發的 AI 代理人需要呼叫特定的外部 API 進行資料比對，但不希望它將機密資料外洩到未知的伺服器，可以將網路原則的 defaultPolicy 設定為拒絕（block），並在 allowedHosts 中精準列出允許連線的主機域名。在背後，Windows 系統會透過內建的防火牆與作業系統核心機制來實施這些邊界限制，在 Linux 下則會切換至核心過濾機制，確保隔離原則在不同環境下都能被切實執行。
隨著 AI 代理人的複雜度提升，微軟更建議採取「多組狹隘原則」的最佳化設計。不要嘗試用一個寬鬆的巨大沙盒去包攬所有任務，而是應該針對 AI 執行的每一個任務步驟，動態配發一個專屬、權限極小化的短暫沙盒，並在任務結束時自動清除原則，這樣會比較安全噢。
