Microsoft Execution Containers：面向 AI Agent 的策略驱动隔离机制
英文标题：🔶 Microsoft Execution Containers: Policy-driven containment for AI agents
Microsoft 宣布 Microsoft Execution Containers（MXC）正式全面可用，为 AI Agent 提供由策略驱动的执行隔离层。开发者和 IT 管理员可定义 Agent 能够访问的文件、网络目标、开发工具和 UI 资源，并由底层容器在运行时强制执行。MXC 支持进程容器、Windows 会话容器、WSL 容器和实验性 MicroVM 等不同隔离等级，并可在 Windows、macOS、Linux 及 Windows 365 Cloud PC 上运行。微软还计划结合 Microsoft Entra、Microsoft Agent 365 和 Intune，实现 Agent 身份归因、组织级策略管理及活动监控，已有 GitHub Copilot、OpenAI Codex、Replit 等产品支持 MXC。
4.0 KB
327 B
97.1 KB
93.8 KB
中文
Agent 正在为客户带来巨大的生产力提升，但其跨文件、网络和应用程序工作的能力也可能引入新的安全风险。这可能让客户感觉自己只有两种选择：要么授予 Agent 不受限制的访问权限，并希望不会出问题；要么阻止它们，从而失去其带来的生产力收益。这两种选择都不可接受。
因此，我们正在构建 Windows 平台能力，以帮助用户更安全地运行和管理 Agent，首先从以下方面着手：
- 隔离：限制 Agent 可以访问和执行的内容。
- 身份：将 Agent 的活动与人员活动区分开来。
- 可管理性：为组织提供治理访问权限和监控 Agent 活动的工具。
Microsoft Execution Containers（MXC）现已全面可用，提供了隔离层。开发者和 IT 管理员可定义 Agent 能够使用的资源，例如文件和网络目标；MXC 则使用适当的容器在运行时执行这些策略。
Windows 还将很快支持 Microsoft Entra，以帮助将 Agent 活动与用户活动区分开来，确保即使需要限制 Agent 访问权限，用户依然能够保持高效工作。Windows 还将把 Microsoft Agent 365 控制能力扩展至设备本地的 Agent，使 IT 团队能够管理 MXC 容器、应用策略并监控 Agent 活动。
为什么 Agent 需要受管理的执行边界
Agent 不能成为自身的安全决策者。它必须在由开发者或组织定义、并独立于 Agent 本身强制执行的边界内运行。
以一个被要求更新网站的编程 Agent 为例。该 Agent 需要对网站代码仓库具有读写权限，也需要访问构建和测试变更所需的开发工具。它可能需要读取生产服务器配置，以了解应用程序的部署方式，但不应能够修改该配置。
如果没有受管理的执行边界，Agent 可能判断修改服务器配置是完成任务最快的方式，并可能导致生产网站故障。从 Agent 的角度看，这一操作或许是合理的，但仍会超出开发者原本打算授予的权限范围。
隔离机制创建了这一受管理的边界：Agent 可以读写代码仓库、读取服务器配置，但除非已获得授权，否则无权访问其他任何内容。如果 Agent 尝试修改服务器配置，无论模型、生成的代码、插件或工具决定执行什么操作，隔离环境都旨在阻止该操作。
什么是 Microsoft Execution Containers（MXC）？
Microsoft Execution Containers（MXC）是一个面向不受信任代码或动态生成工作负载的、由策略驱动的执行层。在 Agent 场景中，开发者可使用 MXC 来隔离模型生成的输出、插件、工具、Agent harness（运行框架）或整个 Agent。通过限制 Agent 工作负载可访问的范围，MXC 能在出现问题时控制其影响范围。
开发者声明一个工作负载所需的资源，例如文件和网络目标，MXC 随后通过适当的容器执行由此形成的边界。策略始终处于 Agent 工作负载的控制范围之外，因此 Agent 或生成的代码无法自行授予额外访问权限。
MXC 还将工作负载需求与平台特定的隔离细节分离，从而大幅简化开发者体验。开发者通过统一的 JSON 配置架构和多语言 SDK 进行集成，而 MXC 会将所请求的控制措施映射至 Windows、macOS 或 Linux 上选定的后端。
开发者可以在任何需要运行 Agent 的地方应用同一套隔离模型——从本地设备到云端。随着 MXC 的 Windows 365 支持现已全面可用，开发者可以在 Cloud PC 上将 Agent 与现有工作并行运行，并使用合适的隔离模型，帮助确保 Agent 执行环境相互分离且更加安全。
选择适合工作负载的隔离级别
不同工作负载需要不同级别的隔离。处理代码仓库的编程 Agent 可能优先考虑低延迟和响应速度，而处理敏感数据或运行不受信任代码的 Agent 则可能需要更强隔离。MXC 提供一系列隔离选项，使开发者和组织能够为每个工作负载选择合适的隔离级别。
只有 Windows 支持会话容器。它会在用户设备上、独立且由操作系统隔离的会话中运行 Agent，并为其提供独立的本地 Agent 身份，以及隔离的桌面、剪贴板、UI 和输入边界。
| 后端 | 可用性 | 最适合的场景 | 重要特性 |
|---|---|---|---|
| 进程容器 | Windows 11、macOS 和 Linux | 面向响应性工作负载的轻量级隔离，包括模型生成代码和工具执行。 | 使用与平台相适应的进程沙箱：Windows 上为 AppContainer，macOS 上为 Seatbelt，Linux 上为 Bubblewrap。 |
| 会话容器 | 仅 Windows 11 | 需要桌面环境，或需要与交互用户更强隔离的长期运行 Agent 和自动化任务。 | 在独立的 Windows 帐户和会话下运行，将 Agent 的桌面、剪贴板、UI、输入及活动会话与用户分离。 |
| WSL 容器（WSLc） | 仅 Windows 11 | 面向 Linux 优先的 Agent 工具链，以及依赖 Linux 软件包和开发生态的工作负载。 | 通过 WSL 提供 Linux 执行环境。 |
| MicroVM | Windows 11 和 Linux，实验性 | 可从硬件支持的虚拟化边界中受益的高风险工作负载。 | 提供硬件强制隔离以及完整的 Linux 工作负载兼容性。 |
每种隔离后端都具有不同的安全属性，应评估工作负载是否适合相应的隔离后端。
MXC 策略如何定义工作负载边界
MXC 帮助用户和组织向 Agent 委派更多工作，同时将其限制在完成每项任务所需的资源范围内。开发者和 IT 人员无需向 Agent 授予登录用户的全部权限，而是可围绕 Agent 工作负载定义由操作系统强制执行的边界。
对于网站场景，MXC 策略可以向编程 Agent 授予对本地源代码仓库的读写权限，并允许其访问 Git 等必要开发工具，同时阻止其访问用户“文档”文件夹等个人位置。该策略还可以阻止入站和出站网络连接，以及对交互式桌面的访问。
| 策略领域 | 控制内容 |
|---|---|
| 隔离 | 工作负载运行所在的隔离环境，例如进程容器或会话容器。 |
| 进程 | 用于启动工作负载的命令、参数、工作目录、环境及其他设置。 |
| 文件系统 | 工作负载可修改的位置、可在不修改的情况下读取的位置，以及不可访问的位置。 |
| 网络 | 入站和出站连接，包括工作负载是否可以通过主机的回环接口连接服务。 |
| 用户界面 | 工作负载是否可以访问或与桌面及相关 UI 资源交互。 |
对于 Agent 开发者而言，添加 MXC 支持非常直接——您可以轻松使用自己喜欢的编程 Agent 集成 MXC SDK，并起草初始工作负载策略，随后审查、测试和完善由此生成的控制措施。
工作负载策略与组织策略如何协同工作
Agent 开发者声明其 Agent 工作负载可能需要的资源。组织也可以通过管理策略施加额外约束，例如 Microsoft Intune 管理策略。这样一来，同一个 Agent 可以在不同企业边界内运行，而无需 Agent 开发者将组织的安全态势编码进应用程序。
当组织能够一致地应用隔离机制时，其价值将更高。Intune 策略很快将可用于管理 Windows 11 上由已集成 MXC 的 Agent 使用的 MXC 进程容器。这些策略将让 IT 管理员能够控制 Windows 如何评估 Agent 发出的容器创建请求，以及这些容器所强制执行的资源边界。
Agent 开发者应将其工作负载设计为能够在可能比默认配置更严格的边界内运行。如果组织策略阻止某项资源，Agent 应说明任务无法在现有权限下完成；在支持时请求用户或管理员采取适当操作，或者选择安全的替代方案。它不应静默失败。
在强制执行前观察并优化策略
当您尚不了解 Agent 工作负载所需的每一项资源时，编写最小权限策略可能很困难。仅在 Windows 上，MXC 进程容器可生成 Agent 活动报告，显示工作负载曾尝试使用哪些资源，以帮助制定最小权限策略。
MXC 支持三种运行模式：
| 模式 | 未获授予的访问 | 活动报告 | 预期用途 |
|---|---|---|---|
| 强制执行 | 阻止 | 否 | 使用生产策略运行工作负载 |
| 学习 | 阻止并记录 | 是 | 诊断故障，并验证策略仅授予所需访问权限 |
| 宽松 | 允许并记录 | 是 | 在不强制执行策略的情况下观察 Agent 活动 |
在强制执行模式下，MXC 应用策略但不生成活动报告。已获授予的操作可以继续，而边界之外的操作会受到限制。
在学习模式下，MXC 会继续强制执行已配置的边界。未获授予的操作将被阻止并记录在 JSON 活动报告中。这使开发者或 IT 人员能够复现隔离故障，并了解工作负载尝试访问了哪些资源。
在宽松模式下，MXC 会记录原本会被策略拒绝的访问，但允许操作继续进行。这在策略编写期间非常有用，因为工作负载可以完成，同时开发者或 IT 人员可以收集有关其所使用资源的证据。宽松模式不会绕过其他适用的操作系统或组织限制。
首次将 Agent 引入 MXC 容器时，策略可能会阻止工作负载确实需要的功能。这些拒绝结果会揭示需要调整边界的位置，帮助您授予必要访问权限，而不会不必要地扩大 Agent 的权限范围。
Agent 身份与归因
隔离机制回答的是 Agent 可以做什么。身份机制则有助于确定是哪一个 Agent 执行了某项操作。Windows 即将允许 Microsoft Entra 在 Microsoft Agent 365 中将 Agent 活动与用户活动区分开来。
这种分离将使安全团队能够独立于设备使用者，评估 Agent 的行为和风险。如果某个 Agent 遭到入侵或违反策略，安全控制将针对该 Agent 对受保护资源的访问，而不会阻止员工自身的访问。随着组织部署越来越多的 Agent，一个行为异常的 Agent 不必干扰员工的访问权限或生产力。
Agent 级别的归因还可改进调查和治理。管理员将能够使用 Agent 365 了解有哪些 Agent 正在运行，将活动关联到特定 Agent，调查风险行为，并对单个 Agent 或 Agent 组应用策略，而非仅依赖用户级或设备级上下文。
当前使用 MXC 的 Agent
NVIDIA 已将 OpenShell 集成到 MXC 中，通过 Agent 对文件和推理服务的访问策略控制、高级网络控制、凭据管理，以及面向企业的 OCSF 审计能力，对 MXC 形成补充。
领先的 Agent 和 Agent 框架已支持 MXC，包括 GitHub Copilot、OpenClaw、OpenAI Codex、Replit、LM Studio 和 Unsloth AI。许多其他产品也将推出 MXC 支持，包括 Anthropic Claude Code、Box、Egnyte、Heidi Health、Nous Research 的 Hermes Agent、Manus、Perplexity、Raycast 和 Simular 等。对于每天使用 AI 的人而言，这些保障措施本身就是 Agent 体验的一部分，使用户能够以更安全的方式使用这些工具。
GitHub Copilot、Codex 和 Replit 的 Agent 场景展示了 MXC 如何支持要求严苛的开发者工作流。编程 Agent 需要访问项目代码仓库、开发工具和完成任务所需的命令，但不应自动获得对无关文件或网络目标的访问权限。MXC 在保留 Agent 所需能力的同时，也对系统其余部分实施了清晰的边界。
通过这篇文章，了解 GitHub Copilot 如何使用 MXC 实现沙箱化执行。
开始使用并分享反馈
通过将隔离、身份和可管理性内置于平台，Windows 帮助 Agent 更安全地运行，同时让开发者和 IT 团队能够控制它们可以访问和执行的内容。
随着我们扩展隔离后端、策略编写、可管理性、可观测性以及更多受支持的容器场景，MXC 仍在持续改进。
您现在就可以通过 MXC 代码库中的 MXC SDK、配置架构、文档和示例开始使用。如果您遇到意外行为，或有改善体验的想法，请在 GitHub 上提交 issue，共同塑造下一步的发展。
English / 原文
Agents are unlocking enormous productivity gains for customers, but their ability to work across files, networks, and applications can introduce new security risks. This can leave customers feeling like they only have two choices: give agents unrestricted access and hope nothing goes wrong or block them and lose the productivity benefits they provide. Neither option is acceptable.
That’s why we’re building Windows platform capabilities to help run and manage agents more securely, starting with:
- Containment : limiting what an agent can access and do.
- Identity : distinguishing an agent’s activity from a person.
- Manageability : giving organizations the tools to govern access and monitor agent activity.
Microsoft Execution Containers (MXC) , now generally available, provides the containment layer. Developers and IT administrators define the resources, like files and network destinations an agent can use and MXC uses the appropriate container to enforce those policies at runtime.
Windows will also soon enable Microsoft Entra to help distinguish agent activity from user activity, ensuring users can remain productive even when agent access needs restrictions and extend Microsoft Agent 365 controls to local agents on-device, enabling IT teams to manage MXC containers, apply policies, and monitor agent activity.
Why agents need a managed execution boundary
An agent cannot be its own security authority. It must run within a boundary defined by the developer or organization and enforced independently of the agent itself.
Consider a coding agent asked to update a website. The agent needs read and write access to the website repository and access to the development tools required to build and test the change. It may need to read production server configuration to understand how the application is deployed, but it should not be able to modify that configuration.
Without a managed execution boundary, the agent may decide that changing the server configuration is the fastest way to complete the task and potentially break the production site. The action can be reasonable from the agent’s perspective and still exceed the authority the developer intended to grant.
Containment creates that managed boundary: the agent can read and write the repository, read the server configuration, but is not authorized to access anything else unless access has been granted. If the agent attempts to modify the server configuration, the containment environment is designed to prevent the operation regardless of what the model, generated code, plugin, or tool decides to do.
What is Microsoft Execution Containers (MXC)?
Microsoft Execution Containers (MXC) is a policy-driven execution layer for untrusted code or dynamically generated workloads. In agentic scenarios, developers can use MXC to contain model-generated output, plugins, tools, agent harness, or the entire agent. This limits what the agent workload can access by containing the scope of the impact if something goes wrong.
Developers declare the resources a workload requires, such as files and network destinations, and MXC enforces the resulting boundary with the appropriate container. The policy remains outside the agent workload’s control, so the agent or generated code cannot grant itself additional access.
MXC also separates workload requirements from platform-specific containment details, greatly simplifying the developer experience. Developers integrate with a unified JSON configuration schema and multi-language SDK, while MXC maps the requested controls to the selected backends on Windows, macOS, or Linux.
Developers can apply the same containment model wherever an agent needs to run – from a local device to the cloud. With Windows 365 support for MXC now generally available, developers can run agents alongside their existing work on Cloud PCs, using the right isolation model to help keep agent execution separate and secure.
Choose the containment level that fits the workload
Different workloads require different levels of isolation. A coding agent working in a repository may prioritize low latency and responsiveness, while an agent processing sensitive data or running untrusted code may require stronger isolation. MXC provides a spectrum of containment options so developers and organizations can select the right level of isolation for each workload.
Only Windows supports a session container, which runs an agent on the user’s device in a separate, OS-isolated session with its own local agent identity and isolated desktop, clipboard, UI, and input boundaries.
| Backend | Availability | Best suited for | Important characteristics |
|---|---|---|---|
| Process container | Windows 11, macOS, and Linux | Lightweight containment for responsive workloads, including model-generated code and tool execution. | Uses the platform-appropriate process sandbox, including AppContainer on Windows, Seatbelt on macOS, and Bubblewrap on Linux. |
| Session container | Windows 11 only | Long-running agents and automation that need a desktop or stronger separation from the interactive user. | Runs under a distinct Windows account and session, separating the agent’s desktop, clipboard, UI, input, and active session from the user. |
| WSL container (WSLc) | Windows 11 only | Linux-first agent toolchains and workloads that depend on the Linux package and development ecosystem. | Provides a Linux execution environment through WSL. |
| MicroVM | Windows 11 and Linux, experimental | Higher-risk workloads that benefit from a hardware-backed virtualized boundary. | Provides hardware-enforced isolation and full Linux workload compatibility. |
Each containment backend has distinct security properties and workloads should be evaluated for fit with containment backend.
How MXC policy defines workload boundaries
MXC helps users and organizations delegate more work to agents while limiting them to the resources required for each task. Instead of giving an agent the full authority of the signed-in user, developers and IT can define an OS-enforced boundary around the agent’s workload.
For the website scenario, an MXC policy could give a coding agent read and write access to its local source-code repository and access to required development tools such as Git, while preventing access to personal locations such as the user’s Documents folder. The policy could also block inbound and outbound network connections and access to the interactive desktop.
| Policy area | What it controls |
|---|---|
| Containment | The isolation environment in which the workload runs, such as a process or session container. |
| Process | The command, arguments, working directory, environment, and other settings used to start the workload. |
| File system | Locations the workload can modify, locations it can read without changing, and locations it cannot access. |
| Network | Inbound and outbound connectivity, including whether the workload can connect to services through the host’s loopback interface. |
| User interface | Whether the workload can access or interact with the desktop and related UI resources. |
Adding MXC support is straightforward for agent developers – you can easily use your favorite coding agent to integrate the MXC SDK and draft an initial workload policy, then review, test, and refine the resulting controls.
How workload and organizational policy work together
Agent developers declare the resources their agentic workloads may need. Organizations can also apply additional constraints through management policy, like with Microsoft Intune management policy. This allows the same agent to operate within different enterprise boundaries without requiring the agent developer to encode the organization’s security posture into the application.
Containment becomes more valuable when organizations can apply it consistently. Intune policy will soon be available to manage MXC process containers used by MXC-integrated agents on Windows 11. These policies will offer IT administrators control over how Windows evaluates container creation requests made by agents, and the resource boundaries that are enforced by those containers.
Agent developers should design their workloads to operate within boundaries that may be more restrictive than the default configuration. If organizational policy blocks a resource, the agent should explain that the task could not be completed within the available permissions, request an appropriate user or administrator action when supported, or choose a safe alternative. It should not silently fail.
Observe and refine policy before enforcing it
Writing a least privilege policy can be difficult when you do not yet know every resource an agent workload requires. Only on Windows, MXC process containers can produce an agent activity report showing which resources a workload attempted to use to help craft a least-privilege policy.
MXC supports three operating modes:
| Mode | Ungranted access | Activity Report | Intended use |
|---|---|---|---|
| Enforcement | Blocked | No | Run the workload with its production policy |
| Learning | Blocked and recorded | Yes | Diagnose failures and verify that the policy grants only required access |
| Permissive | Allowed and recorded | Yes | Observe agent activity without enforcing policy |
In Enforcement mode, MXC applies the policy without activity report. Granted operations proceed, and operations outside the boundary are restricted.
In Learning mode, MXC continues to enforce the configured boundary. An operation that has not been granted is blocked and recorded in a JSON activity report. This lets developers or IT reproduce containment failures and understand which resources the workload attempted to access.
In Permissive mode, MXC records access that the policy would have denied but allows the operation to continue. This is useful during policy authoring because the workload can be completed while developers or IT collect evidence about the resources it uses. Permissive mode does not bypass other applicable operating system or organizational restrictions.
When you bring an agent into an MXC container for the first time, the policy may block capabilities that the workload legitimately needs. These denials reveal where the boundary needs adjustment, helping you grant the required access without unnecessarily expanding the agent’s reach.
Agent identity & attribution
Containment answers what an agent may do. Identity helps determine which agent performed an action. Coming soon, Windows will allow Microsoft Entra to distinguish agent activity from user activity in Microsoft Agent 365.
This separation will allow security teams to evaluate an agent’s behavior and risk independently from the person using the device. If an agent becomes compromised or violates policy, security controls will target the agent’s access to protected resources without blocking the employee’s access. As organizations deploy more agents, one misbehaving agent does not have to interrupt the employee’s access or productivity.
Agent-level attribution also improves investigation and governance. Administrators will be able to use Agent 365 to understand which agents are running, associate activity with a specific agent, investigate risky behavior, and apply policy to individual agents or groups of agents instead of relying only on user-level or device-level context.
Agents using MXC today
NVIDIA has integrated OpenShell into MXC, complementing MXC with policy controls for agent access to files and inference services; advanced network controls; credential management, and for enterprises, OCSF auditing.
Leading agents and agent frameworks already support MXC, including GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio, and Unsloth AI. Many others will be releasing support for MXC: Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast, and Simular amongst others. For people using AI every day, these safeguards are part of the agent experience itself, giving users a more secure way to work with these tools.
GitHub Copilot, Codex, and Replit agent scenarios demonstrate how MXC supports a demanding developer workflow. A coding agent needs access to the project repository, development tools, and commands required to complete a task, but it should not automatically gain access to unrelated files or network destinations. MXC preserves the capabilities the agent needs while enforcing clear boundaries around the rest of the system.
Learn more about how GitHub Copilot uses MXC for sandboxed execution in this .
Get started and share feedback
With containment, identity, and manageability built into the platform, Windows helps agents run more securely while giving developers and IT control over what they can access and do.
MXC continues to improve as we expand containment backends, policy authoring, manageability, observability, and more supported scenarios in the containers.
You can get started today with the MXC SDK, configuration schema, documentation, and samples in the MXC repository. If you encounter unexpected behavior or have ideas for improving the experience, open an issue on GitHub and help shape what comes next.