The Sandbox Moved Into the Operating System

For a year, running an agent safely meant building the cage yourself out of microVMs, seccomp, and read-only mounts.

Microsoft Execution Containers push that boundary down into Windows itself, so you declare what an agent can touch instead of engineering the wall.

The wall becoming a platform feature does not move the hard part, which is deciding the policy, and that part is still yours.

At Build 2026 on June 2, Microsoft announced Microsoft Execution Containers, or MXC, an operating-system-level sandbox for AI agents. OpenAI and Nvidia are already named as partners, GitHub Copilot CLI has adopted its lightest isolation mode, and it enters public preview this month on Windows 11 Enterprise 24H2 and later, plus Windows Server 2026.

I want to talk about why this matters, and then about what it quietly does not solve, because the gap between those two things is where teams will get hurt.

What people have been doing instead

If you have run an autonomous coding agent on anything that matters, you already know the problem. The agent generates code and then runs it. That second step is the dangerous one. A model that hallucinates a rm -rf or pip-installs a typosquatted package will execute it with whatever permissions you handed the process.

So for the last year the answer has been do-it-yourself isolation. Spin the agent up in a microVM with its own kernel. Wrap it in gVisor. Apply Linux Landlock and Seccomp profiles, or Seatbelt on macOS. Mount only the project directory, never the home directory. Run as a non-root user with network egress filtering and a hard timeout on every task. Vendors like Modal, E2B, and Northflank turned this into a product because enough teams needed it and did not want to maintain the plumbing.

That stack works. It is also a lot of plumbing to own, and most teams build it slightly wrong the first time. The home directory gets mounted by accident. The timeout is missing on one code path. Egress filtering covers HTTP but not DNS. The cage has gaps because the cage was hand-welded.

What MXC actually changes

MXC moves the boundary into the OS and gives you a single policy model with three levels of containment.

Process isolation is the light one. It runs model-generated code inside a dedicated process boundary that restricts which files and network domains the code can reach. This is what GitHub Copilot CLI adopted, to constrain what dynamically generated code is allowed to do. It is fast because it leans on existing Windows primitives, AppContainer isolation, capability-based access, and integrity levels, rather than booting a whole operating system.

Session isolation is the middle one. It separates the agent from your actual desktop: the interactive session, the clipboard, the UI, the input devices. The agent runs under a distinct user account with its own identity, either a local ID or a cloud-provisioned one backed by Entra. This is the level that stops an agent from quietly reading your clipboard or driving your mouse.

Micro-VM is the heavy one, hardware-backed isolation through the hypervisor for higher-risk work on sensitive data.

The part that matters more than the three levels is how you choose between them. You declare access policy, files and networking, through Entra and Intune, and Windows enforces it at runtime. You are no longer writing the enforcement. You are writing the intent and letting the OS hold the line.

That is a real improvement. Enforcement built into the operating system is harder to get subtly wrong than a Seccomp profile someone copied from a blog post in 2024.

What it does not do

Here is the part the launch posts skip.

MXC does not decide what your agent should be allowed to touch. It enforces the policy. You still write the policy. If you grant an agent broad file access and open network egress because narrowing it felt like too much work, the OS will faithfully enforce your bad decision. The cage is now well built, but you still choose how big it is and what goes in it.

This is the same trap I keep seeing with every layer of agent tooling. A capable platform feature arrives, and people treat it as a substitute for thinking instead of a place to put their thinking. An OS-level sandbox with a wide-open policy is a locked door with the key taped to the frame.

It is also Windows and WSL only. If your agents run on Linux in production, which most do, MXC is not your answer this quarter. The microVM and Landlock stack is still the job, and the vendors who sell it are not going anywhere. What MXC signals is direction. Isolation is moving from something you assemble to something the platform provides, and the Linux ecosystem will follow the same path because the demand is identical.

And public preview means public preview. This is not the layer to trust blindly with your most sensitive workload in June. Treat it as a strong new option to test, not a finished foundation to bet the company on.

The part that stays human

Strip away the product names and the shape is familiar. The platform got better at the mechanical work, executing the boundary, and the judgment work stayed exactly where it was.

Deciding what an agent may read, where it may send data, and how much blast radius a mistake is allowed to have is a security decision, not a configuration default. It is the same job whether you express it as a Landlock profile, a Northflank config, or an Intune policy. You set the limit. The tool holds it.

So the practical move, even if you never touch Windows, is to write the policy as if you had to hand it to an enforcement engine tomorrow. Name the exact directories. Name the exact domains. Set the timeout on every path, not most of them. Assume the agent will do the worst legal thing your policy permits, because eventually one will.

MXC is a good development. It takes a fragile, hand-built wall and makes it a platform guarantee. Just remember that a stronger wall around a careless boundary is still a careless boundary. The operating system can now hold the line. Where you draw it is still on you.