Container vs MicroVM Sandboxes for Agent Workloads

What happens the moment the sandbox doesn't hold gets decided long before anyone talks about latency or pricing. Standard Docker containers share a kernel across every workload on the host, and that shared kernel is a single point of failure the moment untrusted, LLM-generated code enters the mix. Picking between containers, gVisor, and microVMs is a security decision first and a performance decision second. Get that order backward and you'll find out why the hard way, usually after the fact, usually in production.

Standard containers, whether run through Docker or Podman, use Linux namespaces and cgroups to keep processes apart. That separation is logical: the same kernel handles every container on the host, so a container escape or a kernel bug turns one compromised workload into a compromise of everything else sitting on that machine. For trusted, internally written code running single-tenant, that's a fine trade. Startup takes milliseconds, density is high, overhead is close to nothing. But that model was never built for code an LLM writes at runtime, and it shows the moment you point one at it. Plain containers are the wrong default for agent sandboxing, full stop, and any team using them for untrusted code because the tooling was already lying around is making a bet it hasn't priced correctly.

gVisor sits a tier above. Instead of letting a sandboxed program call the host kernel directly, it runs a process called Sentry in user space that intercepts every syscall first. Hundreds of possible kernel calls get filtered down to a small, vetted subset before anything touches the real kernel, a meaningful cut to the attack surface. It isn't free, though: I/O-heavy workloads see something like 10 to 30% overhead, and not every Linux syscall gets emulated perfectly, so some software behaves oddly once it's inside. Startup stays fast, in the same millisecond range as a plain container. Call gVisor the middle child: stronger than a namespace boundary, weaker than a hardware VM, and a sensible fit for multi-tenant SaaS or CI/CD pipelines where paying the full cost of a VM on every single job is hard to justify.

MicroVMs push isolation down to the hardware layer. Each workload gets its own Linux kernel, running on KVM, so a kernel exploit inside one VM has no path to the host or to any neighboring VM. Firecracker is the reference implementation: it boots in roughly 125 milliseconds, adds less than 5 MiB of overhead per VM, and can spin up 150 VMs per second on a single host. Those numbers aren't the product of clever tuning. They come from cutting things out. Firecracker skips GPU passthrough, CPU hotplugging, and nested virtualization, and that minimalism is the security argument, not a gap someone forgot to patch.

Cloud Hypervisor keeps that same minimal spirit but adds back some of what Firecracker leaves out: configurable nested KVM as of December 2025, VFIO device passthrough for GPUs, CPU and memory hotplugging, and support for Windows guests. The cost is a few dozen extra milliseconds of boot time and a somewhat larger attack surface. Kata Containers takes a different approach again, orchestrating Firecracker, Cloud Hypervisor, or QEMU underneath while presenting a standard container API on top. From Kubernetes' point of view, a Kata pod looks like any other pod. Underneath, it's a hardware-isolated VM booting in around 200ms. For teams that need VM-level isolation without rewriting how they already deploy to Kubernetes, Kata is the path of least resistance.

An emerging tier is taking shape, even if it isn't ready for production traffic: WebAssembly isolates and library OS designs, such as Microsoft's LiteBox running on AMD SEV-SNP confidential computing. The idea has real promise for workloads that need confidential compute guarantees, but LiteBox is still experimental and hasn't earned anything close to the years of production hardening Firecracker got running inside AWS Lambda. Betting a production system on it today is a bleeding-edge bet worth watching, not building on.

Higher isolation is not automatically better isolation for your problem. Containers trade security for speed. gVisor trades some compatibility and I/O throughput for a much smaller kernel attack surface. MicroVMs trade startup time and density for a blast radius that hardware, not software convention, enforces. Pick based on what's actually running.

Reading your threat model before picking a primitive

None of these primitives is "best," and anyone selling one as a universal answer is selling something. Each tier answers a different question about what your system needs to survive. The job is matching the isolation guarantee to the actual threat, not defaulting to whichever tool is fashionable this year.

Start with who writes the code. Internal developers, reviewed and trusted, are one threat model. LLM output, which should be treated as untrusted by default no matter how good the model's track record looks, is a completely different one. Then ask whether the environment is multi-tenant. In a multi-tenant setup, a breach in one tenant's sandbox is a breach of every other tenant's data sitting on that host, and that fact alone should push the decision toward microVM-level isolation regardless of what the performance budget would prefer.

Blast radius matters just as much as tenancy. A compromised sandbox might reach a production database, a secrets store, or a downstream API with write access. The larger that reach, the stronger the isolation needs to be, no exceptions. Regulatory context adds a fourth axis: financial services, healthcare, and other regulated environments need hardware-level isolation plus a full audit trail of every tool call and every network egress, and no amount of clever sandboxing substitutes for that trail when an auditor comes asking.

This isn't a hypothetical risk analysis. Industry research has found that a large majority of organizations report confirmed or suspected AI agent security incidents, and more than half of all agents run with no security oversight or logging at all. That gap, between how fast agents get shipped and how slowly governance catches up, is exactly where incidents happen. Prompt injection is the clearest example: an agent manipulated through its own inputs gets steered into probing the host kernel or pulling secrets it was never meant to touch, and no amount of application-layer input validation closes that hole once the code is already running on the machine. If your threat model stops at the prompt layer, it isn't a threat model, it's a hope.

A few rules of thumb turn this into an actual decision instead of a debate. LLM-generated code running multi-tenant means a microVM, Firecracker or Kata, is the floor, not a nice-to-have. LLM-generated code that's single-tenant and I/O-heavy makes gVisor a reasonable middle ground, provided someone actually measures the overhead instead of assuming it's tolerable. Workloads that need GPU access point toward Cloud Hypervisor or Kata, since vanilla Firecracker has no passthrough story at all. Any deployment with a regulatory requirement for on-premises or BYOC hosting should rule out cloud-only platforms early, before isolation quality even enters the conversation.

