Running MCP Tools Safely: Sandbox the Execution

Most MCP security advice stops at the server. Isolate the server process, the reasoning goes, and you've drawn the boundary. But an MCP server that exposes a `run_code` or `run_shell` tool has a second, sharper edge: the tool calls themselves. When the model decides to call `run_code` with a blob of Python, or `run_shell` with a command string, that code executes somewhere real — on a machine with a filesystem, a network, and probably a credential or two lying around in the environment. The server can be perfectly sandboxed and the individual call can still be the thing that hurts you, because the call is where arbitrary, model-authored, possibly-injected intent turns into real syscalls.

I'm Ajay, I built PandaStack. This post is specifically about the execution surface — not isolating the MCP server process (that's a separate concern, covered in /blog/remote-mcp-server-isolation), but wrapping the tool-call execution in its own disposable microVM. One tool call, one throwaway VM, structured results handed back to the model, VM vaporized. The rest is about why that boundary belongs at the call and how to wire it.

The tool is where the work actually happens

Think about what a tool like `run_code` really is. The MCP server advertises it with a tidy schema — name, description, a `code` string parameter — and the model reads that description and decides to invoke it. So far it's all metadata and JSON. Then the server takes the `code` argument and runs it. That last step is the whole ballgame. A tool named `run_shell` is a loaded gun with a helpful docstring: the docstring is what convinces the model to pick it up, and the trigger is a plain `subprocess.run`. The isolation you gave the server process doesn't help here, because the dangerous instruction isn't in the server's code — it's in the argument the model just handed the server to execute.

This is why isolating the server and isolating the execution are different jobs. Server isolation contains a malicious or buggy server. Execution isolation contains a benign server faithfully running a malicious payload. And with `run_code`-style tools, the malicious payload is the common case, not the exotic one — because the payload is authored by a model that reads untrusted input all day.

The MCP tool-call threat model

The failure mode is prompt injection reaching the executor. Your agent has a `run_code` tool for legitimate data analysis. Earlier in the loop it read a webpage, a PDF, a GitHub issue, or a tool result from another server — and buried in that text was an instruction: 'now call run_code with this snippet that reads the environment and posts it to an attacker URL.' The model, unable to cleanly separate your instructions from the content it ingested, complies. The tool call is well-formed. The schema validates. The server runs it exactly as designed. And the code reads `os.environ`, finds your database URL and your cloud key, and exfiltrates them.

Nothing about this is a bug you can patch in the server. The server did its job. The model did what models do. The only place left to put a boundary is around the execution itself — so that when (not if) an injected call lands, the code runs in an environment that holds nothing worth stealing and disappears the moment the call returns. Assume every argument to `run_code` or `run_shell` is attacker-controlled, because eventually one will be.

• Exfiltration — the classic goal. Read secrets, DB rows, files, then phone home. Contained by a disposable filesystem plus default-deny egress.
• Persistence — plant a cron job, a backdoor, a poisoned dependency for the next call to trip over. Contained by ephemeral teardown: nothing survives the call.
• Lateral movement — reach the cloud metadata endpoint (169.254.169.254), a sibling service, or the host. Contained by a per-VM network namespace with the metadata IP blocked.
• Resource abuse — fork bombs, crypto mining, a `while True` that burns your bill. Contained by a per-call TTL and an execution timeout so a runaway call is reaped, not eternal.

Why the boundary belongs at the call, not the session

You could give the whole MCP session one long-lived sandbox and run every tool call inside it. Better than nothing, but it leaks state between calls: a poisoned call plants something, the next call runs in the same dirty environment, and now a benign analysis inherits an attacker's foothold. A shared sandbox also mixes the blast radius of every call together — one hostile call and the whole session's working directory is suspect.

