微軟 Windows 開發者網誌宣布，Microsoft Execution Containers（MXC）已正式全面可用，為 AI 代理與動態產生工作負載提供政策驅動的作業系統級隔離。開發者與 IT 可事先界定代理可存取的檔案與網絡目的地，由容器在運行時強制執行，代理本身無法自行擴大權限。來源真實性已驗證（微軟官方網誌二零二六年十月七日，並對照 GitHub microsoft/mxc 公開說明與 SDK 套件頁）。

同一公告指 Windows 365 對 MXC 的支援亦已全面可用，讓企業可在雲端電腦上以相同隔離模型並行跑代理與日常工作；NVIDIA 亦已把 OpenShell 整合進 MXC，補強檔案、推理服務存取、網絡與憑證管治。對正在把編程代理、瀏覽器代理推進生產環境的香港與亞洲企業，這是把「最小權限」從口號落成 OS 邊界的重要一步。

微軟／官方：MXC 執行容器全面可用——以 OS 級政策邊界關 AI 代理；跨三平台 SDK，Windows 365 同步 GA

微軟於二零二六年十月七日在 Windows Developer Blog 宣布，Microsoft Execution Containers（簡稱 MXC）正式進入全面可用（generally available）階段，定位為「政策驅動」的執行層，專門約束不可信程式碼與動態產生工作負載——包括模型輸出、外掛、工具、代理框架，以至整個代理程序。本文已核對官方網誌與開源倉庫說明，來源真實性已驗證；以下梳理機制、落地方式，以及對香港企業的實務含義。

一、核心事件：代理不能再當自己的資安官

技術細節

官方開宗明義寫道：代理不應成為自身的安全權威，必須在開發者或組織定義、且獨立於代理之外強制執行的邊界內運行。典型場景是編程代理被要求更新網站——它需要讀寫程式庫與開發工具，甚至可以「讀」生產設定以理解部署方式，但不應被允許「改」生產設定；若沒有受管執行邊界，模型可能認為改設定是完成任務最快的路徑，從而超出開發者意圖。

MXC 的做法是：由開發者宣告工作負載所需資源（檔案路徑、網絡目的地等），再由 MXC 依政策選擇合適容器後端並在運行時強制執行；政策留在代理工作負載之外，因此代理或產生的程式碼不能自行加權。官方強調 Windows／macOS／Linux 共用統一 JSON 設定架構與多語言 SDK，平台差異由 MXC 映射到後端。

隔離強度可按工作負載分級：輕量場景可用平台原生行程沙箱（Windows 的 AppContainer、macOS 的 Seatbelt、Linux 的 Bubblewrap）；Windows 11 另提供 session container，讓代理以獨立本機代理身分、在隔離桌面／剪貼簿／輸入邊界的工作階段運行。官方亦指 Windows 365 對 MXC 的支援已全面可用，方便把同一隔離模型延伸到雲端電腦。

二、技術原理深度解析

開源倉庫（microsoft/mxc）把 MXC 描述為可嵌入應用的沙箱執行系統：應用經 SDK（目前公開列出 Rust、.NET、Node）送出容器建立請求與安全政策，由引擎選後端後起動隔離工作負載。後端清單包括 ProcessContainer、Windows Sandbox、LXC、Bubblewrap、Seatbelt、MicroVM（Nanvix）、Hyperlight、IsolationSession、WSLC 等；部分後端標示為實驗性質。政策面向涵蓋檔案系統（唯讀／讀寫／拒絕路徑）、網絡（代理、外連與後端相依的主機過濾）以及 UI（剪貼簿、顯示、圖形介面）。

政策編寫方面，官方網誌列出三種模式，方便「先觀察、再收緊」：

Enforcement（強制）：直接套用政策，邊界外操作被限制，不產生活動報告。
Learning（學習）：仍強制邊界；未授權操作被擋下並寫入 JSON 活動報告，方便重現與補授權。
Permissive（寬鬆）：記錄本會被拒的存取，但允許操作繼續，適合政策起草期蒐證；並不繞過其他 OS 或組織限制。

僅在 Windows 上，行程容器還可產生代理活動報告，列出工作負載嘗試使用的資源，協助撰寫最小權限政策。組織層面，官方預告將以 Microsoft Intune 管理 Windows 11 上 MXC 整合代理所用的行程容器，讓 IT 在代理開發者預設之外再疊企業約束；同一代理可在不同企業邊界下運行，而無須把企業資安姿勢硬編碼進應用。

