← All guides · Agent security operations

How to Choose a Sandbox for AI Agent Code Execution

Part 3 of Agent security operations · 1,600 words · ~7 min read · published 2026-09-13 · updated 2026-09-13 · Markdown variant

A two-axis framework — trust in the code's source crossed with the blast radius of a successful escape — for picking an isolation layer, choosing among six hosted sandbox APIs, and hardening the harness around whichever one you pick.

Part of the How to Secure AI Agents in Production guide.

Choosing a sandbox for AI agent code execution means matching one layer from the pillar's isolation spectrum to two variables specific to the task at hand — where the code being run came from, and what a break-out from that sandbox could actually reach — rather than defaulting to whichever option is fastest to wire up. The agent security operations pillar already lays out each layer in that spectrum: in-process language sandboxes, OS containers, hardened runtimes such as gVisor and Kata, microVMs such as Firecracker, and full VMs. This piece treats that breakdown as settled ground. What follows is the part a survey of isolation options leaves out: a framework for picking a layer, a vendor-selection pass across the six hosted sandbox APIs the pillar names, and the harness-hardening checklist turned into steps you can implement and verify, not a restated list of six bullet points.

The two variables that decide where you land on the isolation spectrum

Two variables decide where on the isolation spectrum a given sandbox should sit: where the code being run came from, and what a break-out from that sandbox could actually reach. Neither variable alone settles the question — a fully untrusted source in a disposable, low-value environment doesn't need the same layer as a fully untrusted source that can reach production, and a semi-trusted source pointed at a high-value environment still deserves more isolation than the same code running somewhere throwaway.

Trust in the code's source ranges from fully untrusted — code an agent generates freely in response to arbitrary, often adversarial input such as a fetched web page or unconstrained user text — to semi-trusted, where the code passes through some constraint or review first. The Code-Then-Execute pattern covered in defending an agent against prompt injection, where a human or a rule reviews generated commands before execution, is what moves code from the fully untrusted end toward the semi-trusted one.

Blast radius of a successful escape ranges from low-value and ephemeral — a sandbox holding no real secrets, no persistent volume, and nothing beyond disposable output — to high-value and persistent, where the sandbox can reach a live credential, a shared filesystem, or a network path into production. The rule that a secret must never enter anything a model or its output can touch, covered in managing secrets for AI agents, is what should keep even a strongly isolated sandbox from holding a real key at all — isolation and secret-handling are separate controls, and neither substitutes for the other.

Mapping the four quadrants to an isolation layer

Crossing those two variables produces four quadrants, each pointing to a different minimum layer from the pillar's spectrum rather than one fixed answer for every sandbox a team runs.

Layer definitions, startup costs, and the technology behind each one are the pillar's own territory (/articles/agent-security-operations); this framework only supplies which layer a given combination calls for.

How do you choose among the six hosted sandbox APIs?

Choosing among the six hosted agent-sandbox APIs the pillar names — E2B, Modal, Daytona, Cloudflare Sandbox, Northflank, and Vercel Sandbox — comes down to three questions once the isolation layer is settled: does the workload need a GPU, how much do cold start and session length matter, and who should operate the infrastructure underneath it.

Does the workload need a GPU?

Only one of the six, Modal, offers GPU access — A100 and H100 hardware, as of the comparison's June 2026 update. The other five (E2B, Daytona, Cloudflare Sandbox, Northflank, Vercel Sandbox) have no GPU option. For a CPU-bound workload, GPU access isn't a differentiator and the next two questions matter more.

How much do cold start and session length matter?

E2B (Firecracker microVM, ~150 ms) and Daytona (Sysbox containers, under 90 ms via pre-warmed pools) suit a workload spinning up many short-lived sandboxes per minute. Northflank's unlimited sessions and Daytona's persistent, stateful workspace suit the opposite case — a long-running interactive sandbox that shouldn't reset between steps. Vercel Sandbox's fixed 45-minute-to-5-hour cap sits between the two, ruling it out for anything needing to run longer uninterrupted.

