The question that actually matters in 2026 is not whether an AI agent can write code. It can. The question is where you run code that an AI just wrote and that no human has read. An autonomous coding loop installs packages, compiles, runs tests, and spins up servers, and every one of those steps is an instruction nobody reviewed before it hit a shell. That single fact drags a problem out of the security archives and drops it into the middle of every agent platform: how do you execute untrusted code without lighting yourself on fire?

The blast radius is the whole point

When I think about an agent environment, I do not think about the agent. I think about what is reachable from the box it runs in. In a multi-tenant agent platform, a workload that escapes its boundary is not one broken job. It is a path to other customers' data, to cloud credentials sitting in instance metadata, to the control plane that orchestrates everything else. The agent is fast, tireless, and occasionally talked into doing exactly the wrong thing by a prompt injection it read in a webpage. That is the actor you are containing.

So the sandbox is a security decision. It is also a reliability decision, because runaway loops happen, and a UX decision, because an agent that waits a few seconds for an environment on every step feels broken to the person watching it. Platform teams now have to ship "run arbitrary code on demand" as a paved road with isolation, quotas, and egress control built in, not bolted on after the first incident.

Containers are not a security boundary here

This is the uncomfortable consensus forming across the vendor and practitioner writeups this year, and I agree with it: a standard container is not a security boundary for untrusted AI-generated code. Containers share the host kernel. One kernel exploit or one sloppy misconfiguration and the boundary is gone. For trusted internal code that tradeoff is completely fine, and I run plenty of trusted workloads in plain containers without losing sleep. For code an LLM invented thirty seconds ago, with no human in the path, it is not fine.

The part that bites teams in practice is the assumption that "we already containerize everything" means they are covered. They are covered against a flaky dependency, not against an adversary running inside the namespace. Those are different threat models, and conflating them is how you end up explaining a cross-tenant breach to a customer.

Three isolation tiers, strongest first

There are really three options, and they sort cleanly by strength.

MicroVMs (Firecracker, Kata Containers) give each workload its own kernel behind a hardware-enforced KVM boundary. This is the floor for untrusted multi-tenant code, full stop. The reason it is now affordable rather than absurd is Firecracker's numbers: it boots in roughly 125ms with under 5 MiB of memory overhead per VM. That is what makes a fresh VM per agent task economically sane. It is the engine under E2B and Vercel Sandbox.

gVisor sits in the middle. Its Sentry process intercepts syscalls in user space and exposes only a small vetted subset to the host kernel, so you get a real boundary without a full VM. The cost is roughly 10 to 30 percent overhead on I/O-heavy work, which matters if your agents are thrashing the filesystem or the network.

Plain hardened containers are the weakest tier and belong only to code you actually trust. If you find yourself reaching for "but we locked the container down really well" to justify running untrusted agent output, that is the signal you picked the wrong tier.

Cold start is the battleground, and it is a tradeoff, not a winner

The vendors are fighting over startup latency, and the fight is honest because there is no free lunch in it. E2B reports about 150ms cold starts on Firecracker. Daytona advertises sub-90ms sandbox creation using a container-based approach. Read those two numbers together and the whole market makes sense: Daytona is faster because it is not paying for a separate kernel per workload, and E2B is more isolated because it is.

That is the decision, stated plainly. Container speed versus microVM isolation. You do not get to wish the tradeoff away, you get to choose which side of it your threat model lands on.

The market has bifurcated along exactly this line. E2B and Vercel lean into Firecracker isolation for untrusted execution. Daytona emphasizes fast, persistent, configurable sandboxes with auto-stop, auto-archive, and auto-delete, tuned for iterative agent work where the same session builds up state across turns. Modal aims at compute-heavy and GPU workloads. "Best" is not a property of any of these. It is a function of your dominant constraint.

So here is the decision rule I would hand a platform team. Untrusted multi-tenant execution goes to a microVM platform (E2B, Vercel Sandbox). Fast iterative stateful loops go to a Daytona-style persistent sandbox. GPU and heavy compute go to Modal. Do not pay for isolation you do not need, and do not skip isolation you do.

Isolation is the floor, not the control plane

Here is where I see teams declare victory too early. They get the runtime right, call the environment "isolated," and ship it with wide-open network egress. That is a data-exfiltration channel waiting for a prompt injection to find it. An agent that can reach the internet can post your source, your secrets, or your customer data to an attacker's endpoint, and the strongest microVM in the world will happily let it, because exfiltration over an allowed connection is not an escape. It is the sandbox working as configured.

A sandbox that actually holds up couples the runtime with four things. An isolated filesystem the agent can write to freely without touching anything real. Network egress policies that block unauthorized outbound calls by default. Hard resource limits on CPU, memory, and process count, so a runaway loop starves itself instead of the host. And an ephemeral lifecycle that destroys the environment when the task ends, guaranteed, not "usually." The agent gets full autonomy inside that boundary and nothing leaks past it. That is the deal.

On top of the box, the stated best practice this year is defense in depth, and it earns its keep. Sandbox to contain the damage. Runtime monitoring to see the agent misbehaving. Human approval gates on risky actions to stop the bad command before it runs. Signed artifacts on the way out so you can trust what the agent produced. The sandbox limits how bad an incident gets. The surrounding controls stop the incident from starting. You need both, and treating either as sufficient on its own is the mistake.

Build versus buy comes down to data gravity

The last call is whether to use a managed platform at all, and it is not really a security question. It is a data question. Managed sandboxes are excellent, and the adoption shows it: E2B says 88% of Fortune 100 companies have signed up to use it for agentic workflows, with users including Perplexity, Hugging Face, Manus, and Groq. Daytona raised a $24M Series A in February 2026 to expand its agent infrastructure after pivoting from dev-environment management. Northflank reports processing over 2 million isolated workloads monthly. This is a real product category now, not a science project.

But every one of those options means shipping your source code and your agent traffic to someone else's cloud. For a lot of organizations that is the whole ballgame, and the trend signals back it up: self-hosted sandbox projects are rising fast, including one Go project pitched bluntly as self-hosted dev sandboxes with preview URLs, no Kubernetes, built for coding agents. The open-source Firecracker and gVisor tooling matured quickly over the past year, and the gap to the managed offerings is narrowing.

So if you can send code and traffic to a managed cloud, buy. The latency, the lifecycle management, and the isolation are someone else's full-time job, and they are good at it. If you cannot, because of compliance, IP sensitivity, or plain data gravity, evaluate a self-hosted Firecracker or gVisor stack now rather than next year. The counterpoint worth taking seriously is that self-hosting microVM isolation correctly is genuinely hard, and a misconfigured DIY sandbox is more dangerous than a well-run managed one, because it ships with the confidence of "we built it ourselves" and none of the battle-testing. Build it only if you will staff it.

The one-line version for Monday: treat anything an LLM wrote and no human gated as untrusted, give it a microVM, lock the egress, cap the resources, guarantee the teardown, and watch what it does. Everything else is tuning.

Sources

  • https://northflank.com/blog/how-to-sandbox-ai-agents
  • https://modal.com/resources/best-code-execution-sandboxes-ai-agents
  • https://www.startuphub.ai/ai-news/artificial-intelligence/2026/daytona-vs-e2b-vs-modal-vs-vercel-sandbox-2026
  • https://e2b.dev/