# How to Choose a Sandbox for AI Agent Code Execution

> 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.

Guide: Agent security operations — part 3
Published: 2026-09-13 · Updated: 2026-09-13 · 1600 words · ~2128 tokens (estimate)
Canonical: https://changegamer.ai/articles/choosing-a-sandbox-for-ai-agent-code-execution
JSON: https://changegamer.ai/api/articles/choosing-a-sandbox-for-ai-agent-code-execution.json
Pillar: https://changegamer.ai/articles/agent-security-operations.md

## In short

- Choosing a sandbox for AI agent code execution rests on two variables working together — where the code being run came from, and what a break-out from that sandbox could actually reach — not on defaulting to the strongest isolation layer available.
- Fully untrusted, model-generated code destined for a high-value environment holding real secrets calls for a microVM such as Firecracker or Cloud Hypervisor at minimum, never a plain Docker container, regardless of how convenient a plain container is to run.
- Among the six hosted agent-sandbox APIs compared as of June 2026 — E2B, Modal, Daytona, Cloudflare Sandbox, Northflank, and Vercel Sandbox — only Modal offers GPU access, with A100 and H100 hardware.
- Blocking network egress by default only counts as hardening once outbound traffic is denied at the sandbox's firewall or proxy layer and re-tested after every allowlist change, not merely documented as an intended policy.
- No published source in the hosted-sandbox comparison states usage pricing for any of the six vendors, so treat a specific cost comparison between them as unverified rather than filling that gap with an estimate.

---

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](/articles/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](/articles/prompt-injection-defense-in-depth-for-agents), 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](/articles/credential-hygiene-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.

| Quadrant | Example task | Minimum layer | Why |
|---|---|---|---|
| Fully untrusted, low blast radius | Coding-assistant sandbox running arbitrary generated snippets, no secrets, filesystem wiped each run | Hardened runtime (gVisor) | Zero trust in the source still means a plain container's shared kernel is one exploit from every other tenant on the host |
| Fully untrusted, high blast radius | Agent-written code with network reach into production or a live credential | MicroVM (Firecracker or Cloud Hypervisor) | Both variables are worst-case at once — the exact situation the pillar's "plain container is not a security boundary" warning targets |
| Semi-trusted, low blast radius | Code reviewed under Code-Then-Execute, run in a disposable environment with no real data | OS container | Review removed most of the source-trust risk, and the environment has nothing worth escaping toward |
| Semi-trusted, high blast radius | Reviewed code that still touches a shared, production-adjacent resource | Hardened runtime or microVM | Review lowers but doesn't eliminate risk, so blast radius alone justifies real isolation |

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](/articles/credential-hygiene-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](/articles/prompt-injection-defense-in-depth-for-agents). 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](/articles/agent-security-operations) pillar covers, alongside [managing secrets for AI agents](/articles/credential-hygiene-for-ai-agents) and [defending an agent against prompt injection](/articles/prompt-injection-defense-in-depth-for-agents).

## Frequently asked questions

### How do you decide which isolation layer to use for an AI agent's code execution?

Deciding which isolation layer to use starts from two variables crossed against each other — where the code being executed came from (fully untrusted, adversarial model output versus semi-trusted, reviewed code) and what a break-out could reach (a low-value ephemeral environment versus a high-value environment holding real secrets or persistent data) — with fully untrusted code aimed at a high-value target requiring at minimum a microVM such as Firecracker or Cloud Hypervisor, never a plain Docker container.

### Which hosted AI agent sandbox APIs offer GPU access?

As of June 2026, only Modal offers GPU access among the six hosted agent-sandbox APIs in the code-execution-sandboxing comparison — E2B, Modal, Daytona, Cloudflare Sandbox, Northflank, and Vercel Sandbox — with A100 and H100 hardware available; the other five have no GPU option, so a workload that needs GPU compute inside the sandbox itself has exactly one match in that comparison.

### Should a team self-host sandbox infrastructure or use a hosted agent-sandbox API?

Self-hosting sandbox infrastructure such as Firecracker, gVisor, or Kata Containers gives a team full control over network topology and compliance boundary at the cost of owning the operational burden of patching host kernels and running multi-tenant isolation directly, while a hosted agent-sandbox API shifts that operational burden to the vendor; Northflank's bring-your-own-cloud option, deploying onto a team's own AWS, GCP, or Azure account, sits as a documented middle path, and no usage-pricing data exists in the source comparison to settle the choice on cost alone.

### What counts as sufficient network egress hardening for an agent's code sandbox?

Sufficient network egress hardening means outbound traffic is denied by default at the sandbox's firewall or proxy layer with only specific, legitimately needed hosts allowlisted, and that block is confirmed by actually attempting a connection to an unlisted host from inside a running sandbox rather than by checking that a policy document describes the intended behavior.


---

## The rest of this guide

