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.

Comments

[Harjot Singh]

MCP servers being able to read your SSH keys is the kind of thing that sounds like an edge case and is actually the whole security model of agents in miniature: the moment you connect a tool to an agent, that tool runs with whatever access the host process has, and unless something scopes it down, an MCP server (or a compromised/over-broad one) inherits the keys to the kingdom. The fix being a real fix and not a please-be-careful is the important part, because this can't live in the model's judgment. An agent can be prompt-injected into asking a tool to do something awful, so the boundary has to enforce least privilege structurally: the tool gets exactly the filesystem, network, and credential scope it needs and nothing more, sandboxed so reading ~/.ssh isn't even reachable, not merely discouraged. That's the same principle as not running your web server as root, applied to tools an autonomous, manipulable agent can invoke. The threat model is genuinely worse than a normal app because the caller is non-deterministic and can be talked into things. Least privilege at the tool boundary, enforced by the system, not the prompt is the takeaway. That sandbox-the-tool-not-trust-the-agent instinct is core to how I think about MCP security in Moonshift. Beyond the SSH-key fix, are you sandboxing MCP servers per-tool (filesystem/network scoping), or relying on the host's default permissions?