Isolating MCP servers in sandboxes: Tech Insider's 13-step guide

The MCP specification dated 2026-07-28 deprecates the HTTP+SSE transport and mechanisms such as roots, sampling and logging. GitHub's official MCP server has shipped six releases in October alone, reaching v2.0.3 on the 21st. With that pace of change, Tech Insider today published a 13-step guide to isolating MCP servers in sandboxes instead of running them on the developer's machine.

It is written by Elias Virtanen, a cybersecurity analyst at the outlet, and starts from a premise anyone who has connected third-party servers to Claude Desktop or Claude Code will recognize: without isolation, a single injected prompt can compromise user data or the underlying infrastructure. The full version on the Tech Insider website includes configuration examples for each step.

What the guide proposes

The 13 steps fit neatly into four groups.

Threats and architecture. The starting point is documenting the failure modes: prompt injection, malicious MCP servers, tool poisoning, credential theft, data exfiltration and sandbox escape. The guide also cites MCP-2026-015, an issue in the instructions field of `server/discover` that allows content injection and gets worse when responses are cached with `cacheScope: public`. The reference architecture chains the agent runtime, a policy gateway, the MCP server, an isolated executor, network egress control and output sanitization.

Isolation technology. It compares gVisor, which intercepts syscalls in user space, Firecracker, with one microVM per workload, and Kubernetes Agent Sandbox for cluster-scale orchestration. It then moves to specific providers. E2B offers a Hobby plan with 100 dollars of free credit, one-hour sessions and 20 concurrent sandboxes, and a Pro plan at 150 dollars a month with 24-hour sessions. Cloudflare launched its Sandbox SDK 1.0 on 30 September, and the guide recommends migrating even though the 0.x line still receives patches.

Configuration and credentials. Disable unused tools, restrict the server to explicit paths, declare the specification version and enable `denySymlinkEscape`. Authenticate with a bearer token on every transport, including localhost, with tokens scoped to specific tools. Restrict network egress with a host allowlist (the example uses `api.github.com` and `pypi.org`) and test it against SSRF, DNS rebinding and redirect chains. Issue credentials per session and revoke them when the sandbox closes, not when they expire; for this it mentions E2B's Secrets feature, available since 7 October.

Operations. Treat all tool output as potentially hostile and do not let the agent interpret it as a new instruction. Require human approval for consequential actions (write, deploy, delete) and let read-only ones run automatically. Log the tool name, arguments, session ID, duration, exit code and network destinations. And tear down each sandbox inside a `try/finally` block with a hard timeout so no sessions are left orphaned.

Why it matters

Many MCP servers are installed with one command and a few lines in `claude_desktop_config.json`, and run with the same permissions as the user. That is convenient for testing and risky once real data is involved. The guide does not invent new techniques: it gathers well-known container security practices and applies them to a scenario where the attacker can get in through the text the model reads.

For us, the most useful parts are steps 8 and 9. Network egress control and per-session credentials shut down most exfiltration scenarios even if everything else fails. Steps 11 and 12 fit well with Claude Code: per-tool permissions and the `PreToolUse` and `PostToolUse` hooks make it possible to build approval gates and logging without extra infrastructure.

Who it is for

Teams exposing their own MCP servers to agents in production.
Developers who install community servers without reviewing their code.
* Security leads who have to decide which servers are allowed inside the company.

For individual use with two or three trusted servers, the 13 steps are overkill. Starting with the network allowlist and narrowly scoped tokens already covers a good part of the risk.

It is a reference guide more than a piece of news, and that is where its value lies. The MCP ecosystem is moving faster than its security practices, and having an ordered checklist to audit your own setup is a good place to start.