目录

假设一个 AI 编程智能体需要修复未通过的测试。它必须能够读取项目、编辑源文件并运行测试套件。但是否也应该赋予同一个智能体打开个人文档、读取其他目录中的凭据，甚至向陌生服务器发送文件的权限？

如果使用日常的 Windows 账户运行智能体，这些权限往往会被一并授予。即使任务只需要访问一个代码仓库，智能体最终也可能获得远超所需范围的访问权限。

Microsoft Execution Containers（MXC）是一种用于明确这条边界的机制。根据所提供的发布报告，Microsoft 已在 Windows 11 上正式推出 MXC，允许对智能体可访问的文件和网络设置限制。2026 年 10 月 7 日的 Windows Developer 公告说明，这些策略会在运行时强制执行。

实际变化很明确：开发者可以独立于给 AI 模型的指令，定义智能体的活动范围。与要求智能体谨慎行事相比，这提供了更可靠的基础。

MXC 如何改变智能体的运行方式#

传统桌面应用程序通常使用从启动它的用户那里继承的权限运行。AI 智能体可以通过终端、浏览器、文件操作和应用集成等获准使用的工具，行使这些权限。

问题就出在这里。用户授权的是“整理文件夹”这样的目标，而软件获得的访问权限却可能允许它修改无关数据。

MXC 提供了运行智能体的隔离环境。根据发布报告，可以将整个智能体放入该环境，也可以单独隔离插件、工具或智能体运行框架等组件。生成的产物也可以保留在该环境内。

这一点很重要，因为智能体系统的不同部分具有不同的风险。负责规划的组件可能只需要输出文本，而执行生成命令的工具则需要更审慎地定义边界。

报告提到的功能包括访问限制、人类与智能体活动的分离，以及对智能体操作的监控。结合这些功能，开发者可以限制智能体的能力，并更容易区分智能体的操作与用户自己的工作。

不过，这些功能并不能保证智能体的判断正确。对于获准编辑的文件，智能体仍有可能做出有害修改。

面向不同用途的四种隔离方式#

MXC 提供多个后端，而非将所有智能体都视为同一类工作负载。发布报告列出了以下四种。

| 后端 | 报告中描述的边界 | 适用场景 | |---|---|---| | AppContainer | 通过 Windows AppContainer 实现进程隔离 | 编程智能体及单个工具的执行 | | 会话容器 | 隔离账户与交互式会话资源 | 操作桌面的长期运行智能体 | | WSL 容器（WSLc） | 在 WSL 内提供基于容器的隔离 | 需要 Linux 环境的工作负载 | | MicroVM | 硬件级隔离 | 需要硬件支持的边界的工作负载 |

评估这些选项时，需要考虑任务内容以及发生问题时的影响。现有报告没有提供性能测试结果或完整的兼容性列表，因此没有依据将其中任何一种认定为适合所有部署环境的最佳默认后端。

AppContainer：限制进程#

AppContainer 是 Windows 已有的隔离机制。在 MXC 中，它作为进程级选项提供，报告将其定位于编程智能体和工具执行场景。

以修改本地项目的智能体为例。它所需的工作范围可能只包括代码仓库、临时目录和选定的开发工具。访问其他用户文件对任务没有帮助，只会增加风险。

在这种情况下，任务可以表示为范围有限的工具操作，因此进程隔离很合适。至于具体可以授予应用哪些权限，以及如何通过 MXC 进行配置，需要查阅 Microsoft 的文档。

会话容器：隔离智能体的桌面操作#

长期运行的桌面智能体有不同的需求。它可能需要操作应用程序、在屏幕上导航，并维持交互式会话。

根据发布报告，会话容器使用独立账户运行智能体，将其桌面、剪贴板、用户界面、输入和活动会话与人类用户隔离。

这种区别有实际意义。如果桌面智能体与人类在同一会话中运行，就可能发生焦点切换、剪贴板被覆盖，或向错误窗口输入内容等干扰。

会话隔离可以应对这类问题。同时，这也意味着必须在智能体专用环境中，充分测试应用设置、身份验证和共享资源访问。

WSLc 与 MicroVM：选择工作负载所需的边界#

报告提到的其他选项是 WSL 容器和 MicroVM。

WSLc 在 Windows Subsystem for Linux 内提供基于容器的隔离。MicroVM 则提供硬件级隔离。

需要考虑的是，在确保工作负载正常运行的同时，各个后端能够隔离哪些内容。Linux 开发任务与 Windows 桌面自动化可能有不同的需求。处理不可信输入的工具，可能需要不同于编辑小型、管理完善的代码仓库的智能体的边界。

无论选择哪种后端，都应确认其前提条件、支持的工作流程和运行时行为。仅凭公告无法了解这些细节。

