Buried in the README of Microsoft's new agent sandboxing project is a sentence that no one writing about it seems to have quoted: "no MXC profiles should be treated as security boundaries currently" [1].
That is the maintainers of the project, in their own repository, telling you the thing does not yet do what almost every article about it says it does. Microsoft Execution Containers has been covered as operating-system-level containment for AI agents, the answer to the question of what stops a model from reading your SSH keys when it decides a shell command is a good idea. The repository says it is not that answer yet. Both statements are live on the internet right now, and only one of them was written by the people who know.
What the coverage said
The framing arrived with the June announcement. Dana Huang and Logan Iyer, both corporate vice presidents at Microsoft, published a piece arguing that agent autonomy needs containment, identity, and manageability built into the platform rather than bolted on by each application [2]. The strongest line in it is a promise: "Windows reduces the attack surface and raises the security baseline by default, so agents inherit that protection without additional work" [2].
Trade coverage compressed that further. Help Net Security ran it under the headline "Microsoft wants to keep your AI agents from going rogue," describing a world where developers "define constraints for their applications and agents, and Windows enforces them at runtime through MXC" [3]. Nothing in that article is false. It also never mentions that the profiles are not security boundaries, because the announcement blog it was working from does not say so either.
This is how a caveat dies. It lives in the repository, where the engineers put it. It does not survive the trip to the announcement post, and by the second hop it has been replaced by a headline verb. The word "enforces" is doing enormous work in that sentence, and the people who wrote the enforcement code have publicly asked you not to trust it yet.
What MXC actually is
Strip the framing away and the project is genuinely interesting. MXC stands for Microsoft eXecution Container, and the repository describes it as "a sandboxed code execution system for running untrusted code (model output, plugins, tools) on Windows, Linux, and macOS" [1]. It is written in Rust, MIT licensed, and it does something the agent ecosystem badly needs: it puts one JSON schema and one TypeScript SDK in front of a pile of incompatible operating-system isolation primitives.
The policy surface is small enough to hold in your head. Filesystem policy is two lists, read-only paths and read-write paths. Network policy covers proxy configuration, an outbound allow or block switch, and host filtering whose behaviour depends on which backend you picked. UI policy governs clipboard, display, and GUI access [1]. A lifecycle runs provision, start, exec, stop, deprovision, so a sandbox can be a long-lived thing rather than a one-shot process.
That abstraction is the real product. Writing correct Seatbelt profiles on macOS, correct Bubblewrap invocations on Linux, and correct AppContainer configuration on Windows is three separate specialities, and almost nobody building an agent harness has all three. A unified schema that degrades sensibly across platforms is worth having even in an incomplete state.
The project is also alive, which matters. The repository was created on 6 February 2026 and was still receiving pushes on 8 September, with the most recent commit on 4 September referencing pull request number 820 [4]. This is not an abandoned announcement artifact. It is an active engineering effort in public.
The stability matrix is the story
Read the backend table and the picture sharpens considerably.
On Windows 11 24H2 and later, the default backend is processcontainer, and it is stable. The alternatives are windows_sandbox, wslc, microvm, hyperlight, and isolation_session, and every one of them is experimental. On Linux, bubblewrap is the stable default and lxc is stable alongside it, while microvm and hyperlight are again experimental. On macOS there is seatbelt and nothing else [1]. Using any experimental backend requires passing { experimental: true } in the spawn options or --experimental on the command line, which is an honest gate.
Now line that up against what the announcement promised. Micro-VM containment, the hardware-backed hypervisor isolation that would make MXC a real boundary rather than a policy layer, is described in Microsoft's own blog as roadmap, not shipping [2]. Session isolation, the mode that separates an agent from your desktop, clipboard, and input devices, is on the experimental list. What is stable today is process-level containment: a policy applied to a process on the machine the agent is already running on.
Process containment is useful. It is not the same category of protection as a virtual machine, and the difference matters precisely in the scenario everyone is worried about, which is a capable model deliberately trying to get out. Microsoft has been clear about this in the places engineers read. The compression happened everywhere else.
All three published releases reinforce the point. v0.6.1 in June, v0.7.0-rc1 in June, and v0.8.0 on 22 August are marked prerelease, every one of them [4]. The quickstart in the README pins the config schema at version 0.6.0-alpha [1]. Nothing about this project's own versioning claims to be finished, and 118 open issues sit on the tracker [4].
The flag that turns enforcement off
There is a second warning in that README, and it is the one with real operational teeth. The --audit flag, it says, "injects permissiveLearningMode", and under it "AppContainer restrictions are not enforced for the duration of the run. Use only for policy authoring" [1].
Sit with the shape of that for a moment. The workflow for writing an MXC policy is to run your agent under --audit, watch what it touches, and generate a profile from the observed behaviour. During that run, the restrictions are off. You are learning what an unconstrained agent does by letting it be unconstrained.
For policy authoring against code you trust, that is the correct design and there is no other way to build a learning mode. The failure case is a team that discovers --audit produces fewer mysterious permission errors, leaves it in a script, and ships it. The flag name says audit, which sounds like something you would want in production. Nothing in the word warns you that it disables the control you installed the SDK to get.
This is the same defect class the site has covered before in a different costume: a mechanism whose logging or naming implies a guarantee it is not making. If you are evaluating MXC, grep your own repository for --audit and permissiveLearningMode before you grep for anything else.
The maintainers also flag that the generated policies themselves lean loose: "There are known cases where the current policies generated by the MXC SDK in this repository are overly permissive and will be addressed before this is made more generally available" [1]. A permissive policy plus a permissive authoring mode is not a boundary. It is a draft.
The fair objection
The obvious pushback is that this is an early preview, it says so in the first line of its own warning block, and criticising alpha software for being alpha is cheap. That objection is right, and it is the reason this article is not an attack on MXC.
Microsoft did the honourable thing. They shipped the code publicly, labelled the maturity precisely, named the specific weakness in their own policy generator, gated the experimental backends behind an explicit flag, and invited security researchers in while it matures [1]. That is better disclosure than most infrastructure ships with, and the project deserves to be used and stress-tested on exactly those terms.
The problem is not the repository. The problem is that the repository's honesty does not travel. A developer who reads the README gets an accurate picture in about ninety seconds. A developer who reads the announcement gets a partial one. A developer who reads the trade coverage gets a headline that says Microsoft stops agents from going rogue, and no signal at all that the maintainers disagree.
What to do with it today
Treat MXC as a policy authoring and defence-in-depth layer, not as the thing standing between a hostile agent and your filesystem. Use it to make accidents smaller: a model that hallucinates a path, a tool that writes outside its working directory, a plugin that reaches for the network when it had no business doing so. That is most of the real incident volume, and process containment handles it well.
Do not use it as the sole control for code you actually consider adversarial. For that, the boundary still has to be a virtual machine, a separate host, or a container with no credentials worth stealing, exactly as it was before this SDK existed. Keep the stable default backend, keep --experimental out of production, and put --audit behind the same review you would give any flag that disables a security control, because that is what it is.
And build the habit that makes all of this cheap. The README took ninety seconds to read and contradicted three months of coverage. That ratio has held on every infrastructure story worth writing about: the primary document is short, public, free, and almost nobody opens it.
The maintainers already told you what MXC is not. Everything after that is on the reader.
References
[1] Microsoft — microsoft/mxc: Policy-driven, layered isolation and containment. Documentation
[2] Dana Huang and Logan Iyer, Microsoft — Windows platform security for AI agents. Blog
[3] Anamarija Pogorelec, Help Net Security — Microsoft wants to keep your AI agents from going rogue. Article
[4] GitHub REST API — microsoft/mxc repository metadata (GitHub REST API). Documentation