The report
On October 7, 2026, Microsoft declared Microsoft Execution Containers (MXC) generally available. The announced product is an execution policy layer for agent workloads, not a new model-side instruction or a general promise that sandboxed code cannot misbehave. A developer declares resources that the workload is allowed to use, and the selected operating-system backend is intended to enforce file, process, network and interface restrictions outside the model's authority.
What is available. The vendor documents process containers across Windows 11, macOS and Linux, using AppContainer, Seatbelt and Bubblewrap respectively. Windows 11 additionally supports separate-session containers and WSL containers. The microVM option is explicitly experimental; it is not presented as universally production-ready. Backends have different security properties, so a policy design still needs testing on its target platform.
The mode distinction is material. MXC Enforcement blocks policy-denied operations without an activity report. Learning blocks and records denied operations, which is appropriate for diagnosing a restrictive policy. Permissive records operations that would have been denied but allows them to continue. A successful run in Permissive mode therefore cannot be cited as proof that an access rule was enforced. Microsoft's Windows-only activity reports are not a universal cross-platform audit contract.
Repository-level warning and technical scope. Microsoft's current MXC README explicitly warns that --audit disables MXC sandbox protection during that run; it is a policy-authoring diagnostic, not a safe mode for executing untrusted code. The learning-mode implementation guidance is more specific than the release announcement: its learningModeLogging path denies and logs ungranted access, whereas permissiveLearningMode allows and logs it; those mechanisms concern Windows AppContainer-based process backends. This source-specific distinction must not be read as proof of identical telemetry or security enforcement for every backend or third-party integration.
The deployment boundary includes environment configuration and outbound network permissions, not merely read/write access to source files. For contrast, the separate mini-swe-agent Bubblewrap environment case shows why a file-restricted shell can still inherit runner secrets and retain network access. That CVE is not an MXC vulnerability, and the Microsoft announcement is not evidence that MXC or any named downstream integration fixes mini-swe-agent; it illustrates the specific boundary each implementer must check.
Not yet delivered as general features. Microsoft's announcement describes forthcoming agent identity through Entra and forthcoming Intune management for Windows 11 MXC process containers. Treat these as roadmap statements rather than active controls in a deployment. The announcement and vendor integration list do not independently demonstrate equivalent policy enforcement across every backend or agent harness.
A concrete policy review before deployment
A coding agent authorized to edit a website should have a narrow, testable contract: write to that repository; read the deployment configuration if needed; do not modify that configuration, open unrelated user files, contact arbitrary network endpoints or manipulate the interactive desktop. The vendor's example distinguishes read permission from write permission. It also means an instruction found in a README, issue description or generated tool output cannot legitimately extend the agent's authority. The permission decision belongs to the launcher and OS enforcement layer, not to the agent's explanation of why an exception is convenient. This is a recommended review procedure, not a claim that DiggingBeagle performed an MXC penetration test.
For each specific build, platform, backend and configuration, a reviewer should record an allow case and a deny case for each relevant boundary:
- Files and subprocesses: confirm expected repository edits work, while attempts to change read-only deployment configuration or read a synthetic credential outside permitted paths fail. Repeat through tools and child processes, not only the agent's top-level command.
- Environment and credentials: use a harmless synthetic marker to check what variables a launched process receives, then document whether secret injection, credential brokering and environment sanitization are implemented by MXC configuration or by a separate launcher. A filesystem rule alone cannot establish the answer.
- Network: exercise an explicitly permitted destination alongside an unrelated internet host and a loopback or private-network address. Check redirects and name-resolution changes where the chosen backend and networking layer support them. Record observed denied connections rather than inferring denial from a model refusal.
- UI and host state: on the applicable backend, test that access to user-interface resources and unrelated host directories follows the written policy. Windows separate-session isolation cannot be assumed for Linux or macOS process backends.
Reading the results correctly
Run deny tests in Enforcement or, on supported Windows process containers, Learning mode. Verify actual operating-system failures, not just an absence of suspicious model text. Learning adds denied-access evidence while preserving the block. Permissive mode, and the repository's --audit workflow that explicitly turns off sandbox security, serve policy discovery rather than the proof of containment. A completed task in either observational mode establishes what the workload attempted under that mode; it does not establish which operations the production boundary would have stopped.
Policy reviews also need change control. Keep the exact rule set, executable and backend version together with the test result, and require a separately authorized adjustment when a legitimate task encounters a denial. Otherwise repeated 'make the agent work' exceptions can turn a nominally sandboxed workflow into broad host access. This is an engineering recommendation based on the described trust boundary; Microsoft has not published an independent all-backend test result in the cited announcement.