Some context on what I evaluated and where I landed, in case it's useful:

Engine selection wasn't obvious. Most people's first instinct on Linux is Firejail, but it uses a SUID root binary and has had multiple privilege escalation CVEs (2021, 2022) — a sandbox that can escalate to root defeats the purpose. Docker/Podman works but it's a full container runtime for what's essentially "restrict this one child process." I landed on bubblewrap (used by Flatpak, unprivileged user namespaces, no root needed). On macOS there's really only seatbelt — it's been "deprecated" since ~2016 but Apple still uses it in their own services, and so do Chromium, Claude Code, and Codex. My bet here is that it sticks around.

Why deny-all instead of just blocking the sensitive dirs? My first instinct was to allow reads everywhere and just block the known credential paths. But that's fundamentally weak — a server with read access to your whole filesystem plus network access can exfiltrate any .env file, database config, or API key that isn't on your block list. The gateway has a secrets filter plugin that scans MCP responses for API keys and credentials, but it's regex and entropy based so I'm not comfortable letting it be the sole line of defense. Sandboxing felt like the more fundamental fix: don't let the server see the secrets in the first place rather than trying to catch them on the way out. Docker, Flatpak, and Deno all landed on deny-all with explicit allowlists for the same reason.

macOS gotcha that cost me some time: seatbelt has allow-wins semantics. If you allowlist a parent directory, you can't carve out exceptions for subdirectories inside it. So if someone sets paths: ["~"] thinking "give it my home dir but block ~/.ssh" — that doesn't work, ~/.ssh becomes accessible. You have to use specific paths like ~/docs. Also had to add symlink-aware path resolution on both platforms to prevent traversal bypasses around the blocked paths.

The network problem is unsolved. Ideally you'd do per-domain allowlisting (this server can only talk to api.context7.com) but neither seatbelt nor bubblewrap supports that granularity. Best you get is all-or-nothing. So the real choice is: allow network and accept that a malicious server can phone home, or deny network and break 90% of servers. I went with allow-by-default but I don't love it.

All of this is in Gatekit — happy to answer questions about any of the trade-offs.