By default, every MCP server runs with the same privileges as the host that loaded it. Reads your filesystem. Holds your tokens. Spawns subprocesses. A sandboxed runtime breaks the assumption — the server runs in a jail, the host stays clean. Here are the four approaches, what each catches, and the trade-offs.
Why sandboxing is now the bar
Three pressures forced this from "nice to have" into a default expectation:
- Supply chain attacks that exploit the privilege grant — see supply chain attacks.
- Compliance — SOC2, HIPAA, EU AI Act all push for least privilege at execution time.
- Cross-team servers — internal MCP marketplaces need to assume some submitters are wrong, some hostile.
Sandboxing answers all three with the same primitive: limit what the server can touch.
Four approaches
1. OS containers (Docker, Podman)
The default. Run the MCP server inside a container with no host volumes mounted, a minimal network policy, non-root user.
- Strengths: mature, portable, cheap. Works on every OS today.
- Weaknesses: kernel-shared (escapes are rare but real); cold start adds 1–3 s.
- Pick when: general-purpose isolation, dev and prod alike.
2. MicroVMs (Firecracker, Cloud Hypervisor)
Lightweight virtualisation. Each MCP server runs in its own kernel.
- Strengths: strong isolation; near-container speed; clean resource limits.
- Weaknesses: more setup; not common on laptops.
- Pick when: running untrusted servers in production at scale.
3. WASM runtimes (wasmtime, Wasmer)
Compile the server to WebAssembly; run it in a capability-bound sandbox.
- Strengths: strongest capability model; tiny attack surface; instant start.
- Weaknesses: language-restricted (Rust/Go/Zig); ecosystem young.
- Pick when: building greenfield, security-first servers.
4. OS-native primitives (App Sandbox, AppContainer, Landlock)
Use the OS's own sandboxing API. macOS App Sandbox, Windows AppContainer, Linux Landlock + seccomp.
- Strengths: zero extra runtime; integrates with OS audit; lowest overhead.
- Weaknesses: OS-specific; documentation thin.
- Pick when: locking down personal-laptop usage.
Comparison
| Approach | Isolation | Overhead | Portability | Maturity |
|---|---|---|---|---|
| OS container | Medium | Low | High | High |
| MicroVM | High | Low–Medium | High | Medium |
| WASM | High (capability) | Very low | Medium | Low–Medium |
| OS-native | Medium–High | None | Per-OS | Medium |
Reference setup with Docker
The minimal hardened wrapper:
"github": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"--read-only",
"--cap-drop", "ALL",
"--security-opt", "no-new-privileges",
"--network", "none",
"--user", "1000:1000",
"ghcr.io/example/github-mcp"
],
"env": { "GITHUB_TOKEN_FILE": "/run/secrets/github" }
}
Read-only filesystem, no capabilities, no new privileges, no network unless the tool requires it, non-root user. Mount tokens as files, not env vars.
What sandboxing does NOT solve
- Prompt injection through outputs — the server is sandboxed, the model still trusts what comes back. See prompt injection.
- Credential leakage in tool arguments — sandbox does not stop the agent from sending a secret as an argument.
- Data exfiltration via allowed channels — if the network is open for the tool's purpose, exfil flows through it. See exfiltration protection.
Sandboxing is necessary, not sufficient.
Roll-out path
- Wrap the riskiest servers (broad scope, new vendors) in containers first.
- Add network policies (
--network nonestrongest; named networks per server next). - Move secrets out of
envblocks into mounted files. - Move non-prod tooling to MicroVM or WASM where the language allows.
- Audit the host-side servers for bypass paths.
Where this is heading
Two trends to expect by mid-2027: standardised sandbox manifests in MCP itself (a server declares its capability requirements; the host enforces), and OS-level integrations from Anthropic for Claude Desktop. Build the wrappers now, swap implementations later.