How do I sandbox a local stdio MCP server so it can only touch the files and network hosts it needs?

What should I check, step by step?

1. Inventory what each local server really needs: which directory (read-only or writable), which hosts, which one credential. A server that only wraps a remote API needs no files; the MCP guide says to prefer its remote version and skip the local install.

2. Change the launch command, not the server: in your client config, set command to the sandbox (docker, bwrap, firejail or srt) and move the original command into args. One wrapper per server, so each gets its own limits.
3. Container baseline: docker run -i --rm (-i keeps stdin open for stdio), mount only the project directory (-v "/abs/path/project:/work:ro" if it only reads), add --read-only for the container's root filesystem, --cap-drop ALL and --security-opt no-new-privileges, and pin the image by digest (image@sha256:...).
4. No network unless needed: --network none for file-only servers. For servers that call one API, put the container on a docker network created with --internal and route it through an egress proxy that allows only that API's host, or use srt's network.allowedDomains, which starts empty and denies everything else.
5. Without containers on Linux: bwrap with --ro-bind for system paths, --bind only for the one writable directory, --unshare-net (or --unshare-all) and --die-with-parent; or firejail with --private=<dir> or --whitelist, --net=none, --caps.drop=all and --nonewprivs.
6. On macOS: srt wraps the command with sandbox-exec and a generated Seatbelt profile (allowWrite empty by default, denyRead for ~/.ssh, ~/.aws and similar, allowedDomains for egress). Apple's sandbox-exec man page marks it deprecated, so treat it as a best-available layer and prefer a container or VM for servers you trust least.
7. Separate the account, too: run especially untrusted servers under a dedicated OS user (the MCP guide's "going further" step) so even an escape lands in an account with no keys, browser profiles or home directory of yours.
8. Hand in only its own secret: pass a per-server token with docker -e NAME (value read from the client's env for that server) rather than inheriting your whole shell environment, and never mount ~/.ssh, ~/.aws, the Docker socket or your home directory.
9. Test from inside: ask the agent to use the server to read ~/.ssh/id_ed25519, write outside the mounted folder and fetch an unlisted host. All three should fail; if any succeeds, the wrapper is not in effect.

Why isn't the MCP stdio transport a sandbox for a local server?

The MCP Local Server Security guide states the trust model plainly: the client and a stdio server share one trust domain, neither the protocol nor the SDKs defend one against the other, and isolation is the responsibility of the host application and whoever operates the machine. The security best practices add that clients offering one-click local install SHOULD launch servers with restricted file, network and system access, using platform sandboxing such as containers or application sandboxes.

• The threats the guide lists are a malicious or typosquatted server, an overcollecting server, a compromised dependency, a poisoned tool catalog and a vulnerable bridge. Isolation is the one control that limits all of them at once: it turns "this server can read my SSH keys" into "this server can read an empty directory".
• Configuration-level allowlists, such as the directory list you pass a filesystem server, are cooperative. The guide warns that nothing stops a malicious or compromised server from reading whatever its process can reach; enforcement comes from a sandbox where the allowed directory is the only filesystem that exists.

How do I wrap a local MCP server's launch command in a container, bubblewrap, firejail or srt?

Containers are the guide's baseline and stdio works unchanged. GitHub's own MCP server documents the pattern: command docker, args run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server, with the token supplied through the client's env block. Add your mounts, --read-only, --cap-drop ALL and --network none or an internal network to that same args list.

• bubblewrap builds a fresh mount namespace from only the paths you bind (--ro-bind for read-only, --bind for writable) and --unshare-net removes network access. firejail's --net=none gives the process a new network namespace with only a loopback interface, and --private or --whitelist limit which home files it can see.
• Anthropic's sandbox-runtime (srt) was built for this use case; its README shows sandboxing the filesystem MCP server by changing command to srt and putting npx and the package in args, then setting filesystem.allowWrite, denyWrite, denyRead and network.allowedDomains in ~/.srt-settings.json. Writes and network are denied by default; reads are allowed by default until you add denyRead entries, so add them.

What does an egress allowlist for a local MCP server stop, and what doesn't it stop?

Exfiltration needs an exit. The MCP guide's default is no network for servers that don't need it, and an outbound firewall or egress proxy with a domain allowlist for the rest, logging attempts that fall outside it.

• A domain allowlist decides on the hostname requested. Allowing a broad domain (all of github.com, a public paste or storage host) leaves a place to send data. Keep entries to the exact API hosts the server calls.
• A sandbox does not fix a poisoned tool description or a prompt-injected agent calling an honest tool. Pair it with pinned versions, a reviewed tool list and confirmation on write tools.