Microsoft Just Shipped a Sandbox for Agents

This week, your coding agent probably ran a dozen shell commands on a machine you care about. Every one of those commands traces back to text the model read somewhere — a README, a webhook payload, a webpage. That's the scariest dependency in your stack, and until now we've defended it with polite instructions.

Microsoft just shipped Mxc 1.0.0: Execution Containers with policy-driven containment, purpose-built for AI agents. A first-party 1.0 for agent sandboxing is a signal worth fifteen minutes of your Sunday.

Why this matters

The attack that keeps security people up at night is indirect prompt injection: poisoned content goes in, harmful commands come out. The model can't reliably tell instruction from data — that's not a bug you prompt away.

Human approval gates rot fast. Click "allow" forty times a day and the forty-first click is muscle memory. The fix isn't a better system prompt; it's making the wrong action physically impossible. When an OS vendor ships agent containment as a supported primitive, "we trust our prompt" stops being an acceptable answer in design reviews.

How it works

The pattern has three parts: the agent plans outside, execution happens inside, and a policy sits between them. Tool calls dispatch into a short-lived container instead of onto your host session.

The policy is an allowlist enforced at the OS boundary — which paths are readable or writable, which hosts are reachable, what may spawn, how much CPU and memory it gets. Violations fail at the syscall level. The model gets an error, not a choice. That's the whole trick: enforcement lives below the LLM in the stack.

Where this helps

• Laptop coding agents: the agent reads the repo and /tmp, and nothing else. It cannot touch ~/.ssh or POST to an unknown host. Injection becomes an annoying error, not an incident.
• CI fix-up bots: generated code runs against the checkout with exactly one credential — the deploy key for that step. Least privilege per task, not per pipeline.
• MCP tool servers: every third-party tool invocation lands in its own container. One malicious package can't ladder up into your session.

Watch out

• It's a 1.0 security boundary. Expect rough edges. This complements code review and spending caps; it doesn't replace them.
• It's Windows-first. Cross-platform teams need the Docker, gVisor, or microVM equivalent until parity.
• Policies are the hard part. Too tight and the agent stalls on permission errors; too loose and it's security theater. Budget real iteration time here.
• Containers constrain execution, not intent. If the agent legitimately needs a secret to do its job, containment won't stop a confused deputy from misusing it.

Try it yourself

Not on Windows? You can apply the same four policies with Docker today. Run your next agent task like this:

docker run --rm -it \
  --network none \
  --read-only \
  --user 1000:1000 \
  --tmpfs /tmp:rw,size=64m \
  -v "$PWD:/workspace" \
  python:3.12-slim \
  bash -c 'cd /workspace && python agent_task.py'

--network none kills exfiltration. --read-only kills persistence. Dropping root and mounting one writable path shrinks the blast radius to the workspace. Watch how many "essential" agent steps turn out to be exfil-shaped once the network is gone.

TL;DR

• Mxc 1.0.0 — Microsoft's policy-driven Execution Containers for AI agents — shipped stable this week.
• Agent safety is moving from prompt instructions to OS enforcement: the model loses the ability to misbehave.
• Today: run one agent task with no network, a read-only filesystem, and no root. Notice what breaks — that's your real attack surface.