One of the problems facing those who develop agents today, especially when building agents that run on edge systems with a mix of local and cloud AI, is trust: ensuring that the code that runs on users’ PCs doesn’t access private data or call unexpected APIs. How can we keep systems that don’t have predictable operations under control, when it’s that very unpredictability we’re relying on, as they orchestrate calls across local and remote systems, building and running workflows on the fly.
If you worked on agents the first time around, back in the 1990s, when they were tools designed to manage and run long workflows for users, you’ll recognize the problem. After all, the security risks associated with delivering arbitrary code to PCs and servers were what blocked those first agents from wide adoption (that and the complexity of building and sharing the necessary runtimes). Computer systems have evolved considerably over those decades, especially with the arrival of hardware support for virtualization, a technology that Microsoft has built into much of its modern platform. Hardware virtualization is key to technologies like secure containers, to Windows’ own internal isolation model for critical OS components, and to cross-platform tooling like the Windows Subsystem for Linux. New tools like the WSL container platform have begun to extend that virtualization model with SDKs that allow programs to launch and control the virtualization life cycle.
Virtualization also underpins Microsoft’s approach to building a trustworthy framework for agent operations, allowing them to operate in a secure manner by isolating their operations from the operating system as a whole, locking down access to functionality and running them in secure containers and microVMs. With agents working autonomously, it’s essential to keep them isolated from desktop systems, giving them access only to the services they need — as examples of badly configured agents with overly broad prompts deleting files have shown.
Developers need tools to manage that isolation, allowing them to develop code in a permissive environment, before shipping locked-down applications that operate with policy-based restrictions. This approach needs tooling to build and manage those restrictions, providing a framework based on managed, isolated containers. This is where Microsoft Execution Containers (MXC) come into play.
Intended to be cross-platform, MXC offers Windows, macOS, and Linux controls, working with more than one virtualization framework. The tooling is designed to offer a common abstraction layer, so you only need to build policies once before delivering them to all supported operating systems and virtualization environments. By using policies to control payloads, MXC can provide different levels of control for different workloads. An agent that’s designed to provide personalized search will need fewer guardrails than an OpenClaw-like system that’s being set up as an agentic personal assistant with full access to your data and applications.
An early adopter of MXC is GitHub Copilot. Here a single command in any CLI session (once you have enabled experimental mode) switches you into sandboxed mode with limited access to your file system (locking it down to your PATH
, your working directory, Windows temp folders, and your profile), with outbound-only connectivity. There is a config option that allows you to open more directories if you need wider access, but the out-the-box guardrails should help reduce risks to your code from out-of-control agents.
MXC is an open-source project, written in Rust, with the project hosted on GitHub. It’s configured using JSON and provided with a set of TypeScript SDKs that help manage the sandbox life cycle, which is defined as a set of steps: provision, start, execute, stop, de-provision. Sandboxes can be run as “one-shot” (a single execution) or as part of a long workflow to support the local elements of a business process.
Getting started requires a Rust tool chain and a recent build of Node.js, along with npm. Although regular releases do include binaries, it’s still best to clone the MXC repository and build it yourself. (Release source code is available, but working with the repository keeps you up-to-date with the latest changes.) The latest release, MXC 0.8.0, offers the most up-to-date set of policies, which are essential for managing the sandbox guardrails used to corral agents. It also improves networking support, with better security and improved tooling for delivering policies across different sandbox environments.
It’s a good idea to spend some time understanding the MXC policy schema. This is where you learn what MXC can do and what it can’t. It’s important to understand that MXC cannot provide more isolation than you get from a locked-down virtual environment, and that it can’t switch virtualization endpoints on the fly. The schema documentation shows the principles that are used by MXC’s development team. For example, they indicate that policies are an expression of intent, that the enforcement mechanisms are implemented in the tooling, and that the default position on any policy is “deny.” Thus, users need only define the policies they want to have a more permissive approach, as having no policy definition is by default an opt out.
Further, the tooling is designed to be cross-platform. You need only define policies once, and the Windows, macOS, and Linux versions of MXC will implement them on a target sandbox. How they are enforced will differ among the platforms and sandboxes, but whatever MXC does, it is driven by user intent. Putting the user requirements first is key, as the purpose of MXC is to provide a way for users to trust agents and to know that agents won’t run amuck and destroy data.
If you’re using MXC to develop agents and you want to tune the rules it uses, you can run MXC in audit and learning modes. This allows operations that would otherwise be blocked; instead of denying the operations, it logs them along with other operations, allowing you to tune your policies to actual agent behavior. Of course, it’s a good idea to run audit and learning modes on a virtual machine, or on a scratch test install, to ensure that your development systems are not impacted by an uncontrolled agent. Once you have written a JSON policy, you can either use it either to spawn and run a sandbox directly or to generate a sandbox-specific configuration file that can be used with multiple sandboxes. If you take the latter approach, you can edit the generated configuration JSON and use it to launch sandboxes programmatically. It’s important to note that whichever approach you take, MXC lets you avoid working with kernel-level tools to manage hypervisors and their associated networking.
Interestingly, one of the supported isolation environments is Windows Sandbox (WSB). While this lightweight desktop sandbox is often used as a development tool, it can be configured to launch with managed access to defined selections of the host Windows file system. Although the applications you want to run in a WSB sandbox must be installed explicitly, it’s easy to imagine an MXC-managed agent using Windows Sandbox with a set of scripts to install a pre-defined set of applications, with mapped read-only access to a subset of the host’s files. The agent could then use its own APIs and local Model Context Protocol (MCP) servers to work with local data in the background of a user’s own sessions, treating the agent as a user’s “shadow.”
Finally, there’s even scope for working with microVMs that host single-process applications and microkernel-like environments, using technologies like Hyperlight to host agents and other high-risk applications, with MXC providing additional isolation. This approach allows a low-risk agent orchestrator to launch higher-risk agents as needed, without compromising overall security.
By using microVMs, you’re able to manage resources more effectively, running a dense network of secure agents with the same resources as another VM might use for one agent. It’s an approach that allows you to conserve resources by spinning up and tearing down microVMs as needed, something that will be useful in constrained edge environments.
Microsoft also is using MXC in conjunction with its cloud-based virtual PC environments, improving isolation and protection in its Windows 365 for Agents Cloud PCs. Here you can pre-configure virtual environments where agents can operate without affecting users’ systems, by working with cloud replicas of local systems that can be reset in the event of sandbox escapes or other failures.
MXC is still a very young project, and the final release is likely to differ considerably from the current preview release, as both the code and its supported sandboxes evolve. For now, though, MXC is well worth investigating as a way of securing agents that run on edge endpoints as well as agents that run in your own workflows, using tools like the ones built into GitHub Copilot.