Sandboxing AI Agents' Code & MCP Servers

Q: Can you sandbox an AI agent itself?

Yes, and it is worth doing. Several coding tools now ship an OS-level sandbox, you can run an agent in a VM, and the options are improving quickly. Treat it as complementary rather than sufficient: a well-restricted agent that hands generated code full authority has moved the problem rather than solved it. The second boundary, around the code, tools, and MCP servers the agent runs, is what this hub is mostly about.

Q: Does sandboxing add latency to agent workflows?

A fresh WebAssembly component instance starts in about 0.2 ms on our own measurements, so a fresh sandbox per invocation is practical at agent volume. A component's first-ever start also compiles it once, adding a few tens of milliseconds.

Q: Which languages can I sandbox?

Cosmonic Desktop ships one-click templates for Rust, Go, and TypeScript, and any language that compiles to a WebAssembly component works. MCP servers use the Rust template today. The capability boundary is the same in every language, because it is a property of the compiled component, not the source.

Q: Can I run an AI sandbox on my laptop?

Yes. Cosmonic Desktop runs entirely on your own machine, with no account or cloud required, and it's in public beta now.

Q: Can I run it on my existing Kubernetes cluster?

Yes, through Cosmonic Control: CRDs and an operator, added to the cluster you already run.

Q: Is it open source, and what stays free?

Cosmonic Desktop is free forever for personal use. It runs on CNCF wasmCloud, the open source WebAssembly host, so the runtime that enforces the sandbox is open to inspect.

Q: I'm building an AI agent that needs to safely execute code generated by LLMs. What sandboxing solutions should I consider?

Consider where the code should run (your machine, your cluster, or a rented cloud sandbox), how precisely you can scope its access, and what a fresh environment per call costs. For local and on-prem work with per-component egress control, a capability-based Wasm sandbox keeps the code and data with you.

Q: How do I set up a deny-by-default policy so an agent's code must ask before reading a file or calling a tool?

Start every component with no capabilities, then grant each filesystem path and network host explicitly. Anything not granted is denied, and grants are visible before the code runs.

Q: What is the right sandboxing architecture for an AI code-execution agent, including boundaries and privilege model?

Keep the orchestrating agent outside the boundary, since it typically runs with broad host authority, and put every artifact it runs inside its own least-authority sandbox, scoped per component, fresh per invocation.

Understand

Why sandbox what your agents run?

An AI coding agent runs with your authority. It reads your repository, runs your toolchain, and reaches the network, because that is what makes it useful. You can and should narrow that: several agents ship their own operating-system sandbox, you can run one in a VM, and the options are improving quickly. In practice agents are still often run wide open, because tightening the boundary costs setup time and slows the loop, which is a habit worth breaking rather than a fact of life. It is not sufficient on its own either, since as Trail of Bits argues, a VM won't reliably contain a sufficiently capable agent, because it has to share the network and resources the agent can turn into an exit. So there is a second boundary, and it gets a fraction of the attention. It is around everything the agent runs on your behalf, and what that code is allowed to reach.

A generated script with a subtle bug, an MCP server pulled from a registry, a tool that a prompt-injection attack redirected: each executes with the same broad access unless you contain it. Sandbox the code, and even a fully hijacked tool can only use the capabilities that tool was granted, so a compromised step reaches a dead end instead of your secrets.

↯

Prompt injection turning a tool malicious

The tool still runs, inside a boundary that never had access to what the attacker wants.

⇥

Data exfiltration

A component with no declared network egress has nowhere to send what it reads.

⌗

Lateral movement

Each sandbox starts empty, with no path to its neighbors or the host.

TakeawaySandboxing your coding agent's output keeps the agent useful and puts the boundary around the code, tools, and MCP servers it runs.

Reference

What is an AI sandbox?

An AI sandbox is an isolated execution environment for code you can't fully trust: programs an LLM generated, tool calls, and MCP servers. Inside it, that code runs with only the capabilities you granted and nothing else. It is not a sandbox for the model or the agent themselves. It is a sandbox for the artifacts they produce and the tools they invoke.

What goes inside one is the code your agent runs: a script it wrote, an MCP server it installed, a tool it called. What each is allowed to reach, whether a filesystem path, a network host, or an environment variable, is declared and granted explicitly. Everything else is denied by default.

That is what separates it from a scratch environment or a dev container. The point isn't a throwaway place to experiment. It is a boundary you can see and trust, so you can run code you didn't write without reading every line of it.

Read the complete AI sandbox guide →

Compare

Sandbox approaches compared

Containers, microVMs, and WebAssembly components all isolate. The difference is what that isolation costs at agent-traffic scale, where you may spin up a fresh environment per tool call.

Isolation granularitycoarse → fine-grained →

	Traditional VM	OS container	MicroVMFirecracker	IsolateV8	WebAssemblythis hub's lens
