Sandboxed execution
Preview — part of the MCP Gateway private beta. Join the waitlist →
Most MCP servers are third-party code you didn't write. The Gateway runs them in a sandbox so an untrusted server can't read secrets it was never given or touch the rest of your machine.
Two levels
| Level | Isolation | When |
|---|---|---|
| L1 — environment scoping | The server process receives only the environment variables you allow (an allowlist) — not your whole environment. In-process, zero overhead. | Default for every server. |
| L2 — container isolation | The server runs inside a constrained Docker / Podman container: no host filesystem, dropped capabilities, and a network policy. | Opt-in, or automatic for community / unknown-tier servers. Falls back to L1 if no container engine is available. |
Verified and trusted servers stay on the fast path (L1); unknown ones can be fully contained (L2).
Capability manifests
Each server has a capability manifest — the environment variables it may see and the network hosts it may reach. Defaults come from the server's trust tier; you can override them per server with the mcp_sandbox meta-tool.
Example
# Run with container isolation enabled for untrusted servers
MCP_GATEWAY_CONTAINER_ISOLATION=true npx @mcprating/gateway
See also
- Egress allowlist — the network half of the sandbox.
- Access types — which servers can be sandboxed and how.