If you’ve been following agent infrastructure, the last month has a pattern: every major vendor wants to be the layer that runs AI agents safely. On October 7, 2026, Microsoft joined that race with Microsoft Execution Containers (MXC), now generally available at v1.0.0.[1][3][4][5] It’s the third serious entry in roughly a month - a direct continuation of the managed-sandbox wave we covered when DigitalOcean launched Harness Runtime, Action Gateway, and later its Agent Droplets bundle.
The tempting thing is to file MXC next to those and treat all three as “where to deploy agents.” That would be a mistake. MXC is a different kind of product with a different job, and understanding the difference is the whole point of this article.
What MXC actually is
MXC is a policy-driven execution layer for untrusted code or dynamically generated workloads - in agentic terms, for model-generated output, plugins, tools, an agent harness, or an entire agent.[1][2] Developers and IT administrators declare the resources a workload may use (files, network destinations, UI) and MXC enforces that boundary at runtime with an OS container.[1]
Three properties matter here:
- The policy sits outside the workload’s control. The agent, the model, generated code, plugins - none of them can grant themselves more access than the policy allows. MXC validates the container-creation request, selects a backend, and launches the workload in a container whose boundary the workload itself cannot widen.[1][2]
- It’s an SDK, not a service. MXC builds into your application. You write a versioned JSON configuration, and the SDK maps your requested controls onto a platform-appropriate backend. The current supported SDKs are Rust (
mxc_sdk::v1), .NET (Microsoft.Mxc.Sdk.V1), and Node.js (@microsoft/mxc-sdk/v1).[2][3][4][5] - It’s cross-platform, but Windows is the center of gravity. MXC works on Windows 11, Linux, and macOS, yet the most differentiated backends - the session container that isolates an agent in its own OS session with separate desktop, clipboard, and input - are Windows-only.[1]
The containment spectrum
MXC doesn’t offer one sandbox. It offers backends with different isolation strengths, and you pick based on workload risk:[1]
| Backend | Availability | Best suited for |
|---|---|---|
| Process container | Windows 11, macOS, Linux | Lightweight containment for responsive workloads - model-generated code, tool execution (AppContainer on Windows, Seatbelt on macOS, Bubblewrap on Linux) |
| Session container | Windows 11 only | Long-running agents/automation needing a desktop or stronger separation from the interactive user (separate Windows account and session) |
| WSL container (WSLc) | Windows 11 only | Linux-first agent toolchains that depend on the Linux package/dev ecosystem |
| MicroVM | Windows 11 and Linux (experimental) | Higher-risk workloads that need a hardware-backed virtualized boundary |
The GitHub repository lists even more primitives - including Windows Sandbox, LXC, and Hyperlight - with several marked experimental.[2]
Policy itself is declared across five areas: containment (which isolation environment), process (command, args, cwd, env), file system (modifiable, read-only, and inaccessible locations), network (inbound/outbound, including loopback), and user interface (desktop and UI access).[1]
Three operating modes for authoring and enforcing policy
Writing a least-privilege policy when you don’t yet know every resource a workload touches is hard. MXC’s answer is three modes:[1]
- Enforcement - runs the workload with its production policy; un-granted access is blocked.
- Learning - still blocks un-granted access, but records denials in a JSON activity report so developers can diagnose failures and verify the policy grants only what’s needed.
- Permissive - records what would have been denied but lets the operation continue, useful while authoring policy. (Permissive mode does not bypass other OS or organizational restrictions.)
Windows-only process containers can additionally produce an agent activity report showing which resources a workload attempted to use - a concrete aid for crafting least-privilege policies.[1]
What v1.0.0 and “generally available” actually mean
MXC was introduced as an early SDK preview at Build 2026 in June.[6] The October release declares the 1.x compatibility boundary and stable SDK surfaces, and - importantly - the SDK packages are verified today at 1.0.1 - a patch on the 1.0.0 GA - across all three registries: @microsoft/mxc-sdk on npm, Microsoft.Mxc.Sdk on NuGet, and mxc-sdk on crates.io.[3][4][5]
Two things follow from reading the current GitHub repository and the announcement together:
- The core is GA; the management layer is not. The containment layer (the SDK, the backends, the three modes) is generally available, and Windows 365 support for MXC is GA too. But the surrounding pieces are explicitly “coming soon” with no dates: Intune policy for MXC containers, Microsoft Entra distinguishing agent activity from user activity, and Agent 365 controls (attribution, per-agent policy, investigation) for on-device agents.[1]
- The repository has meaningfully matured. During preview, the MXC README carried a warning that SDK-generated policies were “overly permissive” and that “no MXC profiles should be treated as security boundaries currently.” As of the 1.0.0 era, the current README no longer carries that caveat - but it still leans on platform backends that vary in maturity (several, including MicroVM and Hyperlight, remain experimental).[2]
That source-of-truth reading matters if you’re evaluating MXC, and it’s why this article checks the repo rather than quoting only the announcement.
MXC vs DigitalOcean vs self-hosted: what each one is for
This is a hosting site, so the question my readers face is concrete: I have to run agents somewhere - is MXC the answer? The honest short version is no, not for what you’re probably trying to do - MXC is containment, not hosting. Here’s the real split.
MXC: where agents run, not what they run on
MXC does not deploy web apps. It is not a VPS, a PaaS, or a marketplace. It’s the layer that keeps an agent’s access within the bounds you declared - which is why it fits when you’re running agents where you already have a Windows environment: a developer’s machine, a Windows 365 Cloud PC, or a fleet of corporate Windows 11 devices that IT signs off on with Intune (once the Intune integration ships).[1]
Its identity story is the giveaway for the intended user. The announcement frames MXC around containment, identity, and manageability - distinguishing an agent’s activity from a person’s, giving IT tools to govern and audit it. That is an enterprise Windows-management pitch, aimed at organizations that already manage devices and want agents on those devices to stay in a box. GitHub Copilot, OpenAI Codex, Replit, OpenClaw, LM Studio, and Unsloth are among the agents already supporting MXC.[1]
DigitalOcean: agents as a managed cloud subscription
DigitalOcean’s agent products are the opposite end of the spectrum - cloud subscriptions, not OS layers. Harness Runtime runs each agent session in its own Firecracker microVM billed per second, with pause/resume/checkpoint/fork; Action Gateway is a managed MCP endpoint brokering access to 16,000+ tools.[7] Agent Droplets then bundle the whole stack - compute, inference, session storage, tools - into a flat $50/month Pro or $200/month Team plan.[8] If you’re weighing running an agent workload in the DigitalOcean cloud at all, our Agent Droplets review digs into what that flat fee covers and what it doesn’t.
Where MXC says “contain the agent that runs on the Windows device you already manage,” DigitalOcean says “we’ll run the agent for you in the cloud, bill you for consumption, and gate its tool access.” There’s no overlap in the compute model: DigitalOcean is a hosted runtime; MXC is a containment layer embedded in your own app on your own device.
Self-hosted: your VPS, your responsibility
The third path is the one this site assumes: run agents on a server you control, with your own sandboxing where you need it. A cheap Droplet (the Basic 1 vCPU / 1 GiB is $6/month) can run coding agents today with a toolchain you already know - self-hosted MCP servers, Docker, your own isolation choices.[8] Tools like Coolify vs Dokploy (Coolify is Apache-2.0 and self-hosted) can even provide a managed-looking PaaS layer on top of your own server - and if exposing a locally-run agent is the goal, a self-hosted HTTP tunnel gets you the endpoint you need.[9]
The trade-off is exactly the maintenance backlog that managed products absorb: isolation, authorization, tool gateway, audit, storage lifecycle are all yours. For a solo developer already fluent in VPS work, that’s often the most cost-effective and most portable route - but it’s also the one with the most operational surface to patch and maintain.
The honest comparison table
| MXC | DigitalOcean Agent bundle | Self-hosted VPS | |
|---|---|---|---|
| What it is | OS-enforced containment layer (SDK) | Managed cloud subscription | Your server + your tooling |
| Runs on | Windows 11 / macOS / Linux device; Windows 365 | DigitalOcean cloud microVMs | Your own VPS |
| Isolation | OS backends: process / session / WSL / MicroVM | Hypervisor microVM per session | Whatever you build |
| Policy model | Declared JSON policy, three modes | Plan + tool-gateway access | Manual |
| Best for | Agents on managed enterprise Windows / Cloud PCs | Teams that want hosted, billed agent infra | Developers who want control + portability |
| Not for | Deploying web apps / general hosting | Bootstrapping a Linux box you fully own | Teams with no infra bandwidth |
Which scenario wins for you
Let me be direct, because the vendor noise here is real.
MXC is the right answer if your agents run in a Windows-enterprise context - you manage Windows 11 devices, want agents on those devices contained and ultimately governable by Intune and Entra, and need an OS-level boundary that agents cannot widen. It’s a containment capability, and you’d adopt it inside the agents and harnesses you already use. It is not a reason to buy hosting.
DigitalOcean’s bundle is the right answer if you want agents as a hosted, metered cloud product with the isolation and tool-gating done for you - and you’re comfortable with a cloud subscription instead of a box you control.
A self-hosted VPS is the right answer if you already run servers, want full control and portability, or want the flat predictable cost of a $6 Droplet over metered or subscription pricing. This remains the most flexible path - and the most maintenance.
What I won’t do is pretend I can rank them by cost or speed without measuring. There is no benchmark in this article because an honest one requires running real agent workloads on real paid accounts - see how we test. Treat the numbers above as provider-pricing structure, not performance data.
The takeaway
Microsoft Execution Containers is a genuinely important entry into the agent-isolation niche: an open, MIT-licensed, policy-driven containment layer with real SDKs and a real OS-enforcement story, now stable at v1.0.0.[1][2][3] But it is containment, not hosting - it answers where the agent’s access stops, not where the agent runs.
When you decide “where to host agents in 2026,” you’re choosing between three different kinds of answers: contain the agent on infrastructure you already own (MXC, on managed Windows), rent managed hosted agent compute (DigitalOcean), or own the whole stack on a VPS you control (self-hosted). None of them is “better” in the abstract - they fit different scenarios, and the honest move is to pick by where your agents actually run, who manages the machine, and how much operational load you want to carry.
Sources
- Microsoft Windows Developer Blog - “Microsoft Execution Containers: Policy-driven containment for AI agents” (Oct 7, 2026; GA announcement; containment/identity/manageability; backend table; five policy areas; three operating modes; Intune/Entra/Agent 365 “coming soon”; Windows 365 GA; supported agents). https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/ - checked 2026-10-11
- microsoft/mxc - GitHub repository README (MXC as SDK dependency; JSON config; Rust/.NET/Node SDKs; process/seatbelt/bubblewrap/LXC/microvm/hyperlight/WSLC backends; experimental marks; MIT license; samples). https://github.com/microsoft/mxc - checked 2026-10-11
- npm -
@microsoft/mxc-sdk(latest dist-tag1.0.1). https://www.npmjs.com/package/@microsoft/mxc-sdk - checked 2026-10-22 - NuGet -
Microsoft.Mxc.Sdk(latest1.0.1). https://www.nuget.org/packages/Microsoft.Mxc.Sdk - checked 2026-10-22 - crates.io -
mxc-sdk(max stable1.0.1). https://crates.io/crates/mxc-sdk - checked 2026-10-22 - Microsoft Windows Developer Blog - “Build 2026: Furthering Windows as the trusted platform for development” (Jun 2, 2026; MXC SDK introduced as early preview). https://blogs.windows.com/windowsdeveloper/2026/06/02/build-2026-furthering-windows-as-the-trusted-platform-for-development/ - checked 2026-10-11
- DigitalOcean Harness Runtime / Action Gateway - pricing and Docs (Firecracker microVM per session; per-second consumption billing; managed MCP gateway to 16,000+ tools). https://www.digitalocean.com/pricing/harness-runtime - checked 2026-10-11
- DigitalOcean - Droplet pricing (Basic 1 vCPU / 1 GiB - $6/mo); Agent Droplets pricing (Pro $50/mo, Team $200/mo). https://www.digitalocean.com/pricing/droplets; https://www.digitalocean.com/pricing/agent-droplets - checked 2026-10-11
- Coolify - GitHub (Apache-2.0, self-hosted) and self-hosted docs. https://github.com/coollabsio/coolify; https://coolify.io/docs/start-with-self-hosted - checked 2026-10-11