身份面，Windows 即將讓 Microsoft Entra 區分「代理活動」與「使用者活動」，並把 Microsoft Agent 365 控制延伸到本機代理，目標是：單一代理失控時可針對其存取收緊，而不必一併鎖死員工生產力。NVIDIA 則把 OpenShell 接入 MXC，補上對檔案與推理服務的政策控制、進階網絡控制、憑證管理，以及企業場景的 OCSF 稽核。

四、日常應用場景

1. 開發者與技術團隊

已支援或示範 MXC 的代理／框架包括 GitHub Copilot、OpenClaw、OpenAI Codex、Replit、LM Studio、Unsloth AI 等；官方亦點名 Anthropic Claude Code、Box、Egnyte、Heidi Health、Nous Research 的 Hermes Agent、Manus、Perplexity、Raycast、Simular 等將陸續加入。對本機或 CI 跑編程代理的團隊，可把倉庫與工具鏈放進允許清單，同時擋 Documents、個人雲端同步夾與非必要外連，降低「代理為求過關而亂改設定／外洩密鑰」的爆炸半徑。

2. 企業與隱私敏感行業

金融、法律、醫療等行業若允許代理讀內部知識庫或草稿，卻不能讓它任意外傳或改動核心系統，MXC 這類 OS 強制邊界比單純提示詞約束更可稽核。結合即將到來的代理身分歸因，資安團隊較易在 SIEM／EDR 中把異常行為對到「哪一個代理」，而不是只看到某個員工帳號。

3. 一般用戶

日常使用者未必直接寫 JSON 政策，但當 Copilot、Codex、Replit 等產品把 MXC 嵌進體驗，等於預設以較窄權限跑代理，減少個人檔案與剪貼簿被誤讀、誤傳的機會。官方亦提醒：代理應在權限不足時清楚說明並請求合理授權，而不是靜默失敗或自行試探繞過。

4. 香港與亞洲市場視角

香港企業正大量試行編程代理與辦公代理，同時面對數據出境、客戶保密與監管問責壓力。MXC 把隔離落到 Windows（本地仍佔企業桌面大宗）並延伸 Windows 365，與亞洲常見的「雲端電腦＋本機開發」混合模式契合。對已自建私有模型或代理編排的團隊，跨 Windows／macOS／Linux 的統一政策語意，有助減少「每台筆電一套沙箱腳本」的維運碎片。

五、專業評價與潛在考量

優勢

政策在代理之外強制執行，對齊「代理不能自我授權」的工程原則。
跨平台統一 schema／SDK，降低多 OS 團隊的整合成本。
Learning／Permissive 模式降低最小權限政策的起草門檻。
與 Windows 365、Intune、Entra／Agent 365、NVIDIA OpenShell 的路線圖，指向可管治的企業代理堆疊，而非一次性示範。

需要留意的地方

部分後端仍標實驗性質，生產選型需按工作負載驗證延遲與隔離保證。
Intune 管理與 Entra 代理身分標為即將推出，現階段不能假設管理面已齊全。
政策過嚴會擋合法需求；過寬則形同虛設——仍需安全與平台團隊共同演練。
MXC 解決的是執行邊界，並不替代供應鏈掃描、密鑰管理或雲端 IAM；近期供應鏈蠕蟲與外露 AI 服務攻擊，仍要靠分層防禦。

結語

MXC 全面可用，標誌微軟把 AI 代理安全從「模型對齊」與「產品提示」延伸到作業系統強制隔離：開發者宣告需求、組織可再疊政策，代理無法自行加權。對香港企業而言，這與雲端遷移、零信任與高可用架構同一條治理主線——先界定邊界，再放大代理產能。若貴司正把代理導入開發或營運流程，可一併檢視本機／雲端電腦的隔離與監控設計；需要在香港落地雲端遷移與網絡安全（官網刊 99.99% SLA）時，可參考 YSK Limited 的相關服務（https://ysk.hk/services/cloud-security）。

參考來源

Microsoft Windows Developer Blog — Microsoft Execution Containers: Policy-driven containment for AI agents（2026-10-07）：https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/
GitHub — microsoft/mxc（README／SDK／backends）：https://github.com/microsoft/mxc
npm — @microsoft/mxc-sdk：https://www.npmjs.com/package/@microsoft/mxc-sdk
NuGet — Microsoft.Mxc.Sdk：https://www.nuget.org/packages/Microsoft.Mxc.Sdk
crates.io — mxc-sdk：https://crates.io/crates/mxc-sdk