Sandbox Selection Criteria for AI Agent Code Execution

AI agent code execution demands a different sandbox evaluation than conventional cloud security because the code running in production was never written by a human, reviewed in a pull request, or tested in CI/CD. This piece lays out the criteria that actually determine an agent sandbox's fitness for purpose: isolation model, cold-start latency, statefulness, and network egress control, in that order, because each one builds on the last.

Selecting a sandbox for AI agent code execution is a different problem from general cloud security

Traditional applications ship with an instruction set fixed at compile time or deploy time, something an engineer wrote, a reviewer approved, and a test suite exercised before it ever touched production. Autonomous agents break that chain entirely: they generate novel code from natural language at runtime, then execute it, call APIs, read files, and manipulate databases without a human in the loop at the moment of execution. That shift changes what "securing the application" even means, because the thing being secured was not known in advance.

The urgency behind this is not speculative. Andronchik et al. (2026) place the concern on a present-tense timeline, citing research showing that an adversary can meaningfully improve an offensive cybersecurity agent's capability with minimal compute and no outside assistance. On the supply chain side, a meaningful share of AI-recommended packages are hallucinated names that do not correspond to anything real, and a significant fraction of those hallucinated names repeat consistently enough that an attacker can register them in advance and wait. An agent that trusts its own suggestion and installs a package is, in that scenario, installing exactly what the attacker planted.

None of this means the code is simply lower quality and will improve as models do. The execution boundary, not the model's judgment, is the place where these risks have to be stopped. That reframes sandbox selection: it is not a performance knob to tune after the architecture is set, it is the primary control that decides whether an autonomous agent can run in production safely at all. The rest of this piece works through the four criteria that govern that runtime boundary, starting with the one that sets the floor for everything else: isolation.

Isolation Model and the Security Boundary an Agent Operates Inside

Isolation comes first because it determines blast radius. A kernel-level CVE inside one container can reach the host and every co-tenant on it. Practitioner consensus heading into 2026 holds that shared-kernel container isolation is not sufficient for code generated by an LLM or supplied by an untrusted user.

Five isolation levels span the space between "convenient" and "hostile-code safe," and the engineering decision is matching the level to how much the code can be trusted. Containers like Docker and Podman are at the bottom, offering process-level isolation on a shared kernel, appropriate only for code written internally and already trusted. User-space kernels like gVisor intercept syscalls without running a full virtual machine, which gives stronger guarantees than containers at the cost of narrower compatibility and some tradeoffs in how completely syscalls get emulated, making it a good fit for multi-tenant SaaS products and CI/CD pipelines. Firecracker boots in roughly 125 milliseconds with under 5 MiB of memory overhead per instance, and Kata Containers tends to be the preferred choice in regulated industries and zero-trust environments. Above that sits the library OS model, exemplified by Microsoft's LiteBox, where the application runs inside a minimal OS layer that narrows its interface to the host down to a controlled set of primitives exposed through North/South interfaces. This produces the smallest theoretical attack surface in theory, but as of early 2026 it remains experimental, with unstable APIs, no stable SDK release, and no reported production usage. At the top is confidential computing, using hardware like AMD SEV-SNP or Intel TDX to encrypt memory so that even the host operating system and hypervisor cannot read what is inside the sandbox, a guarantee that matters most for regulated industries handling PII, financial records, or healthcare data.

The decision rule that makes this spectrum actionable runs on trust level, not convenience. LLM-generated code, even something as modest as a Python script written to solve a math problem or reformat a file, carries meaningfully higher risk and needs gVisor or a microVM to guard against accidental resource exhaustion or a logic bomb buried in generated code. User-uploaded binaries and autonomous agents installing packages without a human vetting them first need to be treated as actively hostile, which calls for hardware virtualization through Firecracker or an air-gapped primitive. Language-level isolation is a newer category: V8 isolates, the mechanism behind Cloudflare Workers and Deno Deploy, start in microseconds by virtualizing the JavaScript runtime itself, and WebAssembly combined with WASI offers a capability-based model where a module cannot touch anything outside its own memory unless the runtime explicitly grants access. Both are useful, but for specific and fairly constrained use cases rather than as general-purpose answers.

One might argue that picking the right engine class settles the question, but it doesn't. Andronchik et al. (2026) found that engine classes, meaning microVM, userspace kernel, and OCI container as categories, separate cleanly from each other on every architectural axis measured, but products built within the same engine class do not separate cleanly from one another. The engine class sets the floor; the specific product's implementation determines the actual security posture a team ends up operating. Downstream lag, the time between a fix landing in the engine and that fix reaching the product a team actually runs, spans anywhere from zero days to over 471 days, and in some cases isn't disclosed at all. The question to ask any vendor is not "which engine do you use," but "how long after a disclosed vulnerability in that engine does your product ship the fix."

Cold-start latency as a correctness requirement for agent workflows

Isolation sets the security boundary, but every isolation level carries a latency cost, and that cost compounds in ways that go beyond user experience. The practical framing practitioners use is blunt: the first production user who sits through several seconds of sandbox boot time experiences the product as broken, not slow.

The isolation-versus-latency spectrum is a real engineering tradeoff. One microVM-based approach delivers hardware-level isolation through a virtualized kernel boundary with boot times under 125 milliseconds. gVisor boots faster still, at the cost of some of the completeness in syscall interception that gives microVMs their stronger guarantee. Browser isolates start in under 50 milliseconds, which sounds like the clear winner, but they support a narrower set of languages, which confines them to specific use cases rather than general agent workloads.

