Sandbox Selection Criteria for Agentic Workloads

Technology comparisons are seductive precisely because they feel tractable. Firecracker versus gVisor versus WASM is a question with published benchmarks and vendor documentation. But selecting a technology before specifying required properties is the same error as buying a lock before deciding what it needs to secure, and I have watched teams make this mistake more than once, usually under deadline pressure and usually with regret.

Five properties define the minimum viable production sandbox, regardless of implementation.

Isolation means agent execution cannot reach host resources it has not been explicitly granted. This sounds like a baseline until you look at what standard containers actually provide: a shared-kernel namespace whose blast radius extends to the host if any kernel vulnerability is reachable from inside. Not theoretical. Structural.

Resource limits require that CPU, memory, network bandwidth, and wall-clock time are bounded at the cgroup level, not the application layer. If an agent can write and execute arbitrary code, it can write code that ignores application-layer limits entirely. Kernel-level enforcement is an essential hardening step; skipping it is a deliberate choice, and it has predictable consequences.

Capability scoping means fine-grained control over which APIs, filesystem paths, and network endpoints are reachable from inside the sandbox. Isolation defines the outer wall; scoping defines what exists within it. Teams routinely conflate the two, and that conflation is where real misconfigurations originate, the ones that look fine in staging and surface in production.

Auditability means every action the agent takes inside the sandbox is observable and logged. A capability granted but unmonitored can be abused without any trail. This property gets skipped more than the others, usually because it is last on the checklist and the deadline arrived first.

Deterministic teardown means the sandbox can be destroyed completely, with no residual state, credentials, or process artifacts surviving. Partial teardown has a name: a cleanup problem that surfaces at the worst possible moment.

Network egress deserves separate treatment. An agent that can reach a cloud provider's metadata service endpoint can acquire host instance credentials from inside an otherwise well-isolated environment. The correct default posture is deny-all with explicit allowlists for required endpoints, not a hardening option, but a baseline requirement that gets misclassified as advanced configuration more often than it should.

These five properties function as a filter. Any technology that fails on even one of them is the wrong choice for the threat model, whatever its benchmark numbers say. The migration of major cloud providers away from standard runc containers toward hardware-enforced isolation over the past several years is not incidental; it reflects where the industry has actually landed, even when the marketing materials haven't caught up.

The isolation technology options and what each actually trades away

Four isolation approaches dominate production deployments in 2026. Understanding what each concedes is more useful than reading feature matrices, and more straightforward than how vendors tend to present the tradeoffs.

Standard containers are fast to start and broadly compatible. They are also the wrong choice when the code being executed is untrusted. The shared-kernel architecture means a container breakout is a host compromise, not a risk to mitigate through defense-in-depth, but a structural outcome of the isolation model. Standard containers are appropriate for trusted internal automation where the code author is known and controlled. For LLM-generated code, they are unsuitable.

gVisor interposes a user-space kernel, the Sentry process, which intercepts syscalls before they reach the host kernel. The attack surface shrinks substantially because only a minimal vetted subset of syscalls passes through. The cost is real: I/O-heavy workloads carry overhead in the range of 20 to 50 percent, paid under sustained load rather than at startup. Compatibility is the other risk. Teams should review gVisor's syscall compatibility list against any target workload before migration, because some applications break in ways that don't surface during initial testing. gVisor fits best in compute-heavy multi-tenant contexts where full VM isolation is operationally heavier than the threat model demands.

Firecracker microVMs give each workload a dedicated Linux kernel inside KVM. An attacker must escape both the guest kernel and the hypervisor, two independent boundaries. Firecracker's implementation spans roughly 50,000 lines of Rust, compared to approximately 1.4 million lines of C in QEMU; that translates directly to a smaller auditable attack surface. This is the isolation layer under AWS Lambda and AWS Bedrock AgentCore. For production execution of untrusted or LLM-generated code, the microVM represents a defensible minimum isolation floor.

WebAssembly occupies a distinct point in the design space. The capability model means modules start with zero privileges and acquire only explicitly granted capabilities. Linear memory isolation prevents a WASM module from reading or writing outside its own contiguous memory array. Startup happens in microseconds, orders of magnitude faster than any container or VM approach. WASI 0.2 and the Component Model stabilized in early 2024, moving WASM from experimental to production-grade for eligible workloads. The hard constraints matter: no persistent filesystem, limited syscall support, and a requirement to model the workload as capability-scoped stateless operations. Known JIT-based CVEs in V8-based WASM have structural analogues in server-side runtimes like Wasmtime and WasmEdge, so JIT escape risk remains active.

A practical starting heuristic: if the agent needs a shell and package managers and the code author is untrusted, start at microVM. If the compatibility matrix is acceptable and overhead matters, consider gVisor. If the workload can be modeled as capability-scoped stateless operations, prefer WASM. These are starting points, not conclusions, and the specifics of a workload will shift the answer.

Isolation depth: calibrating the security boundary to the actual threat model

