Sysdig 在 7 月 4 日披露的 JadePuffer 還在資安圈發酵時，Microsoft 在 7 月 7 日前後把另一套答案推進早期預覽：Microsoft Execution Containers（MXC）——一套跨 Windows 與 Windows Subsystem for Linux（WSL）的政策驅動執行層，讓開發者宣告 AI 代理 能碰哪些檔案與網路資源，由作業系統在執行期強制隔離。Windows 安全與平台副總 Dana Huang、Logan Iyer 的表述很直接：代理行為是動態且常在執行期生成的，「非確定性不應轉化成不可控風險」；隔離（containment） 要在生產力與邊界之間畫線。MXC SDK 已開源於 GitHub（MIT 授權），並與 Agent 365、Microsoft Entra、Intune 對接——這是繼 KAIST 量出代理能耗 之後，代理議題從「燒多少電」擴展到「在企業桌面燒之前先關進哪個籠子」。
MXC 解決的是什麼問題
傳統資安假設：程式碼由人寫、權限可審。代理時代：模型依提示當場生成程式碼，串連讀檔、連網、執行命令——JadePuffer 證明這條鏈可在無人值守下跑完勒索流程。企業若只擋「提示詞裡的惡意字串」，擋不住代理在合法工具鏈裡試錯迭代。
MXC 的定位是可組合沙箱光譜（composable sandbox）：同一套 SDK 與政策模型，依工作負載風險對應不同隔離後端——從輕量行程容器到未來的 micro-VM、WSL Linux 容器。開發者不必自行拼裝底層隔離原語；Windows 在 runtime 統一執行。
Microsoft 在說明中強調 Agent 365 原生整合 MXC，透過 Entra 身分與 Intune 政策對特定代理下達約束——這與「只監控聊天紀錄」不同，是對執行環境下政策。
早期預覽裡有什麼
行程隔離（process isolation）
AI 生成程式碼在獨立環境執行，檔案與網路存取受限。GitHub Copilot CLI 已採用此模式，限制 AI 生成程式碼能觸及的資源——開發者工作流不必整機鎖死，但高風險動作被框在容器內。
工作階段隔離（session isolation）
代理與使用者桌面、剪貼簿、輸入裝置與使用中工作階段分離，降低資料外洩與介面攻擊（例如代理讀取螢幕敏感資訊）。每個工作階段有獨立身分，支援最小權限、稽核與透過 Entra／Intune 管理政策。初期版本支援非互動式工作階段；互動式能力列為後續版本。
路線圖上的更重隔離
- micro-VM：硬體虛擬化，處理敏感資料或不可信程式碼。
- WSL Linux 容器：延伸同一 containment 模型到 Linux 開發環境。
GitHub 儲存庫 README 列出多平台後端（Windows 11 24H2+ 的 processcontainer、bubblewrap on Linux、macOS seatbelt 等），並明確警告：早期預覽中部分政策可能過於寬鬆，目前不應視為已成熟的安全邊界——歡迎資安研究員回報，但生產環境須保守評估。
夥伴與生態：從 Codex 到 OpenClaw
Microsoft 公布與 Hermes、Manus、NVIDIA、OpenAI、OpenClaw 等合作，在 MXC 上建置與部署代理：
- OpenAI：技術人員 David Wiesen 稱，結合 Codex 能力與 MXC 執行環境，目標是讓開發者從意圖到可靠執行更快，同時保持企業所需安全與控制。
- NVIDIA：將 MXC 整合進 OpenShell，協助在 Windows 上安全部署自主代理。
- OpenClaw：以 MXC 保護 node 與 gateway，並提供 Windows 配套 App 部署管理代理。
這與 Build 2026 以來「Windows 即代理平台」敘事一致：本機小型模型（如 Aion 系列預覽）、Windows 365 for Agents（代理在 Intune 管理的 Cloud PC 執行，與本機分離）與 MXC 形成「輕量本機 → 政策沙箱 → 全雲端桌面」的光譜。7 月 Agent 365 預覽將疊加 Defender、Entra、Intune、Purview，把沙箱升格為企業控制平面。
與 JadePuffer、華府治理的關係
JadePuffer 攻擊鏈起於 Langflow CVE、橫向移動至 Nacos／MinIO——典型雲端 AI 工作流堆疊。MXC 主要守的是 Windows 企業桌面與開發機上的代理執行，兩者互補而非重疊：MXC 擋不住已暴露的雲端編排平台，但能降低「員工本機跑 Copilot／Claude Code 生成腳本」變成橫向移動起點的機率。
華府談論 CJS 越獄分級 與日内瓦 聯合國科學小組 談代理治理步驟變革時，MXC 代表產業落地層：把「代理要人類在環」寫進 OS 政策，而非只寫在模型卡。7 月初媒體報導 Meta 內部稱代理進展慢於預期，亦說明企業需要可部署的 containment 才敢放大代理權限——MXC 正是賣給「想快但怕失控」的 IT 部門。
企業採購與開發者該問什麼
| 問題 | 為何重要 |
|---|---|
| 我們用的代理是否支援 MXC 政策檔？ | 不支援則仍靠應用層自訂沙箱 |
| 行程隔離 vs micro-VM 如何選？ | 敏感資料與不可信程式碼應規劃更重後端 |
| Agent 365 7 月預覽是否涵蓋我們的 Entra 租戶？ | 集中政策比單機 SDK 更接近合規審計 |
| 早期預覽警告讀了嗎？ | README 明示政策可能過寬，勿過度信任 |
| 與 網路安全 紅隊劇本是否對齊？ | 應測「政策繞過」而非只測提示詞 |
Red Team 建議：在 MXC 上跑「自主修補代理」與「自主攻擊代理」對照演練——與 JadePuffer 案例相同，重點是工具鏈在無人值守下能走多遠，而非單次生成惡意字串。
限制與批評面
預覽即預覽：GitHub 警告當前政策生成可能過於寬鬆；micro-VM 與完整 Linux 容器尚未普遍可用。
Windows 中心：WSL 覆蓋 Linux 開發者，但 macOS 僅 seatbelt 後端（schema 0.7.0-alpha+），跨平台一致性仍待驗證。
不取代雲端安全：Langflow、K8s、Nacos 類漏洞仍需補丁與網路分段；MXC 不解雲端設定中心被加密。
與模型安全分工：MXC 管「執行能做什麼」，不管「模型會不會越獄教人造 exploit」——兩層都要。
Microsoft 的賭注是：代理普及的瓶頸不是模型不夠聰明，而是企業不敢給執行權；用 OS 級政策降低失控成本，比等華府 8 月 1 日框架更能加快合法代理部署——前提是早期預覽的警告被當真，而不是當成合規打勾。
一句話：MXC 把 代理式推理 的戰場從提示詞拉到執行環境——JadePuffer 證明代理會自己走完攻擊鏈，Windows 現在試著證明作業系統也能自己畫出代理不准跨的那條線。