But what if the choice between strong isolation and low latency isn't really a choice? The architectures that resolve this tension don't pick a side, they decouple provisioning from the request path entirely. Blaxel's implementation of this pattern offers perpetual standby with resume times under 25 milliseconds, preserving filesystem, memory, and running processes across the gap. Standby kicks in automatically after a short stretch of network inactivity, and billing during that standby period covers only snapshot storage.

This changes what the right question to ask a vendor actually is. Raw cold-start latency is the worst-case number, and a well-designed platform is built to make that worst case rare rather than typical. The number that matters day to day is resume latency from standby. Teams evaluating a platform should ask for three distinct figures, since standby-resume latency measures how long it takes to wake a hibernated sandbox with its prior state intact. These are not interchangeable numbers, and a vendor quoting only the best of the three is telling an incomplete story. Session-length limits add another constraint: Vercel Sandbox, for example, tiers session length on its Hobby plan and extends it substantially on Pro and Enterprise. A platform with excellent resume latency but a short session ceiling may still be the wrong fit for a long-running agent task.

Statefulness in an agent sandbox and the wrong assumption of ephemeral-by-default

Latency pressure naturally pushes teams toward solutions that avoid re-provisioning altogether, and that's where statefulness enters as its own criterion, separate from both isolation and speed. The field's instinct is to treat ephemeral sandboxes, destroyed immediately after each run, as the inherently safer default. That instinct is correct for a narrow category of work and wrong as a general rule. Ephemeral environments make sense for user-submitted scripts and one-off AI-generated tool calls, where isolating each execution from the next is the main requirement and nothing needs to carry forward. But coding agents, PR review agents, and data analysis agents operate differently: they need to hold filesystem state, installed dependencies, and the results of prior analysis across many invocations, and tearing all of that down after each step forces expensive re-provisioning and throws away context the agent needs to do its job.

The safety objection to persistence, that a long-lived sandbox is inherently riskier than a disposable one, does not hold up once isolation and patching are handled properly. A persistent sandbox built on solid isolation, current patching, and active monitoring can be as safe as an ephemeral one. Persistence is a question for the isolation layer to answer, not a reason to avoid statefulness in the first place. MicroVM-based sandboxes fit agents that execute code, and durable-execution platforms fit agents running long-horizon autonomous tasks.

The harder version of this problem, how to preserve state cheaply without re-paying the full provisioning cost on every step, is now an active research question rather than a solved one. Both operate in the hundreds-of-milliseconds-to-seconds range, and that range directly caps how many steps per second an agent can realistically take. DeltaBox, proposed by Dong et al. in 2026, points at a different architecture: because consecutive checkpoints in an agent's workload tend to be highly similar, with only small incremental changes from one step to the next, the system duplicates only the changes rather than the full state each time. In evaluations on SWE-bench and reinforcement-learning micro-benchmarks, DeltaBox achieved checkpointing in 14 milliseconds and rollback in 5 milliseconds. It is a signal of where the field is heading: toward treating state persistence as a diff problem rather than a full-snapshot problem, which is the only way the latency and statefulness goals stop fighting each other, though it is not a number to plan a production deployment around today.

There is also a layering distinction: framework-level checkpointing, the kind LangGraph and LangChain provide, captures an agent's logical state, meaning where it is in its reasoning chain, but it cannot undo the physical effects of commands the agent already executed, like a file it deleted or a row it wrote to a database. DeltaBox addresses that gap by operating at the OS and filesystem level, supplying the physical-state layer that framework checkpointing does not reach. A team relying on LangGraph's checkpointing alone may believe it can roll an agent back to a safe state when, in fact, only the agent's reasoning rolls back, not the damage already done to the filesystem.

Evaluating a platform's statefulness model comes down to four concrete questions: what authority the executed code actually receives, where credentials and network policy are stored and enforced, what data survives between runs, and who is responsible for managing the sandbox infrastructure itself. Different platforms answer these differently. Blaxel preserves filesystem, memory, and running processes through standby, but that state does not survive if the sandbox itself is deleted. Fly.io's Sprites take a different approach: persistent Firecracker microVMs backed by 100GB of NVMe storage, with compute billing that stops while idle, though storage costs continue regardless. The right answer depends on whether the agent in question needs state to survive a deletion event or just needs it to survive between calls, and that distinction should be settled before, not after, choosing a platform.

How network egress policy shapes what an agent can do to systems beyond the sandbox boundary

A sandbox can get isolation and statefulness both right and still leave a serious gap open, because isolation governs what happens to the code, not what the code is allowed to reach. Open network egress means a compromised or simply misbehaving agent can call internal APIs, connect to databases that were never meant to be agent-accessible, and exfiltrate sensitive data straight out of a session that is, by every other measure, properly isolated from the host.

This gap is documented in practice, not hypothetical. Invariant Labs' 2026 research, cited in Uchibeke (2026), found that more than 492 MCP servers were running in production exposed without any authentication or encryption at all. Isolation and egress control answer different questions: a sandbox contains the blast radius of code that misbehaves inside it, but containment alone does not prevent that code from taking unauthorized action against something outside the boundary. Pre-action authorization, sandboxed execution, and model-based screening each cover a different part of that problem, and they work best as complementary layers rather than substitutes for one another.

What follows is a reason to treat egress policy as its own line item in sandbox evaluation, alongside isolation, latency, and statefulness, instead of assuming a strong isolation story already covers it. The 492-server figure is a reminder that this question gets skipped often enough, in production, for the gap to be measurable rather than theoretical.