On this page
When Coding Agents Need Firecracker (Not a Shared Kernel)
Answer first: if the agent writes and runs code you did not review, a shared kernel is the wrong default. The unit of isolation has to be a real machine: its own guest kernel, not a namespace on the host.
This is not a product preference. It is a threat-model match. Coding agents install packages, open shells, touch the network, and execute scripts that nobody approved line by line. Containers were built for trusted deploy units. That is a different job.
For the primitive-by-primitive decision tree (container vs gVisor vs Firecracker), see Isolation Primitives for AI Agents.
What changed in the category
Production coding-agent platforms are now explicit about isolated execution environments, not just “run the command.”
On September 3, 2026, Vercel documented that Cursor Cloud Agents can run in Vercel Sandbox: Cursor keeps the agent harness and inference loop; Vercel Sandbox supplies “an isolated Firecracker microVM for each agent request,” with short-lived credentials inside each sandbox and automatic cleanup. That is a public category signal, not a CreateOS claim about Cursor or Vercel performance.
The pattern matters more than any single vendor: agent control plane outside, untrusted execution inside a Firecracker microVM. Adjacency across the industry (managed sandboxes built on Firecracker, IDE/cloud agents that assume per-run isolation) points the same direction. Treat changelogs as evidence of demand, not as benchmarks.
If you need the vocabulary for “what is an agent sandbox,” start with What is an AI agent sandbox?.
Threat model checklist (coding agents)
Ask these before you pick a primitive:
- Model-written scripts. The code did not go through your normal review gate.
- Package install. The agent can pull dependencies; supply chain is in play.
- Shell. Arbitrary process spawn, not a single pure function.
- Network. Egress can exfiltrate secrets or reach internal services.
- Secrets. Host env, cloud keys, and sibling tenants must stay outside the blast radius.
If three or more of those are true, you are past “dev convenience container” territory. You need a boundary that survives a hostile or merely buggy guest.
Why shared-kernel containers fail that checklist
Containers share the host kernel. Namespaces and cgroups limit what a process should see. They do not give the guest its own kernel. A kernel exploit inside the workload is a host-class event.
That model is fine for many trusted services. It is a weak fit when the workload is “run whatever the model just wrote.” For a deeper cut on microVM isolation, see MicroVM isolation for AI agents. For what changes after you choose Firecracker specifically, see Firecracker sandbox for AI agents.
gVisor-style user-space kernels sit in the middle: stronger than a plain container for many syscall-bounded workloads, still not a full guest kernel for actively hostile, networked, shell-heavy agent runs. Pick them when the threat model says so. Do not pick them because the word “sandbox” appeared in a diagram.
Production requirements beyond boot
Boot time is table stakes. Coding agents also need:
- Egress allowlist. Isolation without network policy just moves the incident. Own guest kernel plus allowlist-only egress is the pair that matches untrusted tool use. Prompt rules are not a data-plane control. See networked isolation.
- Session lifecycle. Pause, resume, and fork matter when the agent iterates on the same world instead of cold-starting every step. See fork / agent state.
- Self-host when policy demands it. Some teams cannot send untrusted execution to a third-party pool. The primitive should travel with the deployment model.
Do not rank vendors on brochure cold start alone. Prefer published startup and success-rate measurements when you compare platforms. If the numbers are not published, say so.
Where CreateOS Sandbox fits
CreateOS Sandbox is built for untrusted and model-written code: Firecracker microVMs (own guest kernel), allowlist-only egress, overlay between environments, pause / resume / fork, self-hostable. Sandbox is the product URL. The public hook stays the governed runtime / execution layer.
This post is about when coding agents need that class of isolation. It is not a rate card. Pricing lives at createos.sh/app/sandbox and pricing.
If you are still choosing among primitives, use the decision tree post first, then come back here for the coding-agent threat model.
FAQ
Do coding agents always need Firecracker?
No. Short, reviewed, network-denied helpers may be fine in a tighter box. Firecracker (or another microVM) becomes the default when the agent can write, install, shell, and talk to the network without a human review gate.
Is this only about cloud agents?
No. The same checklist applies to local coding agents that execute on a developer laptop with live credentials. The blast radius is personal, not multi-tenant, but the failure mode is still “untrusted code on a shared kernel with secrets.”
How is this different from “just use Docker”?
Docker (and containers generally) optimize for packaging and density on a shared kernel. Firecracker optimizes for a dedicated guest kernel per workload. Coding agents that execute untrusted scripts map to the second job.
Should I put the whole agent inside the microVM?
Usually no. Keep the agent harness and secrets outside. Send only the untrusted execution into the sandbox. Putting the commander in the chamber is how environment variables leak under prompt injection.
