MCP Server Examples Worth Running in a Sandboxed Environment

Connecting an MCP server to an agent is not a settings change. MCP, the standard Anthropic released in November 2024, exposes callable functions over a JSON-RPC interface, and when an agent connects to a server, that server is a real program, either a subprocess on the local machine or a remote process running on someone else's infrastructure. It runs code, opens sockets, and reads whatever sits in its environment, exactly the way any other piece of software does.

The distinction between a local and a remote MCP server matters because it changes who is being trusted and with what. A remote server is an HTTP endpoint someone else runs, so the trust extends not just to their code but to their operational security: how they patch, how they store their own secrets, who has access to their deployment pipeline. The protocol itself has nothing to say about either case. Whatever boundary exists comes entirely from the runtime the server happens to run inside.

This gets obscured by how people actually install these things. But the framing around it, "connect my agent to Slack," sounds like flipping a switch, not like granting a stranger's code a shell on the machine. That gap between the language and the mechanism is where most of the risk in this article originates.

It also lets a trusted but lower-privileged process trick a more privileged one into misusing its authority: traditional role-based access control cannot catch this, because RBAC checks whether the requesting process is who it claims to be. Every category examined in this piece, filesystem access, credentials, shell commands, API calls, package installs, is a variation on that same structural gap.

What a sandbox enforces

A plain Docker container does not count as a sandbox for untrusted MCP server code. Pinning down what a real sandbox provides gives the word a precise meaning for the rest of this piece, before naming specific dangerous server categories.

A proper sandbox gives five things at once. Deterministic teardown means the whole environment can be destroyed completely when the work is done, with nothing left behind to carry into the next run.

Different isolation technologies deliver different amounts of this. A microVM built on hardware virtualization, the Firecracker model, gives untrusted code its own kernel, making an escape mean defeating the hypervisor. That is the right assumption to build around when the code might genuinely be hostile. WebAssembly and capability-based models are the lightest-weight option, useful when the code can be targeted to WASM, though that rules out most of what an MCP server actually runs, arbitrary Python, arbitrary shell commands, the kind of general-purpose code these servers are built from.

Two criteria matter more for MCP specifically than for sandboxing code in general. And controlled egress has to be part of the boundary from the start: locking down the disk while leaving outbound internet wide open only solves half the problem, since a server can still read local files and quietly ship them somewhere else.

Filesystem MCP servers: read and write access that spans the entire host tree

Filesystem MCP servers are the clearest place to see this argument play out, because the risk requires no special imagination. A filesystem MCP server exposes tools that read, write, move, and delete files, and when it runs on bare metal, its reach is bounded only by the OS permissions of whatever process spawned it. In a typical developer environment, that means the entire home directory and anything mounted alongside it, not just the project folder the agent was supposed to be working in.

The exfiltration path is direct and doesn't require a sophisticated exploit. Without sandboxing, the execution environment already has access to the full host filesystem, so the key simply leaves in the agent's own output, no separate vulnerability required.

Writes carry the same risk. A hallucinated or injected write or delete operation executes the moment it's issued and can't be undone after the fact. The agent has no reason to pause for confirmation, because a destructive tool call looks structurally identical to a routine one at the point of invocation.

Sandboxing changes what the server can even see. One objection comes up often here: why not just configure the server to a restricted path at the application level? Because a path restriction set in application code is not a kernel boundary. A hardware boundary, by contrast, is not something application code can step around.

Credential and secrets MCP servers: environment variables as an attack surface

Once filesystem access is on the table, the next target an attacker or a misbehaving agent reaches for is credentials, because that's where the real value sits. Environment variables are the standard way cloud infrastructure delivers credentials, and AWS_SECRET_ACCESS_KEY, database connection strings, and API tokens all sit in the environment of the process that launched the MCP server. A compromised or malicious server can read every one of them without needing a separate exploit.

This is what makes tool poisoning such a low-effort attack. Without sandboxing, that tool inherits whatever permissions the agent process already holds, and the hidden instructions ride along on that inherited trust.

Two documented incidents show what this looks like in practice. The root cause wasn't a bug in the server's code. It was architectural: a token scoped far wider than the task needed, paired with an agent that had no way to tell legitimate instructions apart from text smuggled in through the data it was reading. Wiz Research separately disclosed flaws in the Amazon Q VS Code extension, where a malicious repository could trigger credential theft through a crafted workspace MCP configuration file. The MCP server processes spawned in that scenario inherited the full developer environment, which handed the attacker immediate access to cloud infrastructure.

A session holds only the credential a specific operation requires, and that credential disappears at teardown, so a compromised server can only ever steal what that one session was given.

Shell-access MCP servers: arbitrary command execution with no natural boundary

Shell access removes whatever boundaries the earlier categories still had, because a shell can touch files, read credentials, and open network connections all through one tool call. The tool call looks the same either way.

Command injection is the dominant vulnerability class here. Researchers examining MCP implementations have found that a substantial share expose APIs susceptible to command injection, often because a parameter that should have been validated gets passed straight into a shell call. The risk includes attacks that come from inside, too. The blast radius is whatever the run can reach, regardless of whether the model was manipulated or just mistaken.

The reason that statefulness doesn't turn into a liability is the sandbox wrapped around it. Inside a guest kernel, the worst command imaginable, something like rm -rf / aimed at the guest, destroys only that disposable VM. The host is untouched, and a fresh sandbox can be ready again in well under a second.

