An agent cannot be its own security authority. Microsoft Execution Containers move the boundary into Windows
Microsoft made Execution Containers generally available: a policy layer, enforced by the operating system, that decides which files, networks and processes an AI agent can touch.
Listen to this article · 6 min
AI-generated narration of the full article.
Most agent security today lives in places the agent can read: the system prompt, the tool descriptions, the application code that wraps the model. That is a little like asking a contractor to write their own building pass. It works until the contractor is confused, manipulated, or simply wrong.
On October 7, Microsoft made Microsoft Execution Containers (MXC) generally available on Windows 11, and the design starts from the opposite assumption: the agent does not get a vote on its own boundary.
What Microsoft shipped
Microsoft describes MXC as a policy-driven execution layer for untrusted code and dynamically generated workloads, which is a fair description of what an AI agent produces when it writes a script and runs it.
- The developer declares what the workload needs: which files it reads or writes, which network destinations it reaches, which processes it can start, whether it can touch the desktop.
- The organization can narrow that further through management policy.
- The operating system enforces the result. The policy sits outside the agent, so a prompt injection that convinces the agent to read a credentials folder still meets a closed door.
Policies cover containment, process, file system, network and user interface access. There are several containment backends: a process container (Windows 11, macOS and Linux), a session container and a WSL container (Windows 11), and a microVM backend that Microsoft labels experimental. Developers get an SDK, a JSON configuration schema and samples on GitHub.
Two modes matter for anyone who has tried to write least-privilege policy from scratch. Learning mode helps diagnose failures and verify that a policy grants only the access the workload needs. Permissive mode observes what the agent attempts without enforcing anything. Both turn policy writing from guesswork into observation.
Microsoft says GitHub Copilot, OpenAI Codex, Replit and LM Studio already use MXC, and that Anthropic’s Claude Code, Box, Egnyte and Perplexity are adding support. NVIDIA’s OpenShell is integrated for policy controls.
What is still coming
The announcement is careful about timing, and so should you be:
- Microsoft Entra integration, to distinguish agent activity from the activity of the person using the device, is described as coming.
- Microsoft Agent 365 will “soon” extend its controls to local, on-device agents.
- Intune management of MXC process containers on Windows 11 is also “soon”.
Until those land, MXC is a strong enforcement layer with a thinner management and identity story. Plan around what exists today.
- Agent plans and generates code
- Developer declares needed access
- Organization policy narrows it
- Windows enforces files, network, process, UI
- Learning mode logs attempts
- Inside the agent: Agent plans and generates code
- Outside the agent: Developer declares needed access · Organization policy narrows it · Windows enforces files, network, process, UI · Learning mode logs attempts
Untrusted, can be manipulatedPolicy authored by people
Why this changes the security conversation
Two days ago we argued that prompt guardrails are not a security boundary, and that this year’s agent incidents point to runtime containment instead. MXC is that idea shipped as a platform feature on the most common enterprise desktop.
The boundary becomes reviewable. A JSON policy that lists folders and network destinations is something a security architect can read, diff and approve. A system prompt that says “never access sensitive files” is not.
Coding agents stop being an exception. Coding agents run on developer laptops with broad local access, which is exactly where enterprise controls have been weakest. An OS-level container gives endpoint teams a control point they already understand.
Denied attempts become signals. When an agent tries to reach a destination outside its policy, that attempt is evidence: of a bad plan, a poisoned input or a compromised tool. It belongs in the same pipeline as other endpoint alerts.
What MXC does not do is answer who the agent is. Until the Entra integration ships, activity inside a container may still be hard to separate from the user’s own. As we noted when Microsoft’s Digital Defense Report put agent identity next to passwords, containment limits the blast radius; identity is what makes the activity attributable.
What to do now
- Inventory the agents that execute code on endpoints, starting with coding assistants and local automation tools.
- Decide who owns the policy. It should sit with endpoint security, not with whoever installed the agent.
- Start in Permissive or Learning mode on a pilot group, and write policies from observed behavior.
- Keep the microVM backend in the lab until Microsoft moves it beyond experimental.
- Route denied attempts to your security monitoring and review them like any other anomaly.
- Do not design around Entra, Agent 365 or Intune integration yet. Track them, and revisit the operating model when they ship.
The bottom line
The useful shift is not that Windows has another sandbox. It is that agent permissions are moving into a layer the agent cannot rewrite, authored by people and enforced by the operating system. That is where a security boundary belongs.