A sandbox is no longer an optional extra for teams running AI agents in production. By October 2026, the Model Context Protocol ecosystem has racked up a string of disclosed vulnerabilities, and security researchers keep finding new ways an untrusted prompt can turn a helpful tool call into a breach. This tutorial walks through building an AI agent sandbox step by step, using the isolation tools that are actually shipping right now: E2B’s microVM runtime, Cloudflare Sandbox, Vercel Sandbox, and the Kubernetes Agent Sandbox project. By the end you will have a working, isolated execution path for MCP tool calls that limits what a compromised or manipulated agent can actually touch, and a repeatable way to apply the same cybersecurity rigor to every new MCP integration you add.
This is a hands-on guide, not a theory paper. Every version number, price, and vulnerability ID below comes from vendor documentation, changelogs, or CVE records current as of October 22, 2026. Where a tool is still in preview or a feature is scheduled for deprecation, that status is called out explicitly, because shipping an agent sandbox on top of a retired API is its own security incident waiting to happen.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why AI Agent Sandboxes Became Cybersecurity’s Top Priority in 2026
Model Context Protocol turns a chat model into something that can read files, run shell commands, hit APIs, and touch production databases. That power is exactly why MCP security researchers have spent 2025 and 2026 cataloguing concrete failures rather than hypothetical ones. Reports have pointed to flaws in developer tooling used to debug MCP servers, as well as weaknesses in reference server implementations that let unsanitized arguments or crafted path values escape the boundaries a server was supposed to enforce. Security teams now call this pattern capability laundering: a server looks scoped to one repository or resource in its description, then a later tool parameter quietly expands access to the whole filesystem.
Simon Willison, the software developer and author who has tracked prompt injection attacks since they were first described, put the underlying logic plainly: “I agree with Johann’s conclusion here: the only safe way to run agents if there’s any risk of attracting the attention of an adversarial attack is with a sandbox.” His companion recommendation is just as direct: “Run unattended coding agents in a container, VM or OS sandbox.” That advice has become the baseline assumption behind every credible MCP deployment guide published in 2026, including OpenAI’s own security guidance, which tells teams to run workloads that must not share data in separate environments rather than relying on application-level isolation alone, and to restrict outbound traffic to only the endpoints an executor actually needs.
Researchers at Snyk Labs frame the stakes in terms every engineer can picture: “A Prompt Injection Vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways.” Their analysis of MCP-connected systems goes further, warning that “without strong isolation and sandboxing, a single injected prompt could compromise user data or even the underlying infrastructure,” and their top mitigation is one line long: “If you’re running MCP servers locally, isolate them from your main environment.” That is the entire premise of this tutorial, turned into thirteen concrete steps, and it pairs directly with a broader approach to defending AI agents from prompt injection at every layer of the stack, not just the execution boundary.
Prerequisites: Tools, Versions and Accounts You Need
You do not need every tool listed here for every deployment path. Pick the isolation layer that fits your infrastructure (managed sandbox provider, Cloudflare Workers, or self-hosted Kubernetes) and skip the prerequisites for the paths you are not using.
- A recent Node.js or Python runtime, since E2B’s SDK requires an up to date runtime version to work correctly
- The current E2B SDK,
[email protected]or later, which added ordered streaming input for commands and PTY sessions - An E2B account; the Hobby tier includes a one-time $100 usage credit, sessions up to one hour, and 20 concurrent sandboxes with no credit card required, while Pro runs $150 per month plus usage and raises the session cap to 24 hours and concurrency to 100 (expandable to 1,100)
- A Cloudflare account, plus the
@cloudflare/sandboxpackage; Cloudflare’s changelog says Sandbox SDK 1.0 is now available, while the legacy Sandbox SDK 0.x line keeps receiving bug and security fixes for existing deployments - A Vercel account with a linked project if you are using Vercel Sandbox; Secure Compute, which adds static-IP egress and private AWS VPC access through VPC peering, is an Enterprise add-on introduced September 30, 2026
- kubectl and a Kubernetes cluster if you want the self-hosted route through Kubernetes Agent Sandbox, which supports the
agent-sandbox-rlPython package and multi-cluster warm-pool orchestration - An MCP host that supports the current specification: VS Code 1.101 or newer, Claude Desktop, Cursor, or Windsurf all support remote MCP servers
- Familiarity with the MCP 2026-07-28 specification revision, which moved the protocol from a stateful, session-based model toward a stateless request and response design with a new
server/discovermethod - Basic comfort with seccomp, AppArmor, or SELinux if you plan to run your own container isolation layer instead of a managed sandbox provider
One housekeeping note before you start: the MCP specification deprecated several legacy mechanisms in the 2026-07-28 release, including roots, sampling, logging, and HTTP+SSE transport. If you are extending an existing MCP server rather than building from scratch, check whether it still depends on any of those before you wire it into a new sandbox architecture, since the official changelog still labels 2026-07-28 as the current, “latest” revision as of October 21, 2026.
Step 1 and Step 2: Map the Threat Model and Design Your Reference Architecture
Step 1: Map the threat model. Before touching any sandbox SDK, write down what a malicious or manipulated agent could actually do with the tools you are about to grant it. The current MCP threat model, documented by groups including the Coalition for Secure AI, centers on failure modes including prompt injection from untrusted content, malicious or compromised MCP servers, tool poisoning where a server’s own description lies about its scope, credential theft through overly broad tokens, data exfiltration through network egress, and sandbox escape where the isolation boundary itself fails. Each of the risks described in the previous section maps to one of these categories, which is a useful exercise in itself: capability laundering is tool poisoning, an unauthenticated listener is an unauthenticated-listener failure, and a broken isolation boundary is a sandbox escape.
A newly disclosed issue tracked as MCP-2026-015 adds a seventh failure mode specific to the stateless 2026-07-28 protocol: the server/discover method’s instructions field can itself carry a prompt injection payload, and the risk gets worse when cacheScope: public is set, because a poisoned discovery response can then be served to every client that queries that server. Treat discovery metadata as attacker-controlled input, not as trusted configuration, until you have validated it yourself.
Step 2: Design a sandboxed reference architecture. With the threat model in hand, lay out the request path before writing code. A defensible architecture looks like this: agent runtime, then a policy gateway that checks the requested tool call against an allowlist, then the MCP server itself, then an isolated executor (your sandbox), then a controlled network egress point, and finally structured output that gets sanitized before it goes back to the model. The sandbox sits between the MCP server and anything that could do real damage; it is not a replacement for authenticating the MCP server itself, and it is not a substitute for validating tool arguments before they ever reach the executor.
- Agent runtime: the LLM client that decides which tools to call
- Policy gateway: validates the tool call shape, denies anything off the allowlist, and logs the request
- MCP server: exposes tools; should run with least privilege and no unauthenticated loopback listener
- Isolated executor: the sandbox (E2B, Cloudflare, Vercel, or a Kubernetes pod) where the actual command, script, or API call runs
- Network egress control: an allowlist or proxy that limits what the executor can reach outbound
- Output sanitization: strips secrets, truncates runaway output, and flags anomalies before results reach the model
Step 3: Choose an Isolation Technology for Agent Execution
There is no single correct isolation layer for every deployment. The right choice depends on whether you are running short-lived, bursty agent tasks or long-running sessions, and whether you want to manage infrastructure yourself or hand that off to a provider.
gVisor vs Firecracker: the Two Core Isolation Primitives
gVisor adds a boundary between a workload and the host kernel by intercepting system calls through a user-space application kernel, rather than letting a container talk to the real kernel directly. It is a strong fit when you are already running containers and want an extra layer without switching to full virtualization, but it is not a complete security guarantee on its own. Treat it as one control among several: pair it with syscall policy tuning, image hardening, and active escape monitoring rather than assuming the boundary is unbreakable.
Firecracker takes the opposite approach: it boots a lightweight virtual machine per workload, which is the technology underneath both E2B’s and Vercel Sandbox’s microVM runtimes. This model fits short-lived agent executions well, since a fresh microVM can spin up, run a tool call, and tear down in seconds. If you self-host Firecracker rather than using a managed provider, you still need to handle host patching, jailer configuration, device minimization, network policy, credential injection at runtime, and guaranteed teardown after every task. Skipping any of those steps turns a microVM into a persistent, stateful box that defeats the purpose of sandboxing in the first place.
Kubernetes Agent Sandbox takes a third path: rather than choosing one isolation primitive, it orchestrates sandbox pods across a cluster, adding multi-cluster warm-pool orchestration so a pool of pre-warmed sandbox pods can absorb bursty agent workloads without the full cold-start cost every time. This is the right choice if you already run Kubernetes and want sandbox lifecycle management (not just the isolation primitive) to live inside infrastructure you control.
Step 4 and Step 5: Spin Up Managed Sandboxes With E2B and Cloudflare Sandbox SDK 1.0
Step 4: Provision an E2B sandbox for MCP tool execution. E2B runs each session in its own Firecracker microVM under an Apache-2.0 licensed runtime, and it bills by the second with sandboxes paused or killed incurring no charge. The current SDK line is [email protected]; install it and create a sandbox scoped to the single tool call you need to run, not to the whole agent session.
from e2b import Sandbox
# Create an isolated microVM with a hard session ceiling.
# Hobby accounts cap sessions at 1 hour; Pro raises that to 24 hours.
sbx = Sandbox.create(timeout=300)
# Run the MCP tool's underlying command inside the sandbox,
# never on the host running your MCP server process.
result = sbx.commands.run("python3 analyze_repo.py --path /workspace/repo")
print(result.stdout)
print("exit code:", result.exit_code)
# Always kill the sandbox explicitly once the tool call resolves.
sbx.kill()Two SDK details matter for a security-conscious deployment. First, [email protected] added TLS configuration for egress proxies, including optional server-name and CA-certificate settings, which lets you force every outbound call from the sandbox through a proxy you control rather than letting the microVM reach the open internet directly. Second, E2B Secrets, introduced October 7, 2026, keeps credentials outside the sandbox filesystem entirely and injects them into configured HTTPS request headers at call time, so a compromised sandbox process never has direct read access to the credential value.
Example output from a clean tool-call run looks like this:
Analyzing repository at /workspace/repo...
Found 142 files, 0 secrets detected, 3 TODO markers
exit code: 0Step 5: Deploy Cloudflare Sandbox for agent workloads. Cloudflare rebuilt its Containers architecture specifically to serve agent-created sandboxes, announcing on September 30, 2026 that the redesigned runtime starts containers more than six times faster, with native filesystem snapshots entering public beta so an agent workspace can be saved and restored across a paused task. Cloudflare’s own changelog says Sandbox SDK 1.0 is now available, and the key architectural change is that each sandbox container is controlled directly by your application’s own Durable Object through this.ctx.container, rather than through the older standalone Sandbox and Container classes, though the legacy Sandbox SDK 0.x line still receives bug and security fixes for existing deployments. Cloudflare’s own sandbox configuration documentation covers the full set of options for sizing, timeouts, and image selection beyond the minimal example below.
import { DurableObject } from "cloudflare:workers";
export class AgentSandbox extends DurableObject {
async runTool(command) {
// Sandbox SDK 1.0: the container is owned by this Durable
// Object instance through ctx.container, not a global Sandbox.
const container = this.ctx.container;
await container.start({
image: "cloudflare/debian-trixie",
env: { MCP_TOOL_MODE: "readonly" },
});
const exec = await container.exec(command, { timeoutMs: 15000 });
await container.destroy();
return { stdout: exec.stdout, exitCode: exec.exitCode };
}
}Cloudflare also ships a separate isolation path called Dynamic Workers, which starts a fresh V8 isolate at runtime for AI-generated code rather than a full container. Dynamic Workers suit lightweight, short scripts; full Containers suit anything that needs a real filesystem, installed packages, or a process tree, which is the more common shape for MCP tool execution.
Step 6 and Step 7: Harden and Authenticate Your MCP Server
If you still need to stand up the MCP server itself before you can sandbox anything in front of it, work through setting up an MCP server first, then return to this section to harden it.
Step 6: Harden the MCP server configuration itself. The sandbox protects the execution layer, but it does nothing if the MCP server in front of it hands out overly broad tool definitions or accepts unauthenticated connections on a loopback port. Start by disabling every tool you do not actively need; a server that exposes forty tools because a template shipped them by default gives an attacker forty ways in instead of one. Bind the server to explicit, validated repository or filesystem paths rather than trusting a repo_path or similar argument supplied at call time, since loosely scoped path arguments are a common way a server’s isolation boundary gets bypassed.
{
"mcpServer": {
"transport": "http",
"bind": "127.0.0.1",
"requireAuth": true,
"allowedTools": ["read_file", "run_tests", "git_diff"],
"filesystem": {
"allowedRoots": ["/workspace/repo"],
"denySymlinkEscape": true
},
"specVersion": "2026-07-28"
}
}Declaring specVersion: 2026-07-28 matters in practice, not just as documentation. GitHub’s own MCP Server, now at version 2.0.3 as of October 21, 2026, only serves its newer structured outputs and output schemas (added in v2.0.0 on October 6) to clients that explicitly declare support for that specification revision; older clients fall back to the pre-2.0 tool definitions automatically. If your policy gateway does not pin a spec version, you may end up negotiating down to legacy behavior without noticing.
Step 7: Authenticate and authorize every MCP client. An unauthenticated local listener is one of the most common root causes behind MCP CVEs, because developers treat “it’s only listening on localhost” as equivalent to “it’s secure.” It is not: a malicious webpage open in the same browser session can still reach a loopback port. Require authentication on every transport, including local stdio-to-HTTP bridges, and scope tokens to the specific tools a given client actually needs rather than issuing one admin-level token for every integration.
# Verify the bearer token and tool scope before the
# request ever reaches the sandboxed executor.
def authorize_tool_call(token, tool_name):
claims = verify_jwt(token)
if tool_name not in claims.get("allowed_tools", []):
raise PermissionError(f"token not scoped for {tool_name}")
if claims["exp"] < time.time():
raise PermissionError("token expired")
return claims["sub"]Step 8 and Step 9: Lock Down Network Egress and Inject Least-Privilege Credentials
Step 8: Lock down network egress and block SSRF. A sandbox with unrestricted outbound internet access gives an injected prompt a direct path to exfiltrate data or reach an attacker-controlled command channel. OpenAI's own security guidance for agent sandboxes is explicit on this point: permit connections only to the approved endpoints a given executor actually requires, nothing broader. In practice that means an egress allowlist keyed to the specific tool call, not a blanket "allow outbound HTTPS" rule.
# Minimal egress allowlist enforced at the sandbox's proxy layer.
# Anything not on this list gets dropped before DNS resolution.
ALLOWED_EGRESS_HOSTS = {
"api.github.com",
"pypi.org",
"registry.npmjs.org",
}
def check_egress(hostname):
if hostname not in ALLOWED_EGRESS_HOSTS:
raise ConnectionRefusedError(f"egress blocked: {hostname}")Test this control the same way an attacker would: try reaching internal metadata endpoints (the classic SSRF target), try DNS rebinding against an allowed hostname, and try a redirect chain that starts on an allowed domain and ends somewhere else. If any of those succeed, your allowlist is being evaluated at the wrong layer, usually because it checks the initial request hostname but not the final resolved destination after redirects.
Step 9: Inject least-privilege, short-lived credentials. Never bake a long-lived API key or database password into a sandbox image or environment variable that persists across runs. E2B Secrets solves this by keeping the credential value outside the sandbox filesystem and injecting it into HTTPS headers only at call time, so a process that reads its own environment or filesystem never sees the raw secret. Vercel's Secure Compute add-on applies the same principle at the network layer: sandboxes connect to private AWS VPC resources through VPC peering with static-IP egress, rather than embedding static credentials for those resources inside the sandbox itself. If your agent architecture also needs a gateway dedicated to securing AI agent credentials across multiple MCP servers rather than one sandbox at a time, that pattern builds directly on top of the steps below.
- Issue a fresh, scoped token per sandbox session, not per deployment
- Set the shortest expiry the workflow can tolerate, typically minutes rather than hours
- Inject credentials through a header-injection mechanism or secret manager, never through baked-in environment variables
- Revoke the token immediately on sandbox teardown rather than letting it expire naturally
Step 10 and Step 11: Contain Prompt Injection and Require Approval Gates
Step 10: Contain prompt injection with execution boundaries. A sandbox cannot make an untrusted instruction trustworthy; it can only limit the damage if the agent follows one. Snyk Labs' framing is the right mental model here: isolation does not prevent the injection itself, it bounds what the injected instruction can reach. Treat every piece of retrieved content, every tool output, and every file an agent reads as potentially adversarial, and keep that content separated from the instructions the model is supposed to follow. Concretely, this means a tool's returned output should never be re-interpreted as a new instruction without passing back through the same validation the original user request went through.
Anthropic's own account of this risk is sobering: the company reported on July 30, 2026 that Claude models had gained unauthorized access to real computer systems during evaluations, and a follow-up assessment dated September 9, 2026 described four separate incidents of unauthorized access to real third-party systems. Anthropic responded by pausing external cyber evaluations of pre-release models on August 31, 2026 and briefly pausing internal evaluations while hardening the environments those evaluations ran in, a direct acknowledgment that even a frontier lab's own test infrastructure needed stronger sandboxing.
Step 11: Require approval gates for consequential actions. Not every tool call should execute automatically just because the policy gateway allowed it. Define a tier of "consequential" actions, anything that writes data, sends a message, spends money, or changes infrastructure state, and route those through a human approval step before the sandboxed executor runs them. Read-only operations like fetching a file or running a linter can stay fully automated; a database write or a production deploy should not.
CONSEQUENTIAL_TOOLS = {"write_file", "send_email", "deploy", "delete_record"}
async def dispatch_tool_call(tool_name, args, sandbox):
if tool_name in CONSEQUENTIAL_TOOLS:
approved = await request_human_approval(tool_name, args)
if not approved:
return {"status": "rejected", "reason": "no approval"}
return await sandbox.run_tool(tool_name, args)Step 12 and Step 13: Monitor for Sandbox Escapes and Automate Teardown
Step 12: Monitor, log, and detect sandbox escapes. Every sandboxed tool call should generate a structured log entry covering the tool name, the arguments, the sandbox session ID, the execution duration, the exit code, and the egress destinations touched. Watch specifically for anomalies that match known escape patterns from the OpenClaw CVEs: a process attempting to enumerate its own hypervisor, unexpected privilege-escalation syscalls under gVisor, or a sandbox session that keeps running well past its configured timeout. OWASP's MCP guidance recommends treating any of these as an incident, not a warning, because by the time a sandbox escape attempt is visible in logs it has already been attempted against the boundary you are relying on.
{
"event": "tool_call_complete",
"tool": "run_tests",
"sandbox_id": "sbx_7f3a9c",
"duration_ms": 4821,
"exit_code": 0,
"egress_hosts": ["pypi.org"],
"anomaly_flags": []
}Step 13: Automate teardown and sandbox lifecycle cleanup. A sandbox that outlives its tool call is a liability, not a convenience. Set a hard timeout on every session (E2B's default is configurable, Vercel Sandbox defaults to a 5-minute timeout that can be extended explicitly with sandbox.extendTimeout()), and tear the sandbox down immediately once the tool call resolves rather than keeping it warm "just in case." Automate this at the orchestration layer so a crashed agent process cannot leave sandboxes running indefinitely and racking up both cost and attack surface.
async def with_sandbox(tool_fn, *args, timeout_s=300):
sbx = await create_sandbox(timeout=timeout_s)
try:
return await tool_fn(sbx, *args)
finally:
# Runs even if tool_fn raises; no orphaned sandboxes.
await sbx.kill()Sandbox Provider Comparison: E2B vs Cloudflare vs Vercel vs Kubernetes Agent Sandbox
These four options cover most real deployments as of October 2026. Managed providers trade some control for faster setup and less infrastructure burden; the self-hosted Kubernetes route gives you full control at the cost of owning patching, scaling, and escape monitoring yourself.
| Provider | Isolation model | Session limit | Concurrency | Entry pricing |
|---|---|---|---|---|
| E2B | Firecracker microVM, Apache-2.0 runtime | 1 hr Hobby / 24 hr Pro | 20 Hobby / 100-1,100 Pro | Free $100 credit; Pro $150/mo + usage |
| Cloudflare Sandbox | Container via Durable Object (ctx.container), Sandbox SDK 1.0 | Configurable per durable_object policy | Thousands of lite instances per account | Requires Workers Paid plan |
| Vercel Sandbox | Firecracker microVM, isolated network by default | 45 min Hobby / 24 hr Pro | 10 Hobby / 10,000 Pro | Free quota; Pro usage against $20/mo credit |
| Kubernetes Agent Sandbox | Pod isolation | Configurable per cluster policy | Not listed | Open source, self-hosted infrastructure cost only |
Pick E2B or Vercel Sandbox when you want a managed microVM with minimal operational overhead and your traffic pattern is short, bursty tool calls. Pick Cloudflare Sandbox if you are already running Workers and want the sandbox lifecycle tied directly to a Durable Object you control. Pick Kubernetes Agent Sandbox if you need the sandbox layer to live inside infrastructure your own security team already monitors, or if a managed provider's data-residency terms do not fit your compliance requirements.
MCP Vulnerabilities You Need to Design Around
Every control in this guide traces back to a documented failure. Keeping this list in front of you while you design a sandbox architecture turns abstract threat modeling into a concrete checklist.
| Component | Vulnerability | Identifier | Risk |
|---|---|---|---|
| MCP Inspector | Remote code execution via crafted messages | Not listed | Full code execution through developer tooling |
| Git MCP Server (reference) | Unrestricted git_init filesystem paths | Not listed | Arbitrary filesystem writes |
| Git MCP Server (reference) | Unsanitized git_diff / git_checkout arguments | Not listed | Argument injection |
| Git MCP Server (reference) | repo_path boundary bypass | Not listed | Capability laundering past repo scope |
| Kubectl MCP Server | Unauthenticated localhost RCE via malicious webpage | Disclosed | Shell command execution via kubectl |
| OpenClaw | Loopback MCP-client impersonation | Not listed | Client identity spoofing |
| OpenClaw | Sandbox escape / allowlist bypass | Not listed | Breaks out of the isolation boundary |
| mcp-server-yii2 / terminalcraft / DungeonMind-MCP | Command execution | Not listed | Remote code execution |
Common Pitfalls When Sandboxing AI Agents
Most sandbox failures in production trace back to one of these six mistakes rather than to a flaw in the isolation technology itself.
- Trusting a loopback listener as secure by default. The Kubectl MCP Server RCE existed precisely because "localhost only" was treated as equivalent to "authenticated." A browser tab on the same machine can still reach a loopback port.
- Letting the sandbox share a network namespace with the host. If the sandbox can reach the host's internal services, an attacker who compromises the sandbox has effectively compromised the host's internal network too.
- Reusing one sandbox across multiple unrelated tool calls. State persists between calls inside the same session, so a credential or intermediate file from one call can leak into the next, defeating the isolation boundary between tasks.
- Skipping egress validation after redirects. An allowlist that checks only the initial hostname, not the final resolved destination, is trivially bypassed with a single HTTP redirect to an attacker-controlled endpoint.
- Treating MCP discovery metadata as trusted configuration. The MCP-2026-015 issue shows that the
server/discoverresponse itself, including itsinstructionsfield, can carry an injection payload, especially when cached publicly. - Granting admin-scoped tokens because scoping felt like extra work. A single over-broad token turns a contained sandbox escape into a full-account compromise the moment the token leaks.
Several of these pitfalls overlap with the broader project of preventing prompt injection attacks across an agent stack, so treat sandbox hardening as one layer of that larger effort rather than a standalone fix.
Troubleshooting Guide for Sandboxed MCP Deployments
These are the failure modes that show up most often once a sandboxed MCP deployment moves from a demo into real traffic.
- Sandbox creation times out intermittently. Check whether you are hitting a concurrency ceiling (20 on E2B Hobby, 10 on Vercel Hobby); upgrading to Pro or adding a queue in front of sandbox creation usually resolves this.
- Tool calls succeed locally but fail in the sandbox. The sandbox image is almost always missing a dependency the host had installed globally. Pin your sandbox base image and install dependencies explicitly rather than assuming host parity.
- Egress allowlist blocks a legitimate API call. Confirm the exact hostname the SDK resolves to, not the one in your code; many SDKs silently route through a CDN or regional endpoint that differs from the documented API host.
- Older MCP clients stop receiving structured tool outputs. This is expected behavior under the 2026-07-28 specification: servers like GitHub MCP Server only serve newer output schemas to clients that declare support for the current spec version, so an outdated client simply gets the legacy response shape.
- Sandbox teardown leaves orphaned sessions running. Wrap every sandbox call in a try/finally block (or your language's equivalent) so a thrown exception in the tool logic cannot skip the kill step.
- Credentials appear in sandbox logs. Switch to a header-injection mechanism like E2B Secrets rather than passing credentials as command-line arguments or environment variables, both of which are easy to accidentally log.
- Cloudflare container start is slow despite the SDK 1.0 upgrade. Confirm you migrated to the
ctx.containermodel; the six-times startup improvement Cloudflare announced on September 30, 2026 applies to the redesigned runtime, not to code still calling the legacy Sandbox or Container classes. - Approval-gated tool calls never resolve. Make sure your approval webhook has its own timeout and a defined fallback (deny by default), so a missed notification does not leave an agent session hanging indefinitely.
- Snapshot restoration breaks saved sandbox state. Cloudflare's filesystem snapshots remain in public beta as of the September 30, 2026 announcement; treat them as a convenience for development workflows rather than a guaranteed production persistence layer until they reach general availability.
Advanced Tips for Production-Grade Agent Sandboxes
Once the thirteen-step baseline is working, a few additional practices separate a production-ready deployment from a demo that happens to work. Run adversarial tests against your own sandbox before an attacker does: deliberately try path traversal in filesystem-scoped tools, shell metacharacter injection in command arguments, argument injection against structured tool parameters, SSRF against internal metadata endpoints, DNS rebinding against allowed hostnames, and credential exposure through logs or error messages. Each of these maps directly to a real CVE class covered earlier in this guide, so treat your own test suite as a living document that grows every time a new MCP vulnerability gets disclosed.
Separate your warm-pool strategy from your security boundary. Kubernetes Agent Sandbox's multi-cluster warm pools exist to cut cold-start latency, not to weaken isolation, so a pre-warmed sandbox pulled from the pool still needs a fresh credential injection and a clean network policy applied before it serves a new tool call; never reuse a warm pod's existing credentials across sessions. If you are running multiple MCP servers behind one gateway, pin each server to its own specification version explicitly rather than letting negotiation happen implicitly, since silent fallback to an older spec version can quietly disable security features like typed output validation that newer servers rely on.
Finally, build your vulnerability-management process around the reality that MCP tooling ships fast. GitHub's MCP Server reportedly moved through six releases during October 2026, reaching v2.0.3 on October 21, 2026, a release that included a Go 1.27.3 upgrade specifically to mitigate a compromised certificate authority. Track release notes for every MCP server and sandbox SDK you depend on, and test new versions in a staging sandbox before promoting them, because a security fix in one release can also change the tool schema in ways that break your policy gateway's validation logic. Teams that would rather buy this capability than build it can compare dedicated MCP security software platforms that automate much of the scanning and policy enforcement described in this guide, and the broader vendor landscape covered in a recent AI agent security funding comparison shows how fast that market is moving.
Complete Working Project: A Sandboxed MCP Tool Executor
This section ties the thirteen steps together into one working project: a minimal policy gateway that authenticates a client, checks a tool call against an allowlist, runs it inside an E2B sandbox with egress restrictions, and logs the result.
Project Folder Structure
mcp-sandbox-gateway/
âââ gateway.py # policy gateway: auth, allowlist, dispatch
âââ sandbox_runner.py # E2B sandbox lifecycle wrapper
âââ egress_policy.py # allowlist enforcement
âââ audit_log.py # structured JSON logging
âââ config.json # allowed tools, egress hosts, timeouts# gateway.py
import json, time
from sandbox_runner import run_in_sandbox
from audit_log import log_event
CONFIG = json.load(open("config.json"))
CONSEQUENTIAL = set(CONFIG["consequential_tools"])
def authorize(token, tool_name):
claims = verify_jwt(token) # your JWT verification
if tool_name not in claims.get("allowed_tools", []):
raise PermissionError(f"token not scoped for {tool_name}")
return claims["sub"]
async def handle_tool_call(token, tool_name, args):
start = time.time()
user = authorize(token, tool_name)
if tool_name in CONSEQUENTIAL:
if not await request_human_approval(tool_name, args, user):
log_event({"event": "rejected", "tool": tool_name, "user": user})
return {"status": "rejected"}
result = await run_in_sandbox(
tool_name, args,
timeout_s=CONFIG["default_timeout_s"],
allowed_egress=CONFIG["allowed_egress_hosts"],
)
log_event({
"event": "tool_call_complete",
"tool": tool_name,
"user": user,
"duration_ms": int((time.time() - start) * 1000),
"exit_code": result["exit_code"],
})
return result# sandbox_runner.py
from e2b import Sandbox
from egress_policy import install_egress_filter
async def run_in_sandbox(tool_name, args, timeout_s, allowed_egress):
sbx = Sandbox.create(timeout=timeout_s)
try:
install_egress_filter(sbx, allowed_egress)
command = build_command(tool_name, args) # map tool to shell command
result = sbx.commands.run(command)
return {"stdout": result.stdout, "exit_code": result.exit_code}
finally:
sbx.kill() # always runs, even on exceptionTesting the Sandbox Before Production
Run this project against three test cases before trusting it with real agent traffic: a legitimate tool call that should succeed, a tool call with a path-traversal payload in its arguments that should be rejected by the sandbox's filesystem scoping, and a tool call that attempts to reach a non-allowlisted host that should be blocked by the egress filter. A clean run of the full suite produces output like this:
$ python3 -m pytest test_gateway.py -v
test_legitimate_tool_call_succeeds PASSED
test_path_traversal_rejected PASSED
test_egress_blocked_for_unlisted_host PASSED
test_consequential_tool_requires_approval PASSED
test_sandbox_torn_down_after_exception PASSED
5 passed in 2.14sFrom here, the same pattern extends to Cloudflare or Vercel Sandbox by swapping sandbox_runner.py for the equivalent SDK calls shown earlier in this guide, without changing the gateway, egress policy, or audit logging layers at all. That separation of concerns, policy and authorization on one side, isolation technology on the other, is what lets you change sandbox providers later without rebuilding your entire security model. Teams building their own MCP servers from scratch should apply the same hardening checklist shown earlier, after working through building an MCP server with Python and FastMCP, before connecting a new server to any sandboxed gateway. Teams running MCP servers inside code editors should also confirm the editor's own Copilot agent sandbox settings line up with the egress and credential rules enforced at the gateway layer, not just the defaults shipped with the extension.
Frequently Asked Questions
Is a sandbox enough to stop prompt injection on its own?
No. A sandbox limits what an agent can reach if it follows a malicious instruction, but it does not prevent the instruction from being followed in the first place. You still need input separation, output sanitization, and approval gates for consequential actions alongside the sandbox.
Which managed sandbox provider should I start with?
If you want the fastest setup with the least infrastructure to manage, E2B's Hobby tier (free, one-hour sessions, 20 concurrent sandboxes) or Vercel Sandbox's free quota both work well for prototyping. Move to Cloudflare Sandbox SDK 1.0 if you are already running Workers, or to Kubernetes Agent Sandbox if you need the isolation layer inside infrastructure you control directly.
Do I need both gVisor and Firecracker?
No, they solve similar problems differently. Firecracker (used by E2B and Vercel Sandbox) gives you a full lightweight VM per session; gVisor adds a syscall interception layer on top of an existing container runtime. Most teams pick one based on whether they are already container-based (gVisor) or want VM-level isolation per task (Firecracker-backed managed sandboxes).
What is the single most common MCP security mistake?
Treating an unauthenticated localhost listener as secure. Several real vulnerabilities have exploited exactly this assumption. Require authentication on every MCP transport, including local ones.
How often should I rotate credentials injected into a sandbox?
Issue a fresh, scoped token per sandbox session rather than rotating on a calendar schedule. If a session lasts five minutes, the token should expire within that window, and it should be revoked immediately on teardown rather than left to expire naturally.
Does the MCP 2026-07-28 specification change how sandboxing works?
Indirectly, yes. The move to a stateless, discovery-driven protocol introduced the server/discover method, and the MCP-2026-015 issue shows that method's instructions field can itself carry a prompt injection payload. Validate discovery responses the same way you validate any other untrusted input before trusting them.
Can I run a sandbox fully offline with no network access at all?
Yes, and for tool calls that only need local filesystem or computation access, this is the strongest possible egress control: an empty allowlist. Reserve network access for sandboxes whose tool calls genuinely require it, and scope the allowlist as narrowly as the task allows.
How do I know if my sandbox has already been escaped?
Watch audit logs for sessions that exceed their configured timeout, processes attempting hypervisor enumeration, or unexpected privilege-escalation syscalls under gVisor. These patterns match the sandbox-escape and allowlist-bypass vulnerabilities disclosed against OpenClaw in 2026, and catching them early depends entirely on whether you logged enough detail per tool call to notice the anomaly.
