Microsoft puts Windows at the center of AI agent security

Microsoft is making a bet that the operating system, not the model, is where AI agent security has to live. The Windows Developer team just published a post titled "Windows platform security for AI agents" that introduces the Microsoft Execution Containers (MXC) SDK, a policy-driven layer that decides what an agent on Windows or WSL is allowed to do before it runs. InfoQ published a longer technical write-up on what MXC actually changes.

MXC is the new abstraction that sits between an agent and the underlying isolation primitives. Developers describe what an agent may touch, what network calls it can make, and what files it can read, in JSON or through a TypeScript SDK. Windows then picks the right containment mechanism for that policy. Low-risk work runs in a process isolation boundary. Higher-risk work gets its own session and identity. The most sensitive work is meant to land in planned micro virtual machines, and Linux containers are supported for agent toolchains that depend on Linux. Windows 365 for Agents integration is also on the roadmap, which would let some agent workloads move to cloud PCs without rewriting the policy.

The bigger idea is that the OS, not the application, owns containment, identity, and manageability. IT teams can write MXC policies in one place and let Entra ID, Intune, Defender, and Purview enforce them across the fleet. Defender adds protection against prompt injection and other agent-specific threats. Purview gives an audit trail of what an agent did, when, and on whose behalf. The argument is that agents should be able to inherit the same Secure Boot, passwordless sign-in, hotpatching, memory-safe drivers, and post-quantum cryptography that Microsoft has been hardening in Windows over the last several years. The post also leans on distinct agent identities, least-privilege access, and proxy-mediated tool calls as the operating principles underneath the policy layer.

How Windows MXC works, and where it falls short

In practice, MXC is a thin policy layer that calls into lower-level isolation. The official Windows Developer Blog post frames it as a unified configuration plane that fronts multiple containment backends, and CSO Online's coverage describes the same architecture from the operator's side: one JSON or TypeScript spec, multiple isolation engines behind it. That is useful, because agent developers do not want to learn the difference between a process boundary, a session boundary, a micro-VM, and a Linux container just to ship a feature. They want to describe intent, and let the platform pick the right fence for the job. Done well, this is the kind of abstraction that lets a security team say "all agents that touch customer data run in a micro-VM with no outbound network" in one place, and have it stick.

The catch is that the platform is still very early. A technical write-up on byteiota.com, which the InfoQ piece cites, notes that the same MXC policy schema is supposed to run on Windows, Linux, and macOS, but macOS support is still experimental. Microsoft's own documentation warns that MXC profiles should not yet be treated as security boundaries. Independent analysis has surfaced overly permissive default policies that need tightening, and the outbound network filter is not implemented yet, which is a real problem because the most common agent failure mode is data exfiltration. If an attacker can talk to a model and an exfiltration endpoint, none of the in-OS isolation matters. Treat the SDK as a shape, not a guarantee, and budget for a year of policy tuning.

The dependency story matters too. MXC assumes the agent is running on Windows or WSL, which is fine for the enterprise Microsoft sells to, and rough for anyone who is trying to keep their agent portable across macOS developer laptops and Linux servers. The Linux container path helps, but it does not give Linux the same out-of-the-box Entra and Intune integration. If you are a security team buying a fleet of MXC-managed agents, you are also buying deeper into the Microsoft management plane, which is the actual product Microsoft is selling whether it says so or not. The same Windows licensing and Entra seats that already anchor enterprise procurement are about to anchor agent deployment too, and IT leaders should plan for that, not be surprised by it.

The race to own the runtime beneath AI agents

Microsoft is not the only team trying to own the runtime beneath the agent. NVIDIA's open source OpenShell project is described as a safe, private runtime for autonomous agents, with sandbox runtime controls and declarative policies that block unauthorized file access, data exfiltration, and uncontrolled network activity. The developer guide shows kernel-level isolation with filesystem, network, and process controls enforced inside 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 story for enterprise AI agents across hybrid cloud systems. That puts an open source, kernel-anchored alternative directly against Microsoft's managed-Windows approach, and it gives CISOs who are nervous about Windows monoculture a real second option.

The Kubernetes world is heading the same way. The Agent Sandbox controller, an InfoQ-reported add-on, uses gVisor and optionally Kata Containers to isolate untrusted agent code in hardened pods, with explicit OWASP guidance on system isolation and permission management. Azure Container Apps Sandboxes, a separate Microsoft project, runs each agent in a hardware-isolated microVM with default-deny egress enforced by a proxy. Linux distributions and security vendors are also using native primitives like cgroups, namespaces, seccomp, Landlock, and eBPF to build agent-aware sandboxes, and projects like Guardian Shell launch agents in isolated cgroups with Landlock, seccomp, and eBPF hooks enforcing per-agent policies at the kernel level. None of these is a drop-in replacement for the others, and none of them is a finished answer yet, which is exactly the point: there is no dominant platform security model for AI agents in 2026.

For security teams, the immediate takeaway is that the agent security stack is still a buyer's market in the worst sense. Microsoft's MXC preview is real, it is on a clear roadmap, and it ships with the management integration that enterprise IT already knows how to run, but it should be treated as a forward bet, not a finished perimeter. OpenShell and the Kubernetes sandboxes are real too, with stronger kernel-level isolation, but they require more integration work and they do not plug into Entra the way MXC will. Today's related reporting on the RCE risk that a malicious webpage can run code on a host through a browsing AI agent, published earlier this same week, is the most concrete reminder of why the OS layer is the right place to be investing in containment at all. Pick the model that fits your fleet, but plan on revisiting it in a year, because the platform underneath the agent is changing faster than the agent itself.

For a broader look at how enterprise teams are weighing runtime choices, governance, and rollout for AI agents today, see the Enterprise AI in 2026: Use Cases, Governance, and Rollout reference page.