Microsoft MXC turns agent sandboxing into a policy teams can review

The short version

AI agents can write and run code. That is useful, but it also gives a model-generated mistake a path to files, credentials and the network. A sandbox is an isolated place where that code can run with fewer ways to affect the host system.

On X on October 8, developer Simon Willison highlighted Microsoft's new open-source, cross-platform sandbox library. The Microsoft eXecution Container project, or MXC, presents one software interface for Windows, Linux and macOS. An application supplies a command and a policy. MXC selects a platform-specific containment method and runs the workload.

The important change is organizational as much as technical. A shared policy format could give product, security and engineering teams one artifact to review. It does not prove a workload is safe. The quality of the result still depends on the chosen backend, the policy, the host and the test.

The idea in plain terms

Suppose a coding assistant needs to run a test. It may need the current project folder and a package registry. It does not need a password folder, the payroll drive or an open route to every address on the internet.

MXC lets the host application describe that difference. Its current README documents read-only, read-write and denied file paths, plus network and user-interface controls. It also supports several isolation backends. A backend is the operating-system feature or virtual machine that actually enforces the policy. The defaults differ by platform: ProcessContainer on Windows, Bubblewrap on Linux and Seatbelt on macOS.

That common interface is convenient, not magical. The backends do not all provide the same isolation. Some listed options are experimental. A policy that looks identical in a review may meet different host features underneath. Teams should therefore record both the requested policy and the backend that enforced it.

The safest useful starting point is deny by default. That means an action is blocked unless the policy grants it. MXC's documentation says its sandboxes follow this model. It also warns that an audit mode turns off sandbox enforcement while it observes access. That mode may help a developer learn what a trusted program needs, but it should never run untrusted model output.

Where it came from

Willison's post was the discovery signal. We then reviewed the project README and its current learning-mode documentation. Microsoft describes MXC as an SDK dependency that an application embeds, with packages for Rust, .NET and Node. The application chooses the container type, containment rules and command.

The README's sample sets outbound network access to deny and gives the process a 30-second timeout. That is an example, not a claim that the library has been independently shown to stop every escape. We found no evaluation in the reviewed material that compares MXC's security across all supported platforms.

The learning-mode guide makes a useful distinction. One setting records denied access while keeping it blocked. Another records access while allowing it. The latter weakens containment and produces a warning. This distinction matters because a test tool can otherwise become the permission that removes the control being tested.

How it connects to other work

The policy model fits established container guidance. NIST Special Publication 800-190 treats container security as a set of risks across images, registries, orchestrators, containers and hosts. A sandbox does not remove the need to secure the code and system around it.

The OWASP AI Agent Security Cheat Sheet recommends minimum tool access and structured testing before production and after material changes. MXC could help enforce part of that advice at execution time. It does not decide which business action an agent should be allowed to take through an API.

Our added recommendation is a two-column review. In the first column, list the requested controls: readable paths, writable paths, network destinations, interface access and time limit. In the second, capture observed enforcement on each supported host. Run one allowed action and one prohibited action for every important rule. Keep the result with the application release.

This turns a sandbox configuration into evidence that a reviewer can question. It also exposes drift. If a new operating-system build or backend changes behavior, the same negative tests can fail before the application reaches users.

Open questions

How comparable are the platform backends? The current README names their defaults and supported options, but a shared API does not establish equal resistance to escape. Organizations with high-value data may still prefer a stronger virtual-machine boundary for untrusted code.

Which controls fail closed? If a requested feature is unavailable, the safe outcome is to stop the run rather than silently relax the policy. Teams should verify this behavior for every backend and host version they deploy. We have not reproduced it independently.

How will packages and model tools reach the network? A broad network exception can undo much of the value of file isolation by allowing data to leave. A narrow allow-list can also break ordinary builds. That tradeoff needs product decisions and realistic tests, not a copied sample policy.

What this means for your work

For business and technology leaders

A sandbox should be required when an agent runs code. Do not accept the feature name as proof. For example, a support team may let an agent test a script on a sample project. The agent should not be able to reach customer exports or cloud passwords. We recommend asking the owner to show the access rules and one blocked-action test on each operating system. This week, add both items to the pilot checklist. Name the person who must approve any exception.

For full-stack developers

Treat the sandbox rules like application code. For a coding agent, share only the current project. Block password folders and start with internet access off. We recommend adding tests for one allowed file change, one blocked password read and one blocked network call. Use the same path that runs real agent code. Run the tests on each system you support. If you use MXC audit mode to find needed files, use trusted code only. Turn the sandbox back on before the blocked-action tests.

Sources

• New open-source cross-platform sandboxing library from Microsoft — Simon Willison, X, October 8, 2026; captured in the bounded intake.
• Microsoft eXecution Container — Microsoft, GitHub repository and README, reviewed October 12, 2026.
• Learning-mode capabilities — Microsoft, project documentation, reviewed October 12, 2026.
• Application Container Security Guide — NIST, Special Publication 800-190, September 2017.
• AI Agent Security Cheat Sheet — OWASP Cheat Sheet Series, reviewed October 12, 2026.