What an agent is allowed to touch
Microsoft has put an agent sandbox into Windows itself. The interesting part is not the feature, it is that the question it answers, what is this thing allowed to touch, is the question we have been answering by hand on every AI system we ship.
At Build 2026 Microsoft shipped an early preview of Microsoft Execution Containers, or MXC, a policy-driven execution layer built into Windows and WSL. In plain terms, it lets you declare exactly what an AI agent can and cannot reach, and the OS kernel enforces those boundaries at runtime rather than trusting the agent to behave. OpenAI, Nvidia, Manus and Nous Research were named as launch partners, per VentureBeat.
The feature itself matters most to people writing coding agents on Windows. What caught our attention is the question underneath it, because it is the same question we have been answering by hand on every system where an agent does more than talk.
Answering is safe, acting is not
A model that summarises a document or drafts a reply is low risk. The blast radius is the text it produces. The moment the same model is given tools, a file path, a network call, a shell, a payment endpoint, the risk stops being about the quality of the output and starts being about reach. A confident wrong decision now writes to disk, hits an API, or moves money.
That is the line MXC is drawn around. It offers process isolation for the fast inner loop, where a coding agent runs generated code in a boundary that restricts the files and network domains it can see, and hardware-backed micro-VMs for higher-risk work, where a hypervisor raises the bar against a sandbox escape. Two levels of containment for two levels of trust, per the Windows developer blog.
We have been building this by hand
On the operational software and installations we ship, containment has never been optional. An agent that reconciles data on a client system gets a service account scoped to the exact tables it needs, not the database. A kiosk that runs a model on the floor gets an egress allowlist, so it can reach the one service it depends on and nothing else. A build that runs untrusted code gets a throwaway container with no secrets mounted. None of that is exotic. It is just the work, done every time, because the alternative is handing a probabilistic system the keys to the machine.
Least privilege was always the right default. An agent that can act rather than answer is the thing that finally makes ignoring it expensive.
What actually changes
The shift MXC signals is not Windows-specific and it is not really about Microsoft. It is that containment is moving from something each team improvises to something the platform expects you to declare. When the operating system, the cloud, and the agent framework all start shipping a control surface for what an agent may touch, the default stops being open and starts being explicit. That is the right direction. The wrong version of this future is the one where a team wires an agent to a live system, gives it broad credentials to save an afternoon, and finds out where the boundary was after it crossed it.
How we read it
For anyone putting an agent near a real system, the useful takeaway is not to wait for a specific vendor tool. It is to decide the permission boundary before the agent is wired in, write it down as a policy rather than a habit, and pick the level of isolation that matches what a mistake would cost. MXC is a sign the industry is converging on that discipline. We were already going to design the boundary first. It is good to see the platforms agree it is the load-bearing part.