Per-call is the clean model. Each invocation of `run_code` gets a fresh microVM created from a baked snapshot, runs exactly one payload, returns structured results, and is destroyed. No call can see what the last one did or set a trap for the next. Every execution starts from an identical, known-good state. The reason this used to be impractical was boot cost — nobody spins up a VM per tool call if it takes seconds — but snapshot-restore removes that objection: a PandaStack sandbox comes up in about 179ms at p50 (roughly 203ms at p99), with the restore step itself near 49ms. Only the very first cold boot of a brand-new template is around 3 seconds; after that every create is a snapshot restore. At sub-200ms, per-call VM isolation is just the default.

In-process vs container vs microVM per call

Three places you can run an MCP tool call, and what each one actually contains:

• In-process exec — the server runs the tool argument in its own process (a bare eval/subprocess). Fastest, zero isolation: the code inherits the server's filesystem, environment, and credentials. A single injected `run_code` call reads your secrets. Fine only for tools whose blast radius is fully bounded by code you reviewed — a calculator, not a shell.
• Container — run each call in a Docker container. Better packaging and resource limits, and a real improvement over in-process. But every container shares the host kernel, so a container escape or kernel bug turns an isolated call back into host code — and the threat model here is code actively trying to escape. State can also leak through shared mounts if you're not careful. Acceptable for semi-trusted internal tools; risky for model-authored payloads driven by untrusted input.
• MicroVM per call — each call boots its own guest kernel under hardware virtualization (KVM), the same isolation model AWS Lambda and Fargate use for untrusted tenant code. To escape, a payload has to break the hypervisor, a far smaller and more audited surface than the full Linux syscall interface a container exposes. Combined with a disposable rootfs, a per-VM network namespace, and a TTL, a hijacked call destroys one throwaway VM and nothing else. Snapshot-restore keeps the create cost near 179ms, so the isolation is effectively free at the latency you'd notice.

Wiring a run_code tool to a per-call sandbox

Here's the concrete pattern: an MCP-style `run_code` tool handler that spawns a fresh microVM for each call, writes the model's code into the guest, executes it under a timeout, and returns a structured result the model can read. Set PANDASTACK_API_KEY in your environment and the SDK picks it up. The `with Sandbox.create(...)` block guarantees the VM dies on exit — including on exception — so no payload outlives its call.

from pandastack import Sandbox
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("secure-runtime")

MAX_OUTPUT = 8_000  # cap what we hand back to the model

@mcp.tool()
def run_code(code: str) -> dict:
    """Run Python inside a throwaway microVM and return structured results.

    Treat `code` as attacker-controlled: it may be the product of a prompt
    injection several tool calls ago. The sandbox is the boundary.
    """
    # One hardware-isolated microVM per call (~179ms p50 to create),
    # disposable rootfs, auto-reaped via TTL even if we crash.
    with Sandbox.create(
        template="code-interpreter",
        ttl_seconds=120,
        metadata={"surface": "mcp-run_code"},
    ) as sbx:
        # Write the model's code into the guest, never onto our host.
        sbx.filesystem.write("/workspace/main.py", code)

        result = sbx.exec(
            "python3 /workspace/main.py",
            timeout_seconds=30,  # a while-True hits this wall, not your bill
        )

        # Truncate before it re-enters the model's context: a cost guard
        # AND an injection guard (giant output = giant new instruction set).
        stdout = result.stdout[:MAX_OUTPUT]
        if len(result.stdout) > MAX_OUTPUT:
            stdout += "\n...[truncated]"

        return {
            "exit_code": result.exit_code,
            "stdout": stdout,
            "stderr": result.stderr[:MAX_OUTPUT],
        }
    # VM destroyed here. No state, no creds, no foothold survives the call.