External API MCP servers: lateral movement through inherited network access

Shell access and filesystem access are local problems. Network access turns the same risk into something that spreads. A compromise that starts at a chatbot can end as a breach of the internal network.

A compromised server with open network access can scan internal services, make authenticated requests to other microservices using service mesh credentials it inherited rather than requested, and work its way deeper into the infrastructure from there. Locking down the filesystem while leaving outbound internet access open is only half a boundary, because a server that can send a POST request to an external endpoint can exfiltrate everything the agent has touched, no matter how carefully the disk access was scoped.

None of this requires a vulnerability in the server's own code. The attack surface isn't just the provider's own code, it's every dependency sitting in that server's package tree, each one auto-updating on its own schedule, none of them reviewed before every single tool call.

Package-installation MCP servers: supply-chain risk executed at agent request

The last category removes the last constraint: servers that install packages at runtime decide what code to run after the fact, not before. The agent chooses at runtime which library a task needs, then installs it, and whatever runs after that was never reviewed at deploy time and may never be reviewed.

This breaks an assumption that older application security models depend on. Autonomous agents generate and execute new code at runtime based on natural language input, which creates a risk surface that those older controls were never built to handle.

The SmartLoader incident shows what this looks like when it actually happens. Attackers cloned the legitimate Oura MCP project and distributed a trojanized version through public MCP registries, building fake forks and fake contributors to make the clone look credible. CVE-2025-6514, rated 9.6 on the CVSS scale, shows the same risk one level up the stack: it affected mcp-remote, a widely used proxy package, across a very large number of installed environments. That vulnerability sat in a piece of shared infrastructure that most users never chose directly, proving that supply-chain risk in this ecosystem isn't limited to servers people pick themselves.

Running package installation inside a disposable guest VM contains this cleanly. The installed code gets access only to the guest's own filesystem and whatever egress rules were granted for that session, and once the task finishes, the guest is destroyed along with every package it installed, leaving nothing behind for the next session to inherit.

Sandboxed execution is structurally necessary across all five categories

These five categories, filesystem, credentials, shell, API, package installation, are not five separate problems that happen to share a chapter. They are five expressions of one root condition: ambient authority. A process automatically inherits all the background permissions available to it, because that is simply how processes work under a traditional operating system model, not because any single operation needs all of them.

Sandboxing has to contain three failure modes at once, and they are not interchangeable. The model can be wrong, confidently doing the wrong thing with no malicious input involved. The model can be steered, where prompt injection arriving through a web page, a document, or a tool result redirects the agent's behavior using its own legitimate permissions. And the code itself can be exploited, since parsers, package installers, and headless browsers carry their own vulnerabilities, and a malicious PDF or a poisoned dependency can turn an ordinary tool call into remote code execution regardless of what the model intended.

Application-layer controls, restricted paths, scoped tokens, rate limits, are worth having but don't close this gap on their own. A bug in the server's code, a substituted dependency, or an injected instruction that steers the agent into misusing its own legitimate access can defeat all three. But that objection collapses for the five categories this piece has walked through, because in each case the code wasn't written by the team running it, it auto-updates on its own schedule, it processes input an attacker can reach, and it runs with the full permission set of the agent process. Those four conditions together are what make hardware isolation the right default, not a stylistic preference.

Structuring a sandboxed MCP server runtime: the four walls that hold

Knowing that sandboxing matters doesn't by itself tell a team how to build one that actually holds. A sandbox that works for untrusted MCP server code needs four properties beyond raw isolation strength, and skipping any one of them leaves a gap the other three can't cover on their own.

The first wall is one disposable environment per session. A fresh boundary for each execution guarantees that nothing persists that shouldn't.

The second wall is scoped credentials per operation. A session holds what it was granted and loses it the moment that session ends.

The third wall is controlled egress. A server that physically cannot reach an endpoint cannot exfiltrate anything to it, no matter what instructions it's been given.

The fourth wall is deterministic teardown. The sandbox needs to be destroyable completely, with no residual state surviving into the next run. This matters most acutely for package-installing servers, where teardown has to eliminate every installed artifact so a poisoned package in one session has no way to contaminate the next.

None of this rules out statefulness where it's genuinely needed. Statefulness and isolation both hold together when the boundary sits at the hardware level. And auditability needs to run through all of it: every tool call the server makes inside the sandbox should be logged with its inputs, outputs, and a timestamp, because for compliance-sensitive workloads, a detailed record of what code ran, when, and what it touched isn't optional. The sandbox is the only layer positioned to produce a trustworthy audit trail for code the team running it didn't write itself.

Purpose-built runtimes for sandboxed MCP servers

The question of which platform to run this on should come down to the isolation model it offers, not its startup latency or its feature list.

A few criteria matter specifically for MCP server hosting, building on the isolation argument laid out earlier in this piece. And compliance posture matters for production workloads: audit logging, and certifications like SOC 2, HIPAA, or GDPR readiness, depending on what the workload touches.

A handful of platforms illustrate what this looks like today. Vercel Sandbox, generally available as of January 2026, also uses Firecracker microVM isolation, with sub-second starts and billing tied to active CPU use. OpenAI, Nvidia, Manus, Nous Research, and OpenClaw are listed as launch partners.

Which of these fits depends on what's being run. In 2026, meeting that default no longer costs the latency it once did.