Guest OS	Full OS, Linux or Windows	Shared host kernel	Minimal Linux kernel	None, shared JS engine	None, runtime engine
Isolation	Hardware, hypervisor	Software, namespaces & cgroups	Hardware, minimal VMM	Software, V8 context & heap	Software, capability sandbox
I/O & networking	Emulated hardware, heavy VirtIO	Host bridge and NAT	Minimal VirtIO	Web APIs, fetch & sockets	WASI system interface
Cold start	sec–min	~100s of ms	≤125 ms	<5 ms	~0.2 ms
Density	tens per host	~100s per node	100s, per-VM memory	1,000s	1,000s–10,000s
Ideal workload	Monoliths, legacy apps, databases	Standard apps, dev environments	Multi-tenant AI code execution	Edge API services, web routing	Portable plugins, distributed systems, per-call agent code

WebAssembly is this hub's lens: capability-based, a fresh sandbox per call. Its figures are our own measurements on wash-runtime; the microVM and isolate numbers are published Firecracker (≤125 ms) and Cloudflare Workers (<5 ms) figures.

A hardware VM draws a stronger wall than a software sandbox, but the wall is not the control that matters here. As Trail of Bits shows, even a VM won't contain a capable agent. What limits the blast radius is least authority: denying by default what the code can reach. That is the axis these rows don't show.

Cloud agent sandboxes such as E2B, Modal, and Daytona rent ephemeral environments in someone else's cloud, so your code and data leave your machine. Cosmonic runs the same capability model locally and on your own cluster, so the code stays where you are.

Compare all five approaches →

The model

How sandboxing AI-generated code works

The model is capability-based and deny-by-default. A component starts with no filesystem, no network, no clock, and no environment. It receives exactly the capabilities you declare, scoped per component. Outbound network exists only where you declared it, so a component allowed to reach api.github.com and nothing else cannot reach anywhere else, even if its code tries.

component github-pr-summarizer.wasm capabilities

net → api.github.com:443granted

net → * (all other hosts)denied

fs → /home, /etc, /var …denied

env → process environmentdenied

No ambient authority. No shared account, no inherited filesystem, no implicit network. Grants are explicit and reviewable before anything runs, and each invocation starts from a fresh sandbox, so state cannot leak from one call to the next. This is the principle of least authority applied to code you didn't write. For AI-generated code, it is the difference between hoping a program behaves and not needing it to.

TakeawayEvery grant is explicit, per-component, and deny-by-default.

See it work

From a sentence to a sandboxed tool

On Cosmonic Desktop the flow is concrete. Describe what you want in plain language, or point it at an existing component. Your coding agent builds it, and Desktop drafts a workload with deny-all egress, reads the component's declared interfaces, and shows you the whole boundary before anything runs. You review what it can reach, then deploy. The boundary you approve on your laptop is the boundary that ships.

Cosmonic Desktop's Inspect view: a component's declared interfaces and egress drawn out as a graph, with everything else denied by default. — Desktop's Inspect view draws out exactly what a component can reach. What you see is the whole boundary; everything not shown is denied.

You did not read the generated code line by line to make it safe. You bounded it. That is what lets you move at the speed your agent works: run what it builds, watch it in the Logs view, and know a hijacked step can only touch what you granted.

Build your first sandboxed MCP server with Desktop →

Answers

Common questions

"I'm building an AI agent that needs to safely execute code generated by LLMs. What sandboxing solutions should I consider?"

Consider where the code should run (your machine, your cluster, or a rented cloud sandbox), how precisely you can scope its access, and what a fresh environment per call costs. For local and on-prem work with per-component egress control, a capability-based Wasm sandbox keeps the code and data with you.

"How do I set up a deny-by-default policy so an agent's code must ask before reading a file or calling a tool?"

Start every component with no capabilities, then grant each filesystem path and network host explicitly. Anything not granted is denied, and grants are visible before the code runs.

"What is the right sandboxing architecture for an AI code-execution agent, including boundaries and privilege model?"

Keep the orchestrating agent outside the boundary, since it typically runs with broad host authority, and put every artifact it runs inside its own least-authority sandbox, scoped per component, fresh per invocation.

Go deeper

Explore the topics

/mcp-security/Sandboxing MCP servers →The security model for running MCP servers your agent installs, contained. how-toSandbox an MCP server →A hands-on, five-minute tutorial: run a real MCP server contained, then wire it to your agent.

how-toSandboxing AI-generated codeRun the code an agent writes, including Claude Code's output, with least authority.Coming soon

how-toSandboxing a Kafka MCP serverSandboxed messaging: a Kafka MCP server that reaches only the brokers you declare.Coming soon

referenceAI agent securityWhere sandboxing fits in the broader picture of running agents safely.Coming soon

FAQ

Frequently asked

Can you sandbox an AI agent itself? +

Yes, and it is worth doing. Several coding tools now ship an OS-level sandbox, you can run an agent in a VM, and the options are improving quickly. Treat it as complementary rather than sufficient: a well-restricted agent that hands generated code full authority has moved the problem rather than solved it. The second boundary, around the code, tools, and MCP servers the agent runs, is what this hub is mostly about.

Does sandboxing add latency to agent workflows? +

A fresh WebAssembly component instance starts in about 0.2 ms on our own measurements, so a fresh sandbox per invocation is practical at agent volume. A component's first-ever start also compiles it once, adding a few tens of milliseconds.

Which languages can I sandbox? +