The cardinal question is not how secure a sandbox is in the abstract. It is who wrote the code being executed and what permissions that code runs with. A harder question: what if the code author changes over time, say, an internal tool that begins incorporating LLM-generated patches? The same sandbox that adequately contains a trusted internal script may offer no meaningful protection against adversarially crafted LLM-generated code. The threat model is not static, and sandboxes selected for one version of it tend to outlast their original assumptions.

Threat model tiers map to isolation choices roughly as follows. Trusted internal automation, with known authors and reviewed code, can usually be handled by hardened containers. Capability-scoped tool invocations that are stateless and require no shell access are well-suited to WASM or V8 isolates. Untrusted or LLM-generated code requiring shell access demands a microVM floor, with gVisor as a lighter fallback depending on how the specific threat model assesses kernel exploit risk.

Regulated data adds a compliance dimension that sits above the security analysis. PII, financial records, and health data frequently require hardware-enforced isolation by policy, even when the pure security analysis might tolerate a lighter boundary. Compliance requirements often encode lessons from breach post-mortems. Reading them as signal rather than dismissing them as bureaucratic constraint is a disposition that tends to develop after one painful incident.

MCP tool invocations deserve specific treatment here. A malicious tool published to a marketplace can embed instructions that execute when an agent invokes it. WASM's capability model transforms every such invocation from an implicit trust decision into an explicit, monitorable, revocable capability grant. That structural advantage is worth preserving by design, not reconstructing through configuration after the fact.

The OWASP classification of unbounded resource consumption as a top-tier risk connects isolation depth to resource enforcement directly. An under-isolated sandbox that allows cgroup bypass can be weaponized for denial-of-service from within. A team that under-isolates to hit a latency target has traded a hard security boundary for a soft performance preference; that preference tends to feel less important after an incident.

Cold-start latency and where it becomes a user-experience constraint

Framing cold-start time as a performance optimization concern misses the actual problem. For interactive agentic applications, it is a user-experience hard constraint, and it interacts with isolation tier selection in ways that cannot be deferred until after launch.

A coding agent making several sequential tool calls stacks cold-start overhead across each call. That infrastructure delay accumulates before any computation happens. Users don't experience latency as a technical tradeoff; they experience it as a broken product. Waiting on infrastructure that adds nothing to the answer is qualitatively different from waiting on computation, and users make that distinction faster than most engineers expect.

The relative ordering by startup time in 2026 is stable. WebAssembly is fastest by orders of magnitude, constrained to stateless capability-scoped workloads. Firecracker microVMs achieve sub-second cold starts; Daytona reports sub-90 milliseconds, which they describe as among the fastest in the microVM category. gVisor-wrapped containers sit between microVMs and standard containers at startup, with meaningful overhead appearing under sustained I/O load rather than at initialization. Standard containers are fast at startup but disqualified for untrusted code regardless of that advantage.

Snapshot-based warm resumption changes the calculus significantly. Rather than cold-starting a new environment, a hibernated sandbox restores its prior filesystem and memory state in well under a second, eliminating re-initialization steps like cloning repositories or reloading datasets. The latency penalty for isolation is substantially a solved problem once snapshot-resume is available; the question is whether the platform actually supports it, and that question is worth asking before committing.

The latency criterion is not a reason to choose a weaker isolation tier. It is a reason to demand snapshot-resume support from whichever isolation tier the threat model requires. Teams running GPU-intensive agents face a compounding version of this: CPU-side task-coordination latency accounts for the majority of total delay in many agentic pipelines, which means cold-start overhead on the CPU layer hurts throughput even when GPU capacity is plentiful.

Session duration and statefulness: the dimension most evaluation frameworks miss

Most evaluation frameworks treat agent workloads as batch jobs: a task arrives, a sandbox starts, work completes, environment terminates. This is not what agent workloads look like in practice. They are long-lived, mostly idle, with brief bursts of activity. A developer agent managing a multi-day refactoring task is idle most of the time, but the state it accumulates across those bursts is the work product. The lifecycle demands suspension and rapid resumption, not cold-start-optimized ephemerality.

I have seen teams evaluate platforms thoroughly against latency and isolation criteria and then discover, in production, that a session time cap breaks workflows designed to maintain agent state across user interactions over days or weeks. Some platforms cap sessions at 24 hours. That constraint is easy to miss during evaluation, and when a production workload hits it, the fix is not a configuration change; it is a platform migration.

The practical difference between statefulness models is significant. Filesystem-only persistence loses process state at each suspension boundary; the agent must re-initialize tools, re-clone repositories, and re-load context at each resumption. Filesystem plus memory persistence, including running processes, allows the agent to resume exactly where it left off. Snapshot-based environments go further: new environment instances can be forked from a saved state, enabling parallelization across branches of a workflow and rollback when a branch goes wrong.