- [How to Secure AI Agents in Production](https://changegamer.ai/articles/agent-security-operations.md): Credential hygiene, prompt-injection defense in depth, sandboxing choices for code execution, supply-chain provenance, least privilege, audit trails, incident response, and rate/abuse controls — eight operator-side defenses against an adversarial actor or a compromised dependency, not against ordinary load or failure.
- [How to Manage Secrets for AI Agents in Production](https://changegamer.ai/articles/credential-hygiene-for-ai-agents.md): Why single-agent credential issuance is not the whole secrets problem: auditing which tool servers and MCP connectors hold credentials on an agent's behalf, treating provider-side prompt caches as a disclosure surface, and the named frameworks — OWASP's Secrets Management Cheat Sheet, Twelve-Factor config, and the OWASP GenAI project — that govern the rest.
- [How to Defend an AI Agent Against Prompt Injection](https://changegamer.ai/articles/prompt-injection-defense-in-depth-for-agents.md): A decision framework for matching Action-Selector, Plan-Then-Execute, Dual LLM, and the other named architectural patterns to a task's actual blast radius, including when to compose two patterns together and when none of them is worth the overhead.
- [How to Verify Supply-Chain Provenance for AI Agent Dependencies](https://changegamer.ai/articles/supply-chain-provenance-for-ai-agents.md): An operational playbook for three separate trust-boundary gates — package-install time, model-load time, and MCP-server-connect time — that turns SBOM and attestation formats into checks a pipeline can actually run, plus a fail-closed default for the dependency that carries neither.
- [How to Enforce Permission Boundaries for AI Agents at Runtime](https://changegamer.ai/articles/permission-boundaries-and-least-privilege-for-ai-agents.md): How a least-privilege grant actually gets enforced once an agent is running — the eight named checkpoints, five verdicts, and fail-closed contract in Microsoft's draft Agent Control Specification (ACS), and what happens when the policy engine that enforces the boundary breaks.
- [How to Build an Audit Trail for an AI Agent](https://changegamer.ai/articles/audit-trails-for-ai-agents.md): A field-by-field forensic playbook for an AI agent audit log: why each of the checklist's seven required fields matters for reconstruction, a worked incident walkthrough, and the real tension between OpenTelemetry's redact-by-default tracing and full audit logging.
- [How to Respond When an AI Agent Takes a Harmful Action](https://changegamer.ai/articles/security-incident-response-for-ai-agents.md): Why the pillar's cut-credential, stop-instance, export-evidence order is structurally forced rather than a tidy convention, a concrete answer for who holds standing revocation authority, a pre-incident drill for the evidence-export path, and what changes when the compromised credential belongs to a third-party tool server instead of the agent itself.
- [How to Rate-Limit and Cap Spend for Your Own AI Agent](https://changegamer.ai/articles/rate-and-abuse-controls-for-ai-agents.md): Enforcement mechanics for the two ceilings an agent operator should set before production: where a per-credential tool-call counter has to live to stay correct under concurrent calls, where a spend ceiling gets checked in the tool-call loop, and how to reject out-of-scope tool-call arguments with canonicalization rather than a naive prefix match.
- [How to Verify Content Provenance for AI Agents with C2PA](https://changegamer.ai/articles/content-provenance-for-ai-agents.md): A three-state decision procedure — valid manifest, invalid signature, absent manifest — for what an AI agent's ingestion pipeline should do differently with a web image, an email attachment, or a retrieved document, plus a checklist for wiring a C2PA reader library into that pipeline as a gate before content reaches the model.
- [How AI Agents Prove Identity and Delegated Authority](https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents.md): The two-layer model an autonomous agent needs to pass before any credential-custody or permission question even applies: a cryptographic workload identity proving what it is (SPIFFE/SPIRE, cloud workload identity federation) and a separate delegated-authority grant proving it may act on a human's or org's behalf (OAuth scopes, RFC 8693 token exchange, RFC 8707 audience binding).
- [How to Protect PII and Personal Data in AI Agent Pipelines](https://changegamer.ai/articles/data-privacy-and-pii-for-ai-agents.md): Why an AI agent expands PII exposure past a bounded API call — large ingested context, external tool calls, persistent memory and logs, provider training risk — and the containment controls, provider data-handling terms, and GDPR/EU AI Act/CCPA compliance boundary that follow from it.
- [The AI Agent Security Checklist](https://changegamer.ai/articles/agent-security-operations-checklist.md): A go/no-go checklist that turns the agent security operations pillar's eight disciplines, plus content provenance, agent identity, and data privacy, into checkable gates — the specific inventory row, test result, or logged decision that proves each one holds, with a link to whichever sibling article owns its mechanics.

## Reference resources

- https://changegamer.ai/resources/code-execution-sandboxing.md

All guides: https://changegamer.ai/api/articles.json · Reference corpus: https://changegamer.ai/llms.txt
Licensing: https://changegamer.ai/api/pricing.json (offer catalog) · https://changegamer.ai/api/payment.json (payment methods, HTTP 402 flow) · access guide: https://changegamer.ai/resources/access-and-pricing.md