Sandboxing MCP Servers: Containers, Least Privilege, and Process Isolation

The threat model in one paragraph

An MCP server you install is code that runs on your machine, executed by your shell, with your file permissions and your network access. If the server is malicious, buggy, or compromised upstream, it can do anything you can do — read your SSH keys, exfiltrate your browser cookies, push a commit, send an email. Sandboxing is the difference between "the MCP can touch one directory and one HTTPS endpoint" and "the MCP can touch everything I can touch." For most installs, the difference is worth the setup time.

The four patterns, ranked by friction

A concrete example: sandboxing Puppeteer

The Puppeteer MCP spawns Chromium. Chromium has its own internal sandbox, but it still needs filesystem access for the browser profile, network access for the pages it loads, and ideally no access to your home directory. A reasonable wrapper:

# /etc/systemd/system/mcp-puppeteer.service
[Service]
Type=simple
User=mcppuppeteer
Group=mcppuppeteer
ReadWritePaths=/var/lib/mcp-puppeteer
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true
RestrictAddressFamilies=AF_INET AF_INET6
SystemCallFilter=@system-service ~@privileged @resources
ExecStart=/usr/local/bin/mcp-puppeteer

# In your MCP client config, point at the service via a thin shim
# that proxies stdio to the service's socket.

The systemd hardening flags (`ProtectHome`, `PrivateTmp`, `NoNewPrivileges`, `RestrictAddressFamilies`) close the most common holes: the MCP cannot read your home directory, gets a private /tmp, cannot escalate privileges, and is limited to TCP/IP. Add `SystemCallFilter` to block syscalls the MCP does not need and you have a tight box around a piece of code that drives a real browser.

What sandboxing does not solve

Sandboxing protects the host. It does not protect the upstream service the MCP talks to. If your sandboxed GitHub MCP has a personal access token with full-org scope, a compromise of the sandbox still has access to your org via the token. Sandboxing and credential scoping are complementary, not substitutes — and credential scoping is usually the higher-leverage move because tokens are reusable, while host access is one-shot.

Sandboxing also does not stop prompt injection. A perfectly sandboxed MCP that takes instructions from a malicious web page can still send those instructions to the model, which can still call other unsandboxed MCPs. Defense in depth: sandbox the things that need it, scope credentials narrowly, and require user confirmation on destructive tool calls.

Frequently asked questions