For agents whose orchestration outlives any single sandbox session, durable workflow engines offer a complementary architectural pattern. Orchestration code runs inside a durable workflow; model calls and tool invocations run as activities; state replays cleanly from an event-history log if a worker fails or a session expires. The sandbox handles execution isolation. The workflow engine handles durability across arbitrarily long timeframes. These are distinct responsibilities that compose well when both are present and cause interesting failure modes when either is absent.

The statefulness requirement interacts directly with isolation choices. MicroVMs support full memory snapshots. WASM's structural absence of persistent filesystem support makes it unsuitable for stateful agents regardless of its other properties. The capability model cannot substitute for a missing persistence layer, a limitation that is obvious in retrospect but frequently discovered the hard way.

Tool-call surface and capability scoping inside the sandbox

Isolation sets the outer wall. Capability scoping defines what the agent can actually touch within that wall. Conflating the two creates false confidence that is difficult to detect until something goes wrong, and by then the question is usually not whether a misconfiguration occurred but how long it had been present.

Tool-call surface includes filesystem paths with their read and write scope, network egress with its endpoint and protocol specificity, environment variable visibility where credentials frequently live, subprocess spawning, and package installation rights. Each element is a potential pivot point. An agent with unrestricted network egress inside a microVM can still exfiltrate data to arbitrary external endpoints. An agent with environment variable access can read credentials it was never intended to see, and the microVM boundary does nothing to prevent that.

Network egress is the highest-consequence capability in this list. Default-deny with explicit allowlists is the correct posture; default-allow with blocklists is wrong, because blocklists depend on knowing in advance what should be blocked. Teams must explicitly and specifically block cloud metadata service endpoints, rather than assume they are unreachable because the sandbox seems well-isolated.

WASM's capability model makes scoping explicit and auditable by construction. Every capability is a named grant visible in the module manifest, rather than an ambient permission inherited from the process. For non-WASM sandboxes, operators must configure capability scoping deliberately; the isolation technology does not provide it automatically. That gap is a persistent source of misconfiguration in practice.

MCP-based tool invocations compound the scoping problem. Agents may invoke dozens of tools across a single session. Each invocation should carry its own capability scope rather than inheriting the agent process's full permission set. The alternative is a permission model that is technically enforced at the boundary but effectively flat in practice, a distinction that rarely surfaces in vendor documentation.

Auditability is the enforcement partner of scoping. A capability granted but unlogged cannot be investigated after the fact. Scoping without auditability is policy without accountability, and the gap between them is where incidents become mysteries.

Operational fit: GPU access, concurrency, and how the sandbox integrates into existing infrastructure

GPU access determines which platforms are viable for ML-intensive agents, and teams consistently discover this late in evaluation processes. Agents that run inference or fine-tuning alongside code execution need GPU-enabled sandboxes, and only a subset of platforms offer this. Teams add this requirement to evaluation checklists only after discovering it missing in production.

The CPU-to-GPU ratio question is more nuanced than raw GPU availability. Agentic pipelines are coordination-heavy on the CPU side, and the industry has been quietly recalibrating compute ratios toward something closer to parity for agentic workloads, compared to the GPU-skewed configurations that dominated earlier ML infrastructure. A pipeline bottlenecked on CPU-side orchestration does not benefit from additional GPU headroom.

Concurrency requirements for multi-agent pipelines introduce a second operational dimension. Spinning up many simultaneous sandboxes under burst traffic demands either pre-warmed pools with warm-resume capability or snapshot-fork support that allows rapid environment cloning from a known-good baseline. The difference between these two approaches matters for cost structure and for how quickly new environments become available under load.

Integration surface is where operational fit becomes most concrete. CI/CD pipeline integration, SDK language support, Kubernetes scheduling compatibility, and observability tooling compatibility all determine whether a sandbox fits into existing infrastructure or demands a parallel operational track. A sandbox that requires a dedicated operations team to maintain creates organizational debt that compounds quietly until staffing becomes a constraint.

Pricing models interact with workload patterns in ways that are easy to underestimate during procurement. Per-second billing suits short-lived burst workloads. Session-based pricing suits long-running agents with idle periods. Compute-only billing that charges for active execution rather than wall-clock session time fits agents that are mostly idle but expensive during their active bursts. The workload profile should drive pricing model selection, not the reverse.

Vendor risk is underweighted in most technical evaluations, which tend to focus on the sandbox itself and treat the vendor as a stable given. The agent infrastructure market in 2026 includes several well-funded startups operating at scale alongside cloud-native offerings from major providers. Startup platforms may offer more flexibility and tighter latency characteristics, but production workloads that depend on them carry concentration risk. Infrastructure markets have seen providers change direction, change terms, or simply wind down; treating that as a planning assumption rather than a remote contingency is not pessimism, it is operational experience. The argument that a single best-in-class vendor is sufficient if the API is well-documented requires the vendor to remain stable, solvent, and aligned with your workload requirements for the foreseeable future. A two-provider strategy with compatible APIs, or a platform built on an open standard like the Open Container Initiative or WASI, preserves optionality in ways that feel unnecessary until they are not.