Who should operate the isolation infrastructure?

A hosted API means the vendor operates the Firecracker, gVisor, or Kata fleet underneath it, including host-kernel patching and isolation engineering. Self-hosting the same layers gives full control over network topology and compliance boundary at the cost of owning that burden; Northflank's bring-your-own-cloud option, deploying onto a team's own AWS, GCP, or Azure account, is a documented middle path. None of the six vendors publishes usage pricing in this reference — Daytona's $24M Series A in February 2026 is a funding fact, not a cost figure — so treat a cost comparison between them as unverified.

A provider's own built-in tool is a seventh path that skips vendor selection: OpenAI's Code Interpreter and Anthropic's code execution tool run inside the provider's own sandbox. The pillar covers their tool versions and tradeoffs (/articles/agent-security-operations) — the same three questions above still decide whether that built-in isolation is enough or the task needs one of the six dedicated APIs instead.

What does hardening a sandbox harness actually require?

Hardening a sandbox harness requires implementing and verifying six controls mechanically, not just listing them, because an untested policy behaves the same as no policy the first time a sandboxed process tries to exceed it.

• Block network egress by default. Deny all outbound traffic at the sandbox's firewall or proxy layer, then allowlist only hosts a task legitimately needs. Verify by attempting a connection to an unlisted host from inside a live sandbox and confirming it fails.
• Drop privileges. Run the sandboxed process as non-root and apply a seccomp filter denying unneeded syscalls — Firecracker's jailer does this automatically; gVisor or plain-container setups need an explicit profile. Verify with a user-ID check and a syscall audit, not an assumption.
• Wipe the filesystem between runs. Give every execution a fresh overlay or tmpfs mount discarded on exit, and never bind-mount a host directory read-write into an untrusted sandbox. Verify by writing a marker file in one run and confirming the next run can't see it.
• Cap CPU, memory, and wall-clock time. Set limits at the cgroup level or in the microVM's own resource configuration, plus an external timeout that kills the process past deadline. Verify with a runaway test — an infinite loop or a fork bomb — and confirm it gets killed.
• Keep host secrets out of the sandbox entirely. Resolve any credential the code's output might need at the harness layer, never as a sandbox environment variable, matching the rule in managing secrets for AI agents that anything a model or its output can touch counts as disclosed. Verify by scanning the sandbox for known secret patterns first.
• Validate whatever the sandbox hands back. Treat every value, file, or log line a sandbox returns as untrusted output — validate it like an external API response, and watch for content shaped to redirect the agent's next step, the failure mode covered in defending an agent against prompt injection. ChangeGamer applies the same instinct to a different machine-produced input: its own build pipeline fails outright, before anything publishes, if an article declares a resource slug that doesn't resolve in the corpus or a sub-article's body falls under the enforced 900-word floor — its own generated content is something to check, not trust by default.

A sandbox decision checklist

A sandbox choice for agent code execution clears four checks before it is ready for production. The isolation layer must match the task's trust-and-blast-radius quadrant. The vendor or self-hosted setup must match the workload's GPU, cold-start, and session-length needs. Every harness-hardening control above must be implemented and tested, not assumed. And no real secret should ever sit inside the sandbox, regardless of how strong its isolation layer already is.

• Isolation layer chosen from the two-axis framework, not habit
• GPU need, cold-start sensitivity, and session length checked against the six hosted APIs, or a self-hosted setup, before committing to one
• Network egress denied by default and allowlisted explicitly, tested from inside a running sandbox
• Privileges dropped, filesystem wiped between runs, CPU/memory/wall-clock limits enforced and tested against a runaway process
• No host secret injected into the sandbox, and its output validated as untrusted before reaching the next agent step

This decision sits inside the full eight-discipline stack the agent security operations pillar covers, alongside managing secrets for AI agents and defending an agent against prompt injection.

#agents #security #sandboxing #code-execution #microvm #gvisor #firecracker