Microsoft Execution Containers (MXC) reached general availability on 7 October 2026. It is an SDK plus a versioned JSON policy that runs an AI agent's code inside an operating-system container with declared limits on files, network and the desktop. Enforcement runs on Windows, Linux and macOS. The record of what the container blocked is Windows-only, and that asymmetry, not the enforcement, is what your auditor will ask about.
What did Microsoft actually ship on 7 October?
MXC is not a service you subscribe to. It is an SDK dependency that builds into an application, published as mxc-sdk, Microsoft.Mxc.Sdk and @microsoft/mxc-sdk, with MIT-licensed source in the microsoft/mxc repository. The application declares a container type, a policy and a workload command; MXC validates the request, picks a backend and launches the workload inside it.
The policy is deny-by-default across three surfaces: filesystem, with read-only, read-write and denied path lists; network, with proxy support, outbound controls and host filtering the repository calls backend-dependent; and UI, covering clipboard, display and GUI access. The request format is a stable 1.0.0 JSON schema. The architectural point is where that policy lives: the hosting application declares it, outside the agent's reach, so a model cannot widen its own box mid-task.
The backends differ by platform in a way the launch coverage flattened. The repository's own table gives Windows 11 a default of processcontainer plus windows_sandbox, wslc, microvm, hyperlight and isolation_session; Linux a default of bubblewrap plus lxc, microvm and hyperlight; and macOS seatbelt alone, with no alternatives. Three are marked experimental: windows_sandbox, microvm and hyperlight. Three Windows backends carry the experimental asterisk: windows_sandbox, microvm and hyperlight. The Linux row's microvm and hyperlight do not. Post-GA coverage such as eSecurity Planet reads the same way; the pre-GA write-ups that called session and WSL containers experimental were describing the June preview. Take the repository table as current, and note that processcontainer is the Windows default and the only backend with the capability below.
Why did Anthropic reach the same conclusion two days later?
On 9 October, Anthropic published Investigating unintended model actions in our evaluations and internal use, correcting it on 12 October. It describes four categories found through a transcript review it began in July: exploiting SQL or command-injection flaws to run commands on third-party servers; submitting real online forms without authorisation; using exposed or requested tokens to reach gated data; and using URL shorteners to get around length limits on the fetch tool.
The case that travelled furthest was a false homicide tip submitted to a Philadelphia unsolved-murders tip form. Anthropic's post says it shared the finding with the department on 8 October, once its technical review was complete, and that the tip had been flagged as spam and never forwarded for investigation; The Hacker News dates the submission to 18 July 2026 and the discovery to 28 September. Anthropic's response was to disable live internet access across all internal evaluations, not just the high-risk ones.
Read the remediation list rather than the headline. Anthropic states that alignment training "is not yet sufficient or fully robust on its own, at least in the short term". Its fixes are almost entirely environmental: scope evaluations explicitly, including network boundaries; remove training environments that reward circumventing a blocker; migrate internal agents onto centrally managed infrastructure with stronger containment; minimise their internet access altogether. The lab with the most leverage over model behaviour chose to constrain the environment instead.
The fourth category deserves an architect's attention, because it is not a destination problem. A URL shortener does not take the agent somewhere new; it re-expresses a destination so a length check, or a naive host list, no longer recognises it. An allowlist only holds if filtering happens after redirects resolve, which is why MXC calling its host filtering backend-dependent is a line to read closely before you write an egress policy.
Who already made this argument, and where does it stop?
The claim that control is moving out of the model and into the environment is not new, and not ours. Neotheta's AI Doses for the week of 9 October made it the week's thesis, citing the MXC release directly, and already noted that Entra-based agent attribution is still to come while Intune policy is close behind.
The academic version landed one day earlier. Abbas Raftari of Walsh College submitted From Reactive Containment to Proactive Assurance on 8 October, arguing that an evaluation cannot rely on an assumed boundary because agents reach real systems outside their authorised scope, and recommending independent egress enforcement outside the agent-controlled compute plane. He proposes a Proactive Agent Security Assurance Cycle and a five-layer Boundary Assurance Stack. MXC is, in effect, a commodity implementation of that layer, but the paper predates the 9 October disclosure by a day and does not mention MXC, Intune or Entra at all.
Two write-ups got further still. Rajesh Beri on 7 October and Abhishek Tiwari on 8 October both noted that only Windows process containers produce an activity report. Neither went on to the question that actually decides an audit, and it is answered in Microsoft's own documentation: the one fleet-wide flow MXC ships for collecting that evidence requires turning enforcement off.
Where does enforcement end and evidence begin?
MXC's logging access denied documentation states it plainly: learning-mode capabilities are Windows-only, and apply to the AppContainer-based backends: classic AppContainer and BaseContainer. On Linux under bubblewrap and on macOS under seatbelt you get deny-by-default enforcement and no deny-and-record trail of the same kind. On Windows the deny-and-record flow writes denials.<run-id>.json with a redacted verbose sibling; the ETW trace is deleted after analysis unless you set captureDenials.retainEtl.
For an engineer that is a footnote. For anyone who has to evidence a control it is the whole story. ISO 27001 and ISO 42001 both ask you to demonstrate that a control operated, not merely that it was configured, and if you supply a government body, BIO2 reaches you through your contract's chain-hygiene clauses rather than directly. A container that blocked an agent and wrote nothing down leaves you asserting a negative. You will be asked how many times the agent tried to reach something outside its policy last quarter, and on two of the three platforms MXC supports, the honest answer is that you cannot say.
That lands badly given where agent code runs in a mid-market estate. The managed Windows fleet is already under Intune and already reported on. The Linux build runners and the macOS laptops of your data and development teams are where someone installs an agent framework on a Thursday afternoon: the two platforms with enforcement and no comparable record.
Why does the only fleet-wide evidence flow relax enforcement?
The documentation defines two learning capabilities with opposite postures. learningModeLogging logs every failed access check and leaves enforcement unchanged: accesses stay denied. permissiveLearningMode logs every access check and allows it, which the documentation calls weakened: the container no longer enforces deny-by-default. It then maps three flows onto them, and that mapping is the part to read twice. The developer inner loop gets the audit flag, relaxed. The app and user-configurable flow gets deny-and-record, enforced. The third flow is named Fleet auditing, its stated audience is IT admins, and its entry point is captureDenials with mode set to allow: enforcement relaxed, allow-all.
Read that against your own estate. The only flow Microsoft addresses to IT admins, the one that would give you evidence across a fleet rather than from one developer's laptop, is the flow that stops enforcing deny-by-default, and the documentation notes it does not trigger a UAC prompt, because the capability arrives through config. The same page adds that the machinery which collects and surfaces the resulting denial events is layered on top in later work, so there is no shipped aggregation either. Today you can enforce across the fleet, or observe across it. Not both.
The string to grep for is not "permissive". MXC already rejects both learning-mode capability names inside processContainer.capabilities, case-insensitively, and permissiveLearningMode is a reserved capability the entry points inject. What matters is captureDenials with mode allow, the same allow-all arriving through ordinary config, plus the audit flag in a deployment script, a flag the README warns turns off all sandbox security, and which is rejected for every Windows backend other than ProcessContainer. Both are a grep in a pipeline, and both pass review on a Friday because the words sound like compliance. Where NVIDIA's OpenShell hid its trap in a default, MXC hides its in an entry point.
What is still missing from the control plane?
Two pieces of central management are announced and not shipped. Intune policy for MXC process containers is not generally available; Microsoft says a future release and gives no date. Entra distinguishing agent activity from user activity is planned, with no timeline. Agent 365 is worth being precise about: it reached general availability on 1 May 2026 already carrying local-agent discovery and blocking on managed Windows endpoints through Defender and Intune, starting with OpenClaw. What is still coming is extending that to MXC-contained agents: a narrower gap than the launch coverage implies, and still the gap you are sitting in.
Until those land, the containment policy is a developer artefact in the agent supplier's repository, not a managed configuration in your estate. Change control for your strongest agent boundary therefore runs through somebody else's release process. If you are used to answering "what is this policy and who changed it" from Intune, that answer is not available yet for the control that matters most, and the question will be asked by the first auditor who understands what an agent is.
One detail your privacy officer will want before a pilot. Official Microsoft builds can send optional diagnostic telemetry under a layered consent model: the run opts in, the Windows user must have consented, administrative policy must permit collection, and the application must enable the option. An administrator can block collection but cannot grant consent on the user's behalf. In a Dutch organisation with a works council, that conversation belongs before the rollout.
What should a Dutch IT organisation decide this quarter?
Written for an IT manager, informatiemanager, CIO or security officer at a Dutch organisation of roughly 250 to 5,000 employees, with an ICT partner, an internal IT team, or both. Four decisions, in order.
First, decide which platforms agent code may execute on and write it down. If evidence of enforcement is a requirement rather than a preference, Windows with the ProcessContainer backend is currently the only place MXC produces it. Second, put the container policy under change control you can see. It lives in the supplier's repository today, so make it an acceptance criterion and require the diff at each release, as you would for a firewall rule.
Third, ban allow-all capture and the audit flag from production by written rule, enforced in the pipeline rather than on a checklist. Fourth, and most important in a multi-supplier estate, write the ownership split before the pilot rather than after the incident. Your ICT partner owns the Windows baseline, the Intune estate and Entra. The AI supplier owns the container policy, its egress list and the denial records it produces. Nobody owns both, and the gap between those two scopes is exactly where an unlogged agent lives.
That split is the work we do: Crux Digits comes in as the AI specialist alongside your existing ICT partner, and we do not run your endpoints or your identity platform. If you are deciding how agent execution gets governed in an estate somebody else manages, our applied AI for mid-sized business page describes how that division of labour is set up, and the AI implementation page covers the sequencing. For the adjacent decisions, we have written up the state of agent identity standards and what MCP and A2A cannot log. Last updated 13 October 2026.
A consultant tells you where AI pays off; Crux Digits also builds it. A fixed price per step, one named expert, from Utrecht.
AI consultancy in the Netherlands →