None of this replaces the layers that sit around the sandbox. Network egress controls, scoped credentials, and per-session audit logs belong alongside the isolation boundary. A hardware-isolated microVM with a wildcard IAM credential attached is still a blast radius waiting for a reason to happen.

Cold starts, snapshots, and the latency cost of stronger isolation

The naive comparison, containers at a few milliseconds against microVMs at 125 to 200ms, overstates the gap most agent workloads will actually feel. Snapshot-restore is what closes it, and any team still budgeting for a cold Firecracker boot on every request is leaving performance on the table for no reason.

A cold Firecracker boot runs 125 to 200ms. Restore a pre-booted snapshot instead of booting from scratch, and that number drops dramatically. Snapshot-restore architectures that avoid warm pools and boot directly from a baked image illustrate the pattern well: the restore step itself accounts for only a fraction of the total create time, with tail latency driven largely by surrounding orchestration. Snapshot discipline is what actually controls the tail latency.

gVisor's latency story runs differently. Startup is fast, in the same millisecond range as a plain container, so cold start was never gVisor's weak point to begin with. The 10 to 30% I/O overhead is the real cost, and it compounds on anything doing heavy filesystem or network work. What matters for gVisor is steady-state throughput once the workload is running against real I/O patterns.

Billing adds a third axis that has nothing to do with cold start or throughput: idle time. Platforms that bill per second of sandbox wall-clock time charge for every second the sandbox exists, whether it's executing code or just sitting there waiting on a human to click a button. An agent that runs code for two seconds and then waits thirty seconds for approval pays for all thirty-two seconds. Over a long agent session, that idle cost can dwarf whatever got spent on cold starts in the first place.

These are three separate problems, and treating them as one is where most cost estimates go wrong. Cold-start latency governs responsiveness. Steady-state I/O overhead governs throughput on sustained workloads. Idle billing governs cost at scale, particularly for agents that spend real time waiting on humans or external systems. Fixing one doesn't touch the other two, and a platform that's fast to boot can still bleed you dry on idle minutes.

Platform-by-platform comparison: isolation model, cold start, session limits, BYOC, GPU, and pricing

Northflank lets teams pick Kata Containers, Firecracker, or gVisor per workload, which makes it one of the only platforms built around mixing isolation levels inside a single deployment instead of forcing one choice across the board. Cold start runs 97ms median time-to-interactive and 167ms under burst load, per ComputeSDK figures. Session duration is unlimited, and BYOC deployment spans AWS, GCP, Azure, Oracle, CoreWeave, Civo, and bare metal. GPU support covers L4, L40S, A100 40GB and 80GB, H100, H200, B200, and more (18 GPU types total), and the platform processes over 2 million isolated workloads a month. Pricing runs per second: $0.01667 per vCPU-hour, $0.00833 per GB-hour of memory, $0.15 per GB-month of storage, with GPU rates from $0.80/hr for an L4 up to $3.14/hr for an H200. The combination of BYOC and unlimited sessions makes Northflank the natural pick for regulated industries that can't send data to a third-party cloud, and its reach beyond sandboxing, into databases, CI/CD, and backend APIs, avoids the migration headache that comes with outgrowing a narrower tool.

Modal runs on gVisor with custom logic layered on top to block malicious syscalls, and it's one of a small number of platforms offering GPU access inside a gVisor-isolated sandbox. Cold start is sub-second, and alpha-stage memory snapshots can cut startup further for initialization-heavy workloads. Sessions are configurable up to 24 hours, and filesystem snapshots persist until explicitly deleted. There's no BYOC option here. GPU coverage is the widest of any sandboxing platform: T4, L4, A10, L40S, several A100 variants, RTX PRO 6000, H100, H200, and B200/B200+. Modal has run over a billion sandboxes total, supports 100,000-plus concurrent sandboxes, has been stress-tested to 1,000 sandbox creations per second, and serves over 10,000 teams. Pricing runs $0.1419 per physical core-hour on a 2-vCPU basis plus a per-unit memory rate, with GPU rates from $2.10/hr for an A100 40GB to $4.54/hr for an H200. Modal holds SOC 2 Type II certification, with HIPAA-compliant workloads available on Enterprise plans via a BAA. Quora runs Modal Sandboxes inside Poe to execute LLM-generated code, and Ramp runs a background coding agent through Modal that writes its own commits and pull requests. For teams that need GPU acceleration and code execution in the same place, Modal is the obvious fit. But gVisor's isolation profile is a software boundary, not a hardware one, and that tradeoff needs weighing against the actual threat model, not glossed over because the GPU lineup looks impressive on paper.

AWS Bedrock AgentCore launched October 13, 2025 across nine regions, and it isolates every session in its own dedicated Firecracker microVM. The platform is built from composable pieces: Runtime, Gateway, Identity, Memory, plus Code Interpreter and Browser as built-in tools rather than standalone services, with Observability layered across all of it. Billing splits active vCPU-hours, which exclude idle time while the agent waits on an LLM response, from GB-hours, which bill for the full session including idle time, a meaningfully different model from platforms that bill pure wall-clock time straight through. The constraint is straightforward and non-negotiable: AgentCore runs in AWS regions only, with no on-premises, air-gapped, or bring-your-own-Kubernetes option. For teams already committed to the AWS ecosystem who want strong sandbox-level isolation without building the control plane themselves, AgentCore is a reasonable default, as long as the AWS dependency gets treated as the real architectural commitment it actually is, not a detail to sort out later.