Your MCP servers can read your SSH keys. Anthropic just fixed that.

Every MCP server you run locally executes with your full filesystem and network permissions. That means the GitHub MCP server, the Slack one, that third-party tool you installed from npm last week — all of them can read your SSH keys, .env files, and credential stores by default.

Anthropic just open-sourced the fix: sandbox-runtime, the sandboxing layer they built for Claude Code. One-line wrap, no Docker, OS-level enforcement.

What actually changed

srt (the Sandbox Runtime CLI) enforces filesystem and network restrictions on any process using native OS primitives:

• 
  macOS: Uses sandbox-exec with dynamically generated Seatbelt profiles


• 
  Linux: Uses bubblewrap for containerization + network namespace isolation


• 
  Network filtering: HTTP/HTTPS traffic routes through an HTTP proxy; other TCP goes through SOCKS5 — both enforce your domain allowlists

Install it:

npm install -g @anthropic-ai/sandbox-runtime

Wrap an MCP server in your .mcp.json — change command from npx to srt, move the rest to args:

{

  "mcpServers": {

    "filesystem": {

      "command": "srt",

      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]

    }

  }

}

Then configure what the process is actually allowed to touch in ~/.srt-settings.json:

{

  "filesystem": {

    "denyRead": ["~/.ssh"],

    "allowWrite": ["."],

    "denyWrite": ["~/sensitive-folder"]

  },

  "network": {

    "allowedDomains": ["api.github.com", "*.npmjs.org"]

  }

}

The result: the MCP server can work in your project directory, talk to the domains it needs, and nothing else.

Why this matters

The threat model is real. An MCP server running compromised code — or simply a server with more ambient access than it needs — can exfiltrate your SSH keys, read your .env files, or phone home to arbitrary hosts. This isn't theoretical; it's the same class of supply-chain risk that exists for any untrusted npm package, except MCP servers are typically long-running processes with broad system access.

srt is designed secure-by-default: processes start with minimal access, and you explicitly poke holes for what they need. That's the right mental model — not "trust then restrict" but "deny then allow."

The dual isolation model

Both isolation layers are required because they protect against different escape paths:

• 
  Without filesystem isolation: a compromised process exfiltrates credentials it can read


• 
  Without network isolation: a compromised process sends those credentials out, bypasses restrictions with direct connections

The proxy-based network model is clever: on Linux, the sandboxed process has its network namespace removed entirely, so all traffic must go through proxies on the host. On macOS, the Seatbelt profile restricts connections to a specific localhost port where the proxies listen. There's no in-process hook to bypass.

What to do

• 
  Running any MCP servers locally? This is worth setting up now. Start with denyRead: ["~/.ssh"] and an empty allowedDomains list — see what breaks and add back only what's needed.


• 
  Building an MCP server? Publish a recommended srt config alongside your server. It's a trust signal, and it documents what your server actually needs.


• 
  Building an AI agent platform? The SandboxManager is available as a library — you can wrap spawned processes programmatically.

It's tagged as a beta research preview, so the config format may shift. But the core primitive is solid, and the source code is there to audit.

Source: anthropic-experimental/sandbox-runtime · Anthropic Claude Code Sandboxing Docs

✏️ Drafted with KewBot (AI), edited and approved by Drew.