Windows 编程 Agent 的权限隔离方案

如果你现在在 Windows 上运行一个 coding Agent，它执行的 shell 命令通常拥有你这个用户的全部权限：可以访问你的 SSH 密钥、浏览器配置文件，以及整个用户主目录。Microsoft 正在为 Agent 建立操作系统级别的隔离边界，其中不少能力会先落到开发者手中。

我们花了一些时间阅读相关的官方文档、SDK 仓库和 Microsoft 博客文章。下面谈谈我们的理解：如果你在 Windows 上开发或运行 Agent，这些变化意味着什么。

Microsoft Execution Containers（MXC）是一套开源 SDK（支持 Rust、.NET、Node），可以让 Agent 工作负载在你定义的策略范围内运行，约束文件、网络、UI 和进程本身的访问。Microsoft 于 2026 年 10 月 7 日宣布其正式可用。

不同后端的隔离方式各有不同。Process container 比较轻量；Session container 会让 Agent 在独立的 Windows 账户和会话下运行。此外，还有 WSL container，以及处于实验阶段的 MicroVM。

一些 Agent 已经开始使用它。GitHub Copilot 通过 MXC 对 shell 命令和本地 MCP server 进行沙箱隔离，你可以在 Copilot CLI 中使用 /sandbox 进行配置。

Agent workspace（Settings > System > AI Components > Experimental agentic features）是另一项独立的预览功能，为 Copilot Actions 这类 Agent 提供自己的账户和桌面。

MCP on Windows 提供了一个设备端注册表（odr.exe），默认会在隔离的 Agent 会话中运行打包后的 MCP server。这项功能仍处于预览阶段。

尚未落地的功能包括：针对 MXC process container 的 Intune 策略、基于 Entra 的 Agent 身份，以及面向本地 Agent 的 Agent 365 管理控制。

用一个例子说明问题

Microsoft 自己给出的例子就很贴切。用户让一个 coding Agent 更新网站。它需要读写代码仓库，也需要使用你的构建工具。为了了解部署方式，它可能还需要读取生产服务器配置。但它绝不应该修改那份配置。

如果没有隔离边界，Agent 可能会认为，修改配置是完成任务最快的办法。从模型的角度看，这个决定合情合理；对你来说，结果却可能是一次服务故障。

MXC 公告的核心理念是：“Agent 不能充当自身的安全授权方。”策略存在于 Agent 之外，因此，无论是模型，还是模型编写的代码，都无法自行授予更多访问权限。

MXC 是一个集成到应用或 Agent harness 中的库。你描述容器及其规则，MXC 负责选择后端，并在容器内启动工作负载。它支持 Windows、Linux 和 macOS。microsoft/mxc 仓库采用 MIT 许可证，并为 Rust、.NET 和 Node 发布了 SDK，分别是 crates.io 上的 mxc-sdk、NuGet 上的 Microsoft.Mxc.Sdk，以及 npm 上的 @microsoft/mxc-sdk。

策略涵盖五个方面：

下面是仓库 README 中的 Node 示例。它会运行一条命令，并默认禁止出站网络访问：

import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';

const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  network: { egress: { default: 'deny' } },
  timeoutMs: 30_000,
};

const child = await spawn(request);

在 Windows 上，主要有以下几种选择：

• Process container。 这是默认选项，也是速度最快的选项。在 Windows 上，它使用 AppContainer。它适合 coding Agent 和模型生成的脚本，能让开发中的快速迭代保持流畅。
• Session container（SDK 中的 isolation_session）。 它让 Agent 在独立的 Windows 账户和会话下运行，拥有自己的桌面、剪贴板、UI 和输入。它仅支持 Windows，适合长时间运行的 Agent 和 UI 自动化，也是能够提供独立身份、便于审计的后端。
• WSL container（wslc）。 适用于以 Linux 为主、需要 Linux 软件包的工具链。
• MicroVM。 它使用硬件支持的隔离机制，适合运行不可信代码等风险较高的工作。它被标记为实验性功能，仓库中的 Windows Sandbox 和 Hyperlight 后端也同样处于实验阶段。

这些功能有最低 Windows build 要求。根据仓库中的操作系统版本表，Process container 需要 Windows 11 24H2/25H2 build 26100.9278/26200.9278（2026 年 8 月更新）或更高版本。Session container 需要 26100.9550/26200.9550（2026 年 9 月更新）。在 26H2 上，两者都需要 26300.9550。如果你的 CI runner 或测试 VM 没有及时更新，先检查这一点。

不用靠猜来编写策略

我们觉得这部分最实用。没有人能在运行 Agent 之前，就知道它会访问的每一条路径，因此 MXC 提供了三种模式：

• Enforcement： 阻止所有未经授权的访问，适用于生产环境。
• Learning： 仍然阻止未经授权的访问，但会把每次拒绝记录到一份 JSON 活动报告中。
• Permissive： 允许所有访问，同时记录哪些操作原本会被阻止。

活动报告仅适用于 Windows 上的 Process container。Microsoft 的建议与我们的做法一致：先用 Learning 模式运行，查看被拒绝的访问，再仅授予工作负载确实需要的权限。

