Sandboxing & Isolation

An MCP server is code that an AI agent can invoke — which means it is an attack surface. Sandboxing restricts what that code can do even if it is compromised or misconfigured. Process isolation is the first layer: run each MCP server as a separate OS process with its own user account, limited file descriptors, and restricted system call access. On Linux, use seccomp-bpf to allowlist only the system calls your server needs. On macOS, use sandbox-exec profiles. The principle is least privilege: the server should have exactly the permissions it needs and nothing more.

Filesystem restrictions prevent MCP servers from reading or writing outside their designated directories. Bind mounts (Linux) or sandbox profiles (macOS) limit the visible filesystem to the project directory and essential system paths. Network policies add another layer: if your MCP server does not need outbound internet access, block it at the network namespace level. A filesystem MCP server has no business making HTTP requests, and a database MCP server has no business reading ~/.ssh/.

Container sandboxes provide the strongest isolation. Running each MCP server in its own Docker container or microVM (Firecracker, gVisor) gives you filesystem isolation, network isolation, resource limits (CPU, memory, I/O), and a clean teardown mechanism. The trade-off is latency — container startup adds 50-500ms depending on the runtime. For long-lived MCP servers this is negligible. For short-lived stdio servers that start and stop frequently, the overhead may be unacceptable. Choose the isolation level that matches your threat model.