MCP RCE Claims: The Protocol Is Not Your Sandbox
By wGrow Project Team ·
Invariant Labs’ 2025 MCP security analysis and Trail of Bits’ 2025 MCP review both describe the same failure pattern: treating a data-exchange specification as a security primitive.
MCP standardises how hosts, clients, and servers exchange context, advertise tools and resources, and return structured results. It does not create process isolation, enforce permission boundaries, or sandbox execution.
The STDIO Reality Check
The common local MCP transport is STDIO — standard input and standard output. An MCP server process sits on the local machine, reads JSON from stdin, and writes JSON to stdout. This is convenient for development. You can wire up a new tool in an afternoon, iterate fast, and skip the overhead of a network socket. The convenience is real. The illusion is that this transport carries any security properties whatsoever.
If your MCP server exposes a bash execution tool and that server runs under your user account on the host machine, the agent operating through it has your file permissions. It can read your .env files. It can write to your home directory. It can make network calls. The protocol did not grant those permissions — the operating system did, the moment you launched the process. A protocol cannot make an arbitrary shell command safe to execute. The kernel does not read your system prompt.
The failure mode is straightforward: application logic is being asked to enforce boundaries that belong at the process or OS layer.
The Gov Allowlist Misconception
Earlier this year we ran an architecture review for a vendor deploying an agentic document analysis system for a Gov related project. Their threat model rested on two controls: restricted system prompts and an API allowlist. The allowlist determined which tools the LLM could see. The prompts instructed the model to perform only read operations.
Neither of these is a security boundary.
An allowlist governs what the model is offered. It does not govern what the underlying tool can do when invoked. If the tool is a generic Python REPL — and in this case it was — the allowlist is cosmetic. The model sees a curated menu. The menu item labelled “run analysis script” executes arbitrary Python under the application’s service account. The fact that the prompt says “read only” is irrelevant. The runtime does not parse English instructions. The Python interpreter does not.
The fundamental error is one we keep seeing in agentic architecture reviews. Teams trust application logic to do the job of an operating system process boundary. Application logic can be bypassed. A jailbreak, a malformed input document, an indirect prompt injection embedded in a PDF the agent is asked to summarise — any of these can redirect the model’s tool selection. When the model issues a call to the Python executor, the executor executes. Intent does not propagate down the call stack.
Fixing Blast Radius in Infrastructure Provisioning
We made the same structural mistake with our own internal infrastructure provisioning crew. The wGrow agent stack manages parts of our AWS environment — Terraform plans, state validation, deployment readiness checks. The early deployment ran on generic MCP servers at the host level, one server instance handling multiple deployment-adjacent tools.
When we mapped the blast radius, the picture was stark. A successful prompt injection into the provisioning crew could rewrite Terraform state files or expose raw credentials stored in environment variables. Those credentials spanned multiple projects. A single compromised agent run could contaminate unrelated client environments. The tooling worked fine in testing. The threat model was wrong.
We scrapped the monolithic server and moved to Docker-isolated environments on a per-tool basis. Each tool the provisioning agent uses — Terraform plan execution, state validation, credential lookup — runs in its own ephemeral container with a dedicated, restricted IAM role and a filesystem mount limited to the relevant project directory. The MCP server routes the request to the appropriate container. The container executes, writes its output to stdout, and exits. The blast radius of any single compromised invocation is now bounded by the container’s IAM policy and its mount scope, not by the permissions of the host process — provided those policies are scoped correctly. A misconfigured IAM role defeats the isolation regardless of the container boundary.
This is not a novel architecture. It is how you would design any multi-tenant execution environment built on classical systems principles. We applied it late to our own agent crew. That is the honest version of events.
Implementing Ephemeral Tool Execution
The operational changes are not conceptually complex. They do require deliberate infrastructure work, and they introduce real maintenance overhead — something teams should plan for well before the first incident forces the issue.
Treat your MCP server as a switchboard, not a secure enclave. The server’s job is routing. Any tool that executes code, modifies state, or reads sensitive data must run in a separate process with a separate identity. The server routes the call. The isolated process handles the execution.
Adopt per-tool identities. If the agent needs to run Python, that execution happens under a restricted, dedicated user account or IAM role with no access to anything outside the scope of that specific tool’s function. If it needs to read an S3 bucket, that IAM role has s3:GetObject on exactly one bucket prefix. Not s3:*. Not account-wide.
Run code-executing tools in ephemeral, unprivileged containers. The container spins up, executes the payload, returns standard output to the MCP server, and exits. No persistent state between runs. No shell to maintain. If the container runs with a read-only root filesystem, no persistent volumes, and only tightly scoped writable mounts, a malicious payload has nowhere durable to establish persistence.
Enforce network egress at the container level, not the application level. A tool that processes local files has no legitimate reason to make an outbound HTTP request. Block it at the network layer. Do not rely on the LLM declining to make such a call. LLM behaviour is probabilistic. iptables rules are not.
The Operating System Remains the Final Boundary
AI frameworks will continue to abstract tool selection, chain-of-thought routing, and multi-agent coordination. They will not abstract away the Linux kernel. Least privilege, process isolation, and defined blast radius are not legacy concepts that modern tooling has superseded. They are the foundation that modern tooling runs on top of.
The question every team deploying agent infrastructure should be asking is not “which MCP servers does our model have access to?” It is “what can happen at the OS level if every tool the model can invoke is called with adversarial arguments?” Map that surface. Then build the containment before you build the feature.
Running tools natively via STDIO is appropriate for local development and nothing else. Production agent crews require fully containerised, ephemeral tool execution with per-tool identities and network egress controls. This is not a future best practice. It is the baseline missing from the designs described here: host-level tool execution, broad service-account permissions, and no hard egress boundary.
MCP is a useful protocol. It gives the ecosystem a shared vocabulary for LLM-to-tool communication. That is valuable. It is also the entire extent of what it provides. The security architecture is yours to build. The protocol will not build it for you.