Sandboxing Local MCP Servers

Sandboxing a local MCP server means running it inside a boundary that limits what it can touch: which folders it can read and write, which network addresses it can reach, and how much of the computer's resources it can use. If the server is malicious or has a bug, the sandbox limits the damage. The MCP spec recommends it for local servers.

Without a sandbox, a local server runs with the same access as the AI app that started it. For most people, that means everything their user account can reach, including documents, SSH keys and saved browser sessions.

This guide covers what the spec says, the main sandbox options, and how to set limits that still let the server do its job. Sources were checked on 28 October 2026.

What the MCP spec recommends

The MCP Security Best Practices for the 2026-07-28 spec describe "local MCP server compromise." They list three ways it happens: a malicious startup command, a malicious payload inside the server, and an insecure local server reached through DNS rebinding.

For clients, the page says they SHOULD:

• "Execute MCP server commands in a sandboxed environment with minimal default privileges."
• "Launch MCP servers with restricted access to the file system, network, and other system resources."
• Let users "explicitly grant additional privileges (e.g., specific directory access, network access) when needed."
• "Use platform-appropriate sandboxing technologies (containers, chroot, application sandboxes, etc.)"

For servers meant to run locally, it recommends the stdio transport "to limit access to just the MCP client." If a local server must use HTTP, it should require an authorization token or use restricted inter-process channels such as Unix domain sockets.

Why a server's own limits are not enough

Many servers have built-in limits, such as an allowlist of folders. Those limits are code, and code has bugs.

The official Filesystem reference server is a good example. Its GitHub advisory describes how symlinks inside an allowed folder could reach "unintended files." It was fixed in 2025.7.01. A sandbox would have kept those files out of reach even while the bug existed.

That is the core idea: the sandbox is a second wall, enforced by the operating system or container runtime rather than the server's own code.

Your sandbox options

Containers and gateways

Docker's MCP Gateway docs say it runs servers in "isolated Docker containers with restricted privileges, network access, and resource usage." The gateway also "injects any required credentials," so secrets are managed centrally rather than in each user's config, and adds logging and call tracing. Our guide to MCP gateways compares gateway options.

OS-level sandboxes in AI apps

Some AI apps sandbox their own commands. Claude Code's sandboxing docs say it uses Seatbelt on macOS and bubblewrap on Linux and WSL2. Sandboxed commands have "no direct route to the network" except through a proxy that checks an allowlist of domains.

Read the scope carefully, though. The same docs say other processes Claude Code starts, including "local MCP servers," run "with your full access." To put MCP servers behind the boundary too, the docs describe running the open-source @anthropic-ai/sandbox-runtime package around the whole Claude Code process. They also note that on native Windows, commands run unsandboxed.

The lesson applies to every client: check whether "sandbox" in your AI app covers MCP servers, or only shell commands.

How to set the limits

Start with nothing and add only what the server needs.

Files

1. Give the server one working folder, not your home directory.
2. Make it read-only unless the server must write.
3. Never mount folders holding SSH keys, cloud credentials or browser profiles.
4. Pass secrets as environment variables or through a gateway, not by mounting config folders.

Network

1. Block all outbound traffic by default.
2. Allow only the specific hosts the server needs, such as one API domain.
3. Block private ranges and cloud metadata addresses such as 169.254.169.254, which the best practices flag as a credential-theft target.
4. If the server listens on HTTP, bind it to 127.0.0.1 and require a token. The Streamable HTTP spec says local servers "SHOULD bind only to localhost."

Resources

1. Cap memory and CPU so a runaway server cannot freeze the machine.
2. Set a timeout on tool calls; the tools spec says clients should "Implement timeouts for tool calls."
3. Run as a non-root user with no extra privileges.

An illustrative container command

The command below is an example pattern only, not a vendor recipe. Check the flags against Docker's docker run reference, its none network driver page and its bind mounts page for your version.

docker run -i --rm \
  --read-only \
  --network none \
  --cap-drop ALL \
  --memory 512m \
  --user 1000:1000 \
  -v /path/to/project:/data:ro \
  example/mcp-server:1.2.3

It keeps stdio (-i), blocks network access, drops privileges, caps memory, mounts one folder read-only and pins an exact image version. Servers that call an API need a network, so replace --network none with a network that allows only that API.

What sandboxing does not fix

A sandbox limits the blast radius of the server process. It does not:

• Stop prompt injection. If the server is allowed to send email, an injected instruction can still send email. See prompt injection through tool results.
• Protect the access you grant on purpose. A read-only mount of your client folder is still readable.
• Fix a remote server. Sandboxing is about code running on your machine.
• Replace review. Read the server and its install command first, as covered in how to security-review an MCP server.

Combine sandboxing with least privilege, approvals for risky tools and logging. The MCP security checklist lists all of them.

Next step

If your team runs local servers and you are unsure how they are contained, our MCP readiness audit reviews each one and recommends a sandbox setup. Building a server that should ship sandbox-friendly? Talk to our MCP development team.

Frequently asked questions