文件权限应与任务相匹配#

“访问项目文件”听起来很明确，但如果项目中包含凭据、非公开数据或部署配置，情况就会变得不同。

要制定实用的策略，首先应区分智能体需要读取和需要修改的内容。对于编程任务，例如可以做如下配置：

  • 对目标代码仓库拥有读写权限。
  • 对另一个参考目录拥有只读权限。
  • 为临时文件和生成产物设置专用位置。
  • 禁止访问无关的个人文件夹和凭据存储。

这是一种部署模式建议，并不代表 MXC 的配置语法，也不说明所有后端支持的控制粒度。这些细节需要查阅文档确认。

即便如此，这个原则仍然有用：权限应与当前任务相匹配。如果智能体只是更新文档，就需要慎重考虑它是否真的需要对应用配置拥有广泛的写入权限。

还应考虑执行结束后会发生什么。如果有人在容器外打开或执行输出文件，它们仍然可能造成危害。隔离环境可以作为检查产物的场所，但并不会让产物本身变得可信。

网络访问需要独立的策略#

智能体可能需要连接模型提供商、下载依赖项或查询内部服务。但不受限制的网络连接，也会为发生故障或受到恶意诱导的智能体提供向外发送数据的通道。

因此，报告所称的 MXC 可自定义网络访问这一能力，与文件边界同样重要。

首次部署时，请列出任务所需的连接目标。明确哪些服务会接收源代码或文档内容，哪些服务仅用于下载。然后确认，在所选后端上，MXC 能够强制执行哪些限制。

不要仅凭“网络策略”这一表述，就认为它保证支持域名过滤、协议控制，或能够了解加密通信的内容。所提供的报告没有明确提到这些功能。

目标是制定可以测试的策略。如果智能体需要访问获准的软件包分发源，就应确认该访问能够正常进行。接着，尝试本应被拒绝的连接，并检查结果。

隔离可以限制损害，但无法解决提示注入#

文档、网页和代码仓库文件中可能包含诱导智能体采取其他行动的文字。如果智能体将这些文字视为指令，就可能尝试执行用户并未要求的操作。

运行时限制可以遏制其中一部分影响。如果边界配置正确且得到执行，超出允许范围的读取操作就应当失败。

但智能体也可能滥用获准的访问权限。如果它能够读取机密文档，并将内容发送给获准的服务，仅靠隔离无法判断这种发送行为是否符合用户意图。

因此，访问控制与操作确认需要分别考虑。MXC 可以定义允许操作的范围。即使在这个范围内，应用程序仍需妥善处理会产生重大后果的操作，尤其是发送消息、删除共享数据和发布更改。

沙箱测试成功，可以证明边界正在发挥作用，却不能证明边界内的所有判断都是安全的。

已提供的功能与仍需确认的事项#

截至 2026 年 10 月 19 日，所提供的报告称，MXC 已在 Windows 11 上正式推出。报告还提到，计划通过 Microsoft Intune 提供组织级策略管理。

应谨慎区分这两点。运行时正式推出，并不意味着已公布的所有管理功能都已可用。

报告将 OpenClaw 和 Anthropic Claude Code 列为与 MXC 支持相关的合作伙伴。但其中并未说明哪些产品版本包含集成功能、是否默认启用，以及支持哪些后端。

部署前，请查阅 Microsoft 和各合作伙伴的最新文档，确认 Windows 要求、安装步骤、可用后端和策略配置。还需要验证，这些集成能够在计划实际部署的版本中正常工作。

从一项范围有限的任务开始#

首次测试适合选择所需访问权限容易说明的工作流程，例如在一个可随时丢弃的代码仓库中更新文档。

请按以下四个步骤评估：

1. 定义成功条件。 指定智能体应修改的文件，以及应生成的输出。 2. 设置边界。 选择后端，并配置所需的文件和网络访问权限。 3. 测试本应被拒绝的操作。 尝试读取无关文件夹、向工作区外写入，以及连接未经批准的目标。 4. 检查结果。 查看产物，以及可获取的活动记录，包括失败的操作。

首次测试时，不要将凭据或重要数据放入环境。确认任务能够正常进行后，仅在需求得到验证时才增加权限。

MXC 的价值取决于是否严格落实这些做法。可配置的边界只有在符合实际任务需求，并且在运行偏离预期的情况下也经过测试时，才能发挥作用。

请选择一个智能体工作流程，列出所需的访问权限。然后在一个可随时丢弃的 Windows 11 环境中，验证 MXC 是否既能允许必要的工作，又能阻止超出范围的操作。

来源：https://www.publickey1.jp/blog/26/windowsaimicrosoft_execution_containersmxc.html

目录