微软 MXC 正式 GA：把 agent 的权限边界从「应用自觉」搬到「操作系统强制执行」
微软在 2026-10-07 宣布 Microsoft Execution Containers（MXC）正式 GA：开发者用一份 JSON 策略声明 agent 能碰哪些文件、网络与桌面资源，由 Windows 在运行时强制执行，agent 无法给自己扩权。四种隔离后端中 MicroVM 仍是 experimental，Entra 身份区分与 Intune 管控仍为 coming soon。
2026-10-10 · Windows Developer Blog 官方公告（2026-10-07，Logan Iyer 署名，逐段核对）
发布 2026-10-10核实 2026-10-10要点速览
- MXC（Microsoft Execution Containers）已于 2026-10-07 正式 GA，同时 Windows 365 对 MXC 的支持也一并 GA——意味着 Cloud PC 上跑 agent 也能用同一套隔离模型。
- 它解决的不是「agent 会不会乱来」，而是「谁来当安全权威」：官方原话是 「An agent cannot be its own security authority」。策略写在 agent 之外，由操作系统在运行时强制执行，agent 或它生成的代码无法给自己加权限。
- 四种隔离后端，成熟度不同：Process container（Win11/macOS/Linux，GA）、Session container（仅 Win11，GA）、WSL container（Win11，GA）、MicroVM（Win11/Linux，仍为 experimental）。
- 三种运行模式是这篇最实用的部分：Enforcement（按策略拦）、Learning（拦 + 记录 JSON 活动报告）、Permissive（不拦，但记录本会被拦的访问）。写最小权限策略的正确姿势是先用 Permissive 观察，再转 Learning 验证，最后进 Enforcement。
- 已经接入的 agent：GitHub Copilot、OpenAI Codex、OpenClaw、Replit、LM Studio、Unsloth AI，以及 NVIDIA OpenShell。Claude Code、Manus、Perplexity、Box、Raycast 等在「即将支持」名单里。
- 别把 GA 理解成「企业管控已就绪」：Entra 区分 agent 与用户活动、Agent 365 管理本地 agent、Intune 管理 MXC 进程容器三项官方均标注为 coming soon / will soon be available，今天还不可用。
为什么微软要专门做一层「执行边界」
官方给的例子很能说明问题：让一个 coding agent 去改网站。它需要对仓库读写、需要构建与测试工具、可能需要读生产服务器配置来理解部署方式——但不应该能改这份配置。
没有边界时，agent 完全可能判断「改一下服务器配置是最快完成任务的路径」，然后把生产站搞挂。这个动作从 agent 的视角看是合理的，却超出了开发者原本想授予的权限。
MXC 的做法是把这个边界外置并强制化：
The policy remains outside the agent workload's control, so the agent or generated code cannot grant itself additional access.
这条设计对 agent 工具尤其关键——此前主流做法（应用内 allowlist、提示词约束、模型对齐）都属于「靠应用自觉」，模型一旦被提示注入或生成了越权代码，防线就跟着一起失效。MXC 把防线放到了应用之外的操作系统层。
四种隔离后端：按负载挑，不是越重越好
| 后端 | 可用平台 | 状态 | 适合什么 | 关键特征 |
|---|---|---|---|---|
| Process container | Windows 11 / macOS / Linux | GA | 模型生成的代码、工具执行等要求低延迟、高响应的负载 | 用平台原生进程沙箱：Windows 的 AppContainer、macOS 的 Seatbelt、Linux 的 Bubblewrap |
| Session container | 仅 Windows 11 | GA | 需要桌面、或要与交互用户强隔离的长期运行 agent / 自动化 | 跑在独立的 Windows 账户与会话下，桌面、剪贴板、UI、输入、活动会话全部与用户分离 |
| WSL container（WSLc） | 仅 Windows 11 | GA | 依赖 Linux 包与开发生态的 Linux 优先工具链 | 通过 WSL 提供 Linux 执行环境 |
| MicroVM | Windows 11 / Linux | experimental | 需要硬件级虚拟化边界的高风险负载 | 硬件强制隔离 + 完整 Linux 负载兼容 |
这里有个容易被忽略的取舍：隔离最强的那一档（MicroVM，有 hypervisor 隔在中间）恰恰是官方标注为 experimental 的一档。也就是说，今天生产可用的最强边界是 Session container，而它只有 Windows 11 有。官方自己也提醒：「Each containment backend has distinct security properties and workloads should be evaluated for fit」——别拿进程级隔离去顶一个本该用虚拟化隔离的需求。
策略能管什么：五个维度
开发者用统一的 JSON 配置 schema + 多语言 SDK（仓库在 GitHub，MIT 许可，提供 Rust / .NET / Node 接口）声明资源，MXC 负责把它映射到具体后端：
| 策略域 | 控制内容 |
|---|---|
| Containment | 负载跑在哪个隔离环境里（进程容器 / 会话容器……） |
| Process | 启动负载所用的命令、参数、工作目录、环境变量等 |
| File system | 哪些位置可改、哪些只读、哪些完全不可访问 |
| Network | 入站 / 出站连接，含能否通过宿主机 loopback 访问服务 |
| User interface | 能否访问或操作桌面及相关 UI 资源 |
注意 Network 一栏里明确包含 loopback——这条对本地开发很实在：agent 起个本地调试服务、或去戳你本机的 11434（Ollama）/ 其他本地端口，都是可以被策略单独关掉的，而不是「要么全断网要么全放开」。
三种运行模式：这才是能立刻用起来的部分
写「最小权限策略」最难的地方在于——你事先根本不知道这个 agent 到底要碰哪些资源。MXC 给了三个模式来渐进收敛（活动报告目前仅 Windows 的进程容器支持）：
| 模式 | 未授权访问 | 活动报告 | 用途 |
|---|---|---|---|
| Enforcement | 阻断 | 无 | 用已确定的生产策略跑负载 |
| Learning | 阻断并记录 | 有 | 复现隔离失败、验证策略是否只授予了必需权限 |
| Permissive | 放行并记录 | 有 | 在策略编写期观察 agent 到底想碰什么，负载能跑完，同时收集证据 |
推荐顺序：Permissive 跑一遍收集证据 → 收敛成最小权限策略 → Learning 验证无遗漏 → Enforcement 上线。
Permissive 不是绕过其它限制：官方明确 「Permissive mode does not bypass other applicable operating system or organizational restrictions」。它只是不执行 MXC 自己的策略，操作系统与组织层面的既有约束照旧生效。
另外官方给了一个对 agent 开发者很重要的行为要求：组织策略可能比默认配置更严格，agent 遇到被拦时应该说清楚「在当前权限下完不成」、请求用户或管理员动作、或选一个安全的替代路径——「It should not silently fail」。静默失败是这一类沙箱落地后最常见的体验事故。
谁已经支持，谁在路上
已支持：GitHub Copilot、OpenAI Codex、OpenClaw、Replit、LM Studio、Unsloth AI。NVIDIA 的 OpenShell 也已完成集成，额外补上了文件与推理服务的策略控制、高级网络控制、凭据管理，以及面向企业的 OCSF 审计。
官方列为「即将支持」：Anthropic Claude Code、Box、Egnyte、Heidi Health、Hermes Agent by Nous Research、Manus、Perplexity、Raycast、Simular 等。
读法提醒：「已支持」是微软单方面的集成状态报告，不等于每个客户端都已默认开启、也不等于每个后端都被该客户端支持。例如 GitHub 侧另有文档说明 Copilot 在 Windows 上用的是 MXC 的 BaseContainer 档 ProcessContainer，且 shell 命令与本地 MCP / 语言服务器进程走进程边界，而内置文件工具是在 agent harness 内做策略检查、远程 MCP server 则不在本地进程沙箱内——不要以为开了 MXC 就把 Copilot 的每一个操作都罩住了。本站未逐客户端实测，接入状态请以各工具自己的文档为准（待核实）。
AI 之家 观点
这一条的意义不在「微软又出了个沙箱」，而在 agent 安全的责任方发生了转移。
过去两年，agent 的权限控制基本是应用内实现的：Cursor / Claude Code / Codex 各自有一套 allowlist 与审批交互。问题是这些控制与 agent 共享同一个进程与同一份信任——一旦模型被注入、或被诱导生成了绕过检查的代码，护栏就和 agent 一起失守。这跟 Claude Code 近期反复修钩子语义（v2.1.294 修「自然语言钩子会放行本该拦下的动作」、v2.1.295 引入 onFailure: "block" 把 fail open 改成 fail closed，详见 v2.1.295 资讯）是同一类问题的两种解法：一个在应用层把护栏修严，一个干脆把护栏搬出应用。
但 GA 不等于企业可用。 这里要泼一盆冷水：官方通篇把身份（Entra 区分 agent 与用户）、可管理性（Agent 365 管本地 agent、Intune 管 MXC 进程容器）都写成 coming soon。这意味着今天 MXC 的策略仍然主要由「agent 的开发者」书写，IT 部门还没有统一的下发与审计入口。对组织的建议是：现在可以做开发者侧的试点与观察（Learning / Permissive 模式正是为此设计的），但不要把「桌面 agent 已在 MXC 里跑」当作 fleet-wide 放行的理由。
对国内团队的额外提示：Session container 只有 Windows 11，且长期运行的桌面自动化是它最对口的场景；Linux 优先的工具链走 WSLc。macOS 用户目前只能拿到 Process container 这一档（AppContainer 对应物为 Seatbelt）——跨平台团队要给同一批 agent 准备三套不同的边界预期。
待核实
- 各客户端的实际启用状态与默认后端：微软公告只给集成名单，未给 Copilot / Codex / OpenClaw 各自的版本门槛、默认值与支持的后端。本站未逐客户端实测，请以各工具官方文档为准。
- MicroVM 后端的转正时间：官方仅标注 experimental（仓库侧
windows_sandbox/microvm/hyperlight亦标 experimental），未给 GA 时间表。 - Entra 身份区分、Agent 365 本地 agent 管控、Intune MXC 策略的具体上线时间：官方只写「soon」。
- MXC 在中国大陆 Windows 上的可用性与后端差异：官方公告未涉及区域限制，本站未实测。
- GitHub Copilot 侧对 Windows 版本的具体要求（有第三方整理称需 Win11 25H2 + 某 KB 或 26H1 + BaseContainer 支持）：来自二手整理，未核对微软官方文档，不采信。
来源
- Microsoft Execution Containers: Policy-driven containment for AI agents（Windows Developer Blog，2026-10-07，一手核对）
- MXC 仓库（GitHub，MIT 许可，含 SDK / 配置 schema / 文档 / 示例）
- 延伸阅读：Agent 沙箱、提示注入、Claude Code v2.1.295 钩子 fail closed
口径说明：本文事实部分逐段核对微软官方公告原文；事件日期 2026-10-07 取自该公告的发布时间（官方页面标注 published October 7, 2026），非推断。