In a new Windows Developer Blog post titled "Windows platform security for AI agents", Microsoft positions Windows as the trustworthy operating system for autonomous agents and introduces the Microsoft Execution Containers (MXC) SDK as the core of that strategy. The post argues that containment, identity and manageability must be built into the operating system so that agents can be deployed and governed safely at scale. It describes a spectrum of isolation mechanisms, from process and session isolation through to planned micro virtual machines and Linux containers, all driven by MXC policy.
MXC is presented as a policy‑driven execution layer for agents on Windows and WSL that abstracts over lower‑level isolation primitives. Developers describe what an agent may access in JSON or through a TypeScript SDK, and Windows uses process isolation for containment and session isolation when agents need separate desktops and identities. There is also planned support for using micro‑VMs for higher‑risk work, and Linux containers for toolchains that depend on Linux. Also integration into Windows 365 for Agents to run some workloads on cloud PCs is coming. The intent is that IT teams can manage MXC policies centrally using Entra ID and Intune, and Defender and Purview will give protection, observability and and audit trail of agent behaviour.
Containment, identity and manageability are built as foundational primitives in Windows, extending security beyond the app and model into the OS.
-- Dana Huang
The post also roots the agent model in longer‑running security investments such as Secure Boot, passwordless sign‑in, hotpatching, memory‑safe drivers and post‑quantum cryptography in Insider builds. It claims that agents can inherit this secure foundation, with Defender adding protection against prompt injection and other agent‑specific threats. This argument emphasises having distinct agent identities, least‑privilege access and proxy‑mediated tool calls.
Industry coverage has picked up on the structural aspects of MXC. A report from CSO Online notes that MXC offers multiple containment backends behind a unified configuration and SDK. A separate analysis of Microsoft's Build announcements argues that folding MXC into Windows and WSL is part of Microsoft's efforts to rebuild the operating system as a controlled runtime for AI agents as well as humans.
Some early commentary is quite cautious about treating MXC as a finished security solution. A technical write‑up on MXC from byteiota.com notes that the same policy schema is expected to run on Windows, Linux and macOS but that macOS support is still experimental. The article cites Microsoft documentation warning that MXC profiles should not yet be treated as security boundaries, and it highlights known cases of overly permissive policies that need to be addressed. It also points out that outbound network filtering doesn't yet work; an important point given that agent compromise often manifests as data exfiltration..
The value of an agent is not just what it can do, but whether it can be trusted in production.
-- Dana Huang
Cloud providers, Linux vendors and independent projects are also progressing platform security for agents for other platforms too. Outside the Windows ecosystem, Linux‑based platforms have been moving in a similar direction, often with a stronger emphasis on kernel‑level or hardware‑backed isolation. NVIDIA's open source runtime OpenShell is described as a safe, private runtime for autonomous agents that combines sandbox runtime controls with declarative policies to prevent unauthorised file access, data exfiltration and uncontrolled network activity. NVIDIA's developer guide demonstrates the kernel‑level isolation, with filesystem, network and process‑level controls enforced in a sandbox designed for long‑running self-evolving agents. Red Hat has announced integration between its AI platform and OpenShell, alongside confidential containers and SELinux‑based enforcement, as part of a zero‑trust model for enterprise AI agents across hybrid cloud systems.
A number of projects and guides have also emerged around agent sandboxes on Kubernetes. An InfoQ article on the Agent Sandbox controller describes a Kubernetes add‑on that uses gVisor and, optionally, Kata Containers to isolate untrusted agent code in hardened pods. This approach specifically uses OWASP guidance around system isolation and permission management. Another recent InfoQ report on Azure Container Apps Sandboxes covers Microsoft's separate work on microVM‑backed sandboxes for untrusted agent code in the cloud, where each sandbox runs in a hardware‑isolated microVM with default‑deny egress enforced by a proxy.
Linux distributions and security vendors are also using native primitives such as cgroups, namespaces, seccomp, Landlock and eBPF to build agent‑aware sandboxes. Agent execution sandboxes running in standard containers share a host kernel, and production‑safe agent execution often requires hardware‑level isolation via microVMs or user‑space kernels, combined with strict filesystem and network policies. A project named Guardian Shell, for example, launches agents in isolated cgroups with Landlock, seccomp and eBPF hooks enforcing per‑agent policies at the kernel level without requiring changes to agent code. This approach tries to add agent‑specific control into existing Linux security modules and container runtimes, rather than building a new SDK and policy layer into the operating system.
For security teams, the immediate takeaway is that there is no single dominant platform security model for AI agents yet. Windows' MXC preview brings OS‑integrated, policy‑driven containment to the Windows and WSL world, but its own documentation and independent analyses stress that this is early software that should not be treated as a final and complete security boundary. Linux and Kubernetes already offer kernel‑level and hardware‑backed options such as OpenShell, gVisor, Kata Containers and cloud microVM sandboxes.