有两点需要留意。首先，README 警告，测试执行器 wxc-exec.exe 的 --audit 参数会在当次运行中“关闭所有沙箱安全保护”，因此绝不能用它运行不可信代码。其次，README 说得很直白：“应用在沙箱中运行时会遇到访问问题，直到你花时间调整好隔离规则。”要做好反复调整几轮的准备。

Microsoft 还要求 Agent 开发者考虑一种情况：组织策略可能比你自己的策略更严格。如果某项资源被阻止访问，Agent 应当解释原因，并请求适当的访问权限，而不是悄无声息地失败。这是一项值得现在就纳入设计的 UX 要求。

如果你已经在使用 GitHub Copilot

GitHub 与 Windows 的那篇文章解释了 Copilot 如何使用 MXC。在 Windows 上，它使用 ProcessContainer 后端的 BaseContainer 层级。启用沙箱后，shell 命令、本地 MCP server 和 language server 默认都会在进程隔离边界内运行。

进行威胁建模时，有两个限制需要注意：

• Copilot 内置的文件工具在 Copilot 自身内部运行。它们由 Agent harness 按策略检查，而不是通过操作系统进程隔离来约束。
• 远程 MCP server 位于本地沙箱之外。

要查看或修改设置，在 Copilot CLI 中运行 /sandbox。在 Copilot 应用中，点击齿轮图标打开设置，选择项目，然后开启 Sandbox new sessions。默认情况下，工作目录可读写，系统其余大部分位置则为只读或禁止访问。

Microsoft 列出的其他已支持 MXC 的产品包括 OpenClaw、OpenAI Codex、Replit、LM Studio 和 Unsloth AI。Claude Code、Manus、Perplexity、Raycast 等产品“将发布支持”，但没有给出具体日期。

Agent workspace 是另一回事

这些功能很容易混淆。Agent workspace 来自 Experimental agentic features 设置，Copilot Actions 会使用它。根据 Microsoft Support 的说明：

• 它默认关闭。只有管理员可以开启，开启后会对设备上的所有用户生效。
• 它会创建独立的 Agent 账户，以及拥有自己桌面的 Agent workspace，与用户会话分开。
• Agent 可以请求访问六个已知文件夹：Documents、Downloads、Desktop、Music、Pictures 和 Videos。Agent 账户还可以访问所有已通过身份验证的用户都能访问的文件夹，例如公共用户配置文件目录。
• 在预览版 build 26100.7344 及更高版本中，你可以在 Settings > System > AI Components > Agents 下，按 Agent 设置文件访问权限，选项包括 Allow always、Ask every time 和 Never allow。

还有一个小坑：Windows 安全手册中，这个开关的路径多了一层 Agent tools。Microsoft 自己的页面同时出现了这两种路径，所以，如果你在当前 build 中找不到它，可以在 Settings 中搜索“agentic”。

MCP server 与设备端注册表

如果你要交付一个 MCP server，这部分与你有关。MCP on Windows 新增了 Windows On-Device Agent Registry（ODR）。Agent 通过它发现 MCP server。在 build 26220.7262 或更高版本中，你可以通过终端查看和管理它：

odr mcp list
odr mcp add <path-to-mcpb-manifest-json>
odr mcp remove <server-id>

隔离文档中有一些容易忽略的细节：

• 通过 ODR 注册的打包 server，会在独立的 Agent 账户和 Agent 会话中运行。除非你授权，否则它们无法访问你的文件、设置、凭据或窗口。
• 要在隔离环境中运行，server 必须是具备包标识（MSIX）且具有有效 manifest 的二进制 .exe。MCP bundle（.mcpb）目前无法在隔离环境中运行。
• 隔离环境中的 server 仍然可以访问互联网。这里的隔离限制的是本地访问，而不是网络访问。
• 文件权限按宿主应用授予，而不是按 server 授予。如果某个宿主使用的一个 server 获得了文件访问权限，那么该宿主使用的所有 server 都会获得同样的权限。
• Reduce protections for agent connectors 设置（Settings > System > Advanced > AI components）是为测试准备的。顾名思义，它会降低保护强度。

与 Agent workspace 一样，这些功能都被标记为预发布状态。

还缺少什么

客观看待目前的缺口：据 Microsoft 表示，针对 MXC process container 的 Intune 策略“即将推出”。用于区分 Agent 活动与用户活动的 Entra 支持也“即将推出”，面向设备端 Agent 的 Agent 365 管理控制同样如此。如果你现在要在一批设备上运行 Agent，已经可以对它们进行隔离，但集中治理能力尚不完整。目前更适合先做试点，再考虑全面铺开。

你现在如何在 Windows 上为 Agent 设置沙箱：使用 VM、WSL、Windows Sandbox、独立用户账户，还是完全没有隔离？你会把 MXC 集成到自己的 Agent harness 中，还是等 Intune 和 Entra 支持落地？欢迎在评论区分享你的配置。

我们最早在 Windows Mode 上撰写了这篇文章。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。