微軟 MXC 正式 GA：用 OS 層政策容器關住 AI agent
Windows Developer Blog · 2026-10-07
讓 AI agent 跑在 sandbox 裡，過去多半靠各家工具自己在 harness 裡檢查路徑、攔指令；微軟的 Microsoft Execution Containers（MXC）改成由作業系統強制執行一份獨立於 agent 的政策。政策放在 workload 控制範圍之外，agent 沒辦法替自己加權限。
微軟在 2026-10-07 的部落格宣布 MXC 已 GA，程式碼在 microsoft/mxc，可用於 Windows、macOS 與 Linux。部落格與 repo 都沒有給版本號，GitHub 的 Releases 頁面目前是空的。
原本的問題
agent 會執行模型產生的 shell 指令、外掛、本機 MCP server 和 language server。這些程式碼不可信，但多數工具只能各自實作限制：Windows 用 AppContainer、macOS 用 Seatbelt、Linux 用 Bubblewrap，三套機制語法完全不同。
結果是每個 agent 產品都要自己維護跨平台的隔離層，企業 IT 也沒有統一的地方去收緊設定。MXC 的做法是只寫一份 JSON 設定與 SDK 呼叫，再由它對應到各平台的後端。
核心改動
MXC 把政策拆成五個區塊：容器類型、行程（指令、參數、工作目錄、環境變數）、檔案系統（可寫、唯讀、封鎖的路徑）、網路（含對 host 服務的 loopback）、使用者介面。組織可以透過 Microsoft Intune 之類的管理政策再加限制，不必由 agent 開發者寫進程式。
後端有四種：
| 後端 | 平台 | 機制 |
|---|---|---|
| Process container | Windows 11、macOS、Linux | AppContainer、Seatbelt、Bubblewrap |
| Session container | 僅 Windows 11 | 獨立的 Windows 帳號與 session，隔離桌面、剪貼簿、UI 與輸入 |
| WSL container（WSLc） | 僅 Windows 11 | 透過 WSL 跑 Linux 工具鏈 |
| MicroVM | Windows 11 與 Linux（實驗性） | 硬體強制的虛擬化邊界 |
SDK 支援 Rust、.NET 與 Node。repo README 的 Node 範例如下，預設拒絕對外連線並設定 30 秒逾時：
import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';
const request: ContainerRequest = {
command: 'node -e "console.log(\'hello from container\')"',
network: { egress: { default: 'deny' } },
timeoutMs: 30_000,
};
const child = await spawn(request);三種運作模式
政策很難一次寫對，所以 MXC 提供三種模式：
- Enforcement：未授權的存取一律封鎖，不產生報告，給正式環境用。
- Learning：封鎖並記錄，用來找出哪些存取被擋、確認是否真的是最小權限。
- Permissive：放行並記錄，只觀察、不強制；仍不會繞過 OS 或組織層級的限制。
活動報告是 JSON 檔，但部落格說明目前只有 Windows 的 process container 能產生。要靠 Learning 模式收斂政策的團隊，在 macOS 與 Linux 上暫時拿不到這份資料。
影響範圍
自家做 coding agent 或 agent 平台的團隊，現在有一個可以取代自製隔離層的選項。GitHub Copilot 已採用：依官方說明，Windows 用 ProcessContainer 後端的 BaseContainer 層，macOS 用 Seatbelt，Linux 用 bubblewrap，shell 指令、本機 MCP server 與 language server 預設都在邊界內執行。
但有兩個邊界要注意：Copilot 的內建檔案工具跑在 Copilot 自己的行程內，只是由 harness 依政策檢查，不是 OS 強制的子行程隔離；遠端 MCP server 在本機 sandbox 之外，只做連線政策檢查。評估時要分清楚哪些路徑真的被 OS 擋住。
部落格也提醒各後端的安全性質不同，要自行評估是否合用。MicroVM 在 Linux 仍是實驗性，不適合直接當正式環境的唯一防線。
Intune 對 Windows 11 process container 的管理、Microsoft Entra 區分 agent 與使用者活動、Microsoft Agent 365 擴展到本機 agent，這幾項部落格都列為尚未提供。用 Claude Code 的團隊另需留意，Anthropic 在部落格中被列為「已宣布」而非「已支援」的整合對象。部落格未說明 MXC 與其他容器技術的效能差異，也沒有公布任何基準數字。
NVIDIA 已把 OpenShell 整合進 MXC，加入檔案與推論服務的政策控制、進階網路控制、憑證管理與 OCSF 稽核。
原始來源：Windows Developer Blog、microsoft/mxc、GitHub Copilot 與 MXC