关于本文
本文是通过利用生成式AI的自动化生成流程创建的。虽然是基于参考来源的信息进行整理的，但作者并未进行实机验证。
验证状态：unverified（未进行实机验证）
Microsoft Execution Containers（MXC）是一个策略驱动的执行隔离基础设施，已作为正式发布（GA）功能引入，它在操作系统级别限制了AI代理或动态生成代码可以访问的文件和网络等权限。通过在外部强制执行由开发人员或管理员定义的边界，降低了代理执行超出用户预期操作的风险。
为什么需要代理专用的执行边界？
AI代理可以跨越整个系统的各种资源（如文件操作、命令执行和网络通信）自主工作。然而，不能将安全决策权限交由代理自身。因为即使模型或工具为了完成任务而判断其行为是“合理的”，它也可能偏离系统管理员预期的权限范围。
在第一手资料中，举了一个被委托更新网站的编码代理的例子。即使代理为了解构建和部署状态而需要参考生产服务器的配置信息，也不应赋予其重写该配置文件的权限。在执行边界不受管理的环境中，代理可能会将重写生产配置作为最短路径，从而带来引发服务故障的危险。
MXC通过独立于代理内部判断的操作系统级策略，强制执行“允许读取但拒绝更新”等边界，并提供了一种机制，即使万一发生误操作或非预期的更改，也能将影响范围封锁在边界之内。
Microsoft Execution Containers（MXC）的整体架构
MXC是一个策略驱动层，用于执行不受信任的代码或模型动态生成的工作负载。它不仅可以封装整个代理，还可以按任意单位将模型生成的代码、插件、单个工具以及代理框架等关在容器内。
开发人员使用统一的JSON配置架构和多语言SDK来定义资源需求。MXC会自动将这些请求映射到Windows、macOS和Linux等目标操作系统专有的沙盒机制中，因此无需关注针对每个操作系统的单独实现，即可应用相同的策略模型。
此外，一手资料还指出，MXC不仅可以在本地设备上使用，还可以在Windows 365的Cloud PC上使用，这使得在云环境和本地环境中都能够实现一致的代理隔离。
针对不同用途的四种容器后端
在MXC中，根据工作负载的性质、安全要求以及所需的响应能力，准备了多个后端。
| 后端 | 支持的操作系统 | 适合的工作负载 | 主要特征 |
|---|---|---|---|
| Process container | Windows 11、macOS、Linux | 需要低延迟的轻量级工作负载，例如模型生成的代码和工具执行 | 利用各个操作系统的进程沙箱，例如 Windows 上的 AppContainer、macOS 上的 Seatbelt 以及 Linux 上的 Bubblewrap |
| 会话容器 (Session container) | 仅限 Windows 11 | 需要桌面环境的长时间运行代理和自动化处理 | 在独立的 Windows 帐户和会话中运行，桌面、剪贴板、UI 和输入边界与交互用户完全隔离 |
| WSL 容器 (WSL container / WSLc) | 仅限 Windows 11 | 依赖 Linux 软件包和开发生态系统的代理工具链 | 通过 WSL（适用于 Linux 的 Windows 子系统）提供 Linux 运行环境 |
| 微型虚拟机 (MicroVM) | Windows 11、Linux（实验性功能） | 需要硬件虚拟化边界的高风险工作负载 | 提供硬件级别的隔离以及完整的 Linux 工作负载兼容性 |
特别是会话容器作为仅限 Windows 11 的后端，其特点在于能够将正在交互的用户环境与代理的 UI 及剪贴板完全隔离，从而安全地执行自动化操作。
可通过策略控制的 5 个领域
代理可使用的资源作为由操作系统强制执行的边界在 MXC 策略中进行声明。代理不会被直接委派当前登录用户的全部权限，而是仅分配任务所需的最小资源。
第一手资料中指出的策略控制领域如下 5 个：
隔离环境 (Containment)
指定运行工作负载的隔离后端类型，例如进程容器或会话容器。Process（进程设置）
定义有关工作负载启动的基本参数，例如执行命令、参数、工作目录和环境变量。File system（文件系统）
单独指定仅允许读取的路径、允许写入和修改的路径，以及完全禁止访问的路径。Network（网络连接）
设置入站和出站通信的允许性。还包括是否允许通过主机的回环接口（localhost）进行通信。User interface（用户界面）
控制是否允许访问桌面屏幕或UI相关资源并进行交互操作。
支持策略创建和验证的三种操作模式
在基于最小权限原则创建策略时，一开始就涵盖代理所需的所有资源并非易事。Windows 上的 MXC 进程容器提供了三种操作模式，用于生成代理活动报告并逐步完善策略。
| 操作模式 | 未授权访问的行为 | 活动报告 | 主要用途 |
|---|---|---|---|
| Enforcement | 阻止 | 无 | 生产环境中的常规运行。严格应用已配置的策略 |
| Learning | 拦截并记录 | 有 | 诊断失败原因并验证是否授予了过多权限。未授权的操作将被拦截并输出到 JSON 报告中 |
| Permissive | 允许并记录 | 有 | 制定策略前的调查。允许被拒绝访问的请求并收集记录（不会绕过操作系统或组织的其他限制） |
可以分阶段应用：先在 Permissive 模式下观察行为，然后在 Learning 模式下确认拦截行为，最后在 Enforcement 模式下投入运行。
代理的身份识别与组织管理的联动
为了建立代理治理，除了隔离（Containment）之外，“身份识别（Identity）”与“可管理性（Manageability）”的联动是不可或缺的。
根据一手资料，Windows 将在未来启用与 Microsoft Entra 的联动，计划在 Microsoft Agent 365 中区分代理活动与人类用户的活动。由于可以按代理单位评估行为和风险，因此即使某个代理发生策略违规，也只需屏蔽该代理的访问权限，而不会停止使用该代理的员工本人的工作或账户权限。
此外，由 Microsoft Intune 提供的管理策略也即将推出，IT 管理员将能够集中管理 Windows 11 上代理请求创建容器的评估标准以及适用的资源边界。
在代理开发方面，当因组织策略导致特定资源被屏蔽时，不应静默异常退出，而是需要实现向用户明确说明无法完成任务的权限不足原因，或选择安全替代方案的功能。
MXC 的采用案例与生态系统
MXC 已经在主要代理和开发环境中得到采用和集成。
NVIDIA: 将 OpenShell 集成到 MXC 中，提供推理服务、文件访问控制、高级网络控制、凭据管理以及面向企业的 OCSF 审计功能。
现有的支持工具与框架: GitHub Copilot、OpenClaw、OpenAI Codex、Replit、LM Studio、Unsloth AI。
计划未来支持的工具：Anthropic Claude Code、Box、Egnyte、Heidi Health、Hermes Agent（Nous Research）、Manus、Perplexity、Raycast、Simular 等。
在 GitHub Copilot 和 Replit 等开发辅助工具中，通过采用 MXC，既允许其访问项目代码库中的代码或运行构建工具，又能确保确实阻止其对无关的个人文件夹或外部网络的非法访问。
总结
Microsoft Execution Containers（MXC）是用于在操作系统级别控制 AI 代理自主执行权限的重要基础。
部署时需要考虑的要求和限制如下。
使用前确认事项:
根据目标工作负载的特性选择合适的后端（Process、Session、WSL、MicroVM）。
梳理代理所需的文件路径、命令、网络连接目标等。
利用 Learning 模式或 Permissive 模式，根据活动报告调整策略。
平台限制与注意事项:
Session container 和 WSL container 仅支持 Windows 11。
MicroVM 后端目前处于实验性功能状态。
活动报告功能仅限于 Windows 环境的进程容器。
通过 Entra 进行身份识别集成以及通过 Intune 进行集中策略管理即将推出（正在等待推出）。
由于尚未在实际设备上应用策略或验证行为，关于环境特定的详细行为，请参考官方 SDK 或代码库文档。
参考信息
- Microsoft Execution Containers: Policy-driven containment for AI agents: https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/