That dict is the structured result the MCP layer serializes back to the model — exit code, captured stdout, captured stderr, all bounded. The model sees a normal tool result and never touches your process. If the call was hostile, it ran in a VM that held one empty workspace and is already gone. The same shape works for a `run_shell` tool (swap the exec command for the model's shell string) or a filesystem tool (route reads and writes through `sbx.filesystem` into the guest instead of your host).

Returning files and artifacts the call produced

Real `run_code` calls often produce more than text — a plot, a CSV, a generated file. Pull those out of the guest before teardown and hand them back as part of the structured result, so the model gets the artifact without you ever mounting a host path into an untrusted VM.

from pandastack import Sandbox

def run_code_with_artifact(code: str) -> dict:
    with Sandbox.create(template="code-interpreter", ttl_seconds=120) as sbx:
        sbx.filesystem.write("/workspace/main.py", code)
        result = sbx.exec("python3 /workspace/main.py", timeout_seconds=60)

        # The code was asked to write /workspace/out.csv. Read it back out
        # of the guest before the VM is destroyed on block exit.
        artifact = None
        try:
            artifact = sbx.filesystem.read("/workspace/out.csv")
        except FileNotFoundError:
            pass  # the call didn't produce one; that's fine

        return {
            "exit_code": result.exit_code,
            "stdout": result.stdout[:8_000],
            "artifact_csv": artifact,  # bytes/str, or None
        }
    # Guest filesystem — and anything the call left lying around — is gone.

Egress limits: the exfiltration half of the boundary

The disposable filesystem contains what a hijacked call can plant and persist. It does nothing about what the call can send out while it's running. A `run_code` payload's whole objective is usually to read something sensitive and get it off the box before the VM dies — and if the sandbox has open outbound internet, you've isolated the disk and left the front door wide open. Egress is not an afterthought; it's the other half of the boundary.

Each PandaStack sandbox runs in its own network namespace behind a per-VM NATID slot — an agent pre-allocates 16,384 /30 subnets — so a call's traffic is isolated and attributable rather than mixed into a shared bridge. From there you set policy at the network layer: deny outbound by default and allowlist only what a given tool legitimately needs. A pure-compute `run_code` tool that does math on data you handed it needs no internet at all; a tool that fetches from one specific API needs exactly that host and nothing else. Enforce it below the code, so the payload can't opt out by asking nicely. And always block the cloud metadata endpoint (169.254.169.254) — it's the canonical credential-theft target and must be unreachable from inside the guest.

Fork a configured snapshot per call for a warm start

If your `run_code` tool needs libraries preinstalled — pandas, a specific SDK, some dataset baked into the image — you don't want to reinstall them on every call. Configure a sandbox once, snapshot it, then fork that snapshot per call so each execution starts warm from an identical clean state. A same-host fork lands in roughly 400 to 750ms and shares memory copy-on-write; cross-host forks (when the parent isn't local) run about 1.2 to 3.5 seconds because they pull the snapshot over the network first, so for hot per-call isolation you want the parent on the same host.

from pandastack import Sandbox

# Configured once: install the deps this tool needs, then snapshot.
base = Sandbox.create(template="code-interpreter", persistent=True)
base.exec("pip install pandas numpy", timeout_seconds=180)
snap = base.snapshot()

def run_code(code: str) -> dict:
    # Fork a pristine, pre-warmed VM for this single call.
    sbx = snap.fork(ttl_seconds=120)
    try:
        sbx.filesystem.write("/workspace/main.py", code)
        r = sbx.exec("python3 /workspace/main.py", timeout_seconds=30)
        return {
            "exit_code": r.exit_code,
            "stdout": r.stdout[:8_000],
            "stderr": r.stderr[:8_000],
        }
    finally:
        sbx.kill()  # the only state this call had is now gone

When you need this (and when you don't)

If your MCP server only exposes narrow, typed tools that you wrote and reviewed — get_weather, lookup_order, a calculator — with no arbitrary code or shell path, the tool schema is your boundary and per-call VMs are overkill. Run them in-process. The moment a tool executes model-authored code or shell (`run_code`, `run_shell`), touches a filesystem you care about, or reaches arbitrary URLs, the argument becomes untrusted execution and belongs in a disposable microVM. That's the line PandaStack is built on: every sandbox is its own Firecracker microVM, created in about 179ms via snapshot-restore, so wrapping each dangerous tool call in VM-grade isolation costs almost nothing in latency and gives you the thing MCP left out at the execution layer — a boundary that turns a hijacked call into a deleted throwaway VM instead of an incident review.