On this page
- What is a Firecracker Sandbox for AI Agents?
- Why Isolation Alone is Not Enough
- How Do You Pause and Resume an Agent Sandbox?
- How Do You Fork an Agent Sandbox?
- How Do You Control What a Sandboxed Agent Can Reach?
- Is Firecracker Isolation the Same as Hardware Isolation?
- How Does Firecracker Compare to Containers and gVisor?
- Common Questions
- About CreateOS
- Next Step
What is a Firecracker sandbox for AI agents?
A Firecracker sandbox is a micro-VM that runs an agent's code with its own guest kernel, so anything the agent does stays inside that VM. Firecracker is the micro-VM technology AWS built for Lambda, and it boots in roughly 100–150ms — fast enough to start one per task.
That is where almost every guide on this topic stops. Isolation is the easy half.
The hard half is everything after: an agent that runs for an hour, needs to branch, gets paused mid-task, and has to call out to a real API without being able to call out to everything else. This post covers that half.
Why isolation alone is not enough
A sandbox that only isolates treats the agent as a script. Real agents are long-running processes with state. Three problems appear the moment you move past a single code-execution call.
- State does not survive. An ephemeral sandbox throws away the filesystem when the task ends. An agent that spent forty minutes building context loses it.
- You cannot branch. Trying two approaches from the same starting point means re-running everything up to that point.
- Isolation says nothing about egress. A perfectly isolated VM can still make an outbound request to any host on the internet. Isolation protects your infrastructure from the agent. It does not protect your data from exfiltration.
That third point is the one security teams ask about first, and it is the one the isolation-focused guides answer least.
How do you pause and resume an agent sandbox?
Pausing writes the micro-VM's memory and disk state to storage, so the agent can be resumed later on a different host with its context intact. The agent does not know it stopped.
This matters for cost and for review. A long-running agent that is waiting on a human approval does not need to hold compute. Pause it, resume it when the approval lands.
On CreateOS, sandboxes support pause and resume as a first-class operation, with disks backed by S3-compatible storage. The practical effect is that an agent's working state becomes a durable artifact rather than something you lose at the end of a request.
How do you fork an agent sandbox?
Forking copies a running sandbox's full state — memory, filesystem, process tree — into a second sandbox that starts from that exact point. Both then run independently.
This is the operation that makes agent evaluation cheap. Rather than running a task from scratch for each variant, you run once to the decision point, fork, and let each branch proceed.
Three common uses:
- Try competing approaches from an identical starting state, then keep the better result.
- Retry a failed step without repeating the forty minutes before it.
- Snapshot before a risky action so a bad write can be abandoned rather than undone.
We cover the mechanics in more depth in forking agent state.
How do you control what a sandboxed agent can reach?
Egress allowlisting decides which outbound hosts the agent may contact, enforced in the kernel rather than in the agent's own code. CreateOS uses eBPF for this.
The distinction matters. If the rule lives in your agent framework, a prompt injection that changes the agent's behaviour can change the rule. If it lives in the kernel, the agent cannot reach past it regardless of what it was persuaded to do.
A workable default for a regulated environment:
| Destination | Policy |
|---|---|
| Your own APIs | allow, explicitly listed |
| Model providers in use | allow, explicitly listed |
| Package registries | allow during build, deny at run time |
| Everything else | deny |
Pair that with a VPC so the sandbox sits inside your network boundary, and the agent's reach is defined by infrastructure rather than by instructions. More on that in networked isolation.
Is Firecracker isolation the same as hardware isolation?
No, and the difference matters in a security review. Firecracker is a KVM-based virtual machine monitor. Each sandbox is VM-isolated with its own guest kernel, which is a substantially stronger boundary than a container sharing the host kernel.
It is not, however, hardware-enforced isolation in the sense a security team means when they say that phrase — that implies TEE-class guarantees such as SGX or SEV. Firecracker does not claim those, and neither do we.
Use the accurate description. "VM-isolated with its own guest kernel" survives a security questionnaire. "Hardware-isolated" does not, and getting caught on it costs more credibility than the stronger-sounding claim ever earned.
How does Firecracker compare to containers and gVisor?
Containers share the host kernel, gVisor intercepts syscalls in userspace, and Firecracker gives each workload its own kernel inside a micro-VM. The trade is startup time against boundary strength.
| Boundary | Typical cold start | Best fit | |
|---|---|---|---|
| Container | Shared host kernel | ~10–50ms | Trusted code you wrote |
| gVisor | Userspace syscall filter | ~50–150ms | Semi-trusted, syscall-light workloads |
| Firecracker micro-VM | Own guest kernel | ~100–150ms | Untrusted or model-generated code |
For agent workloads that execute code a model wrote, the micro-VM boundary is the one that matches the threat. The extra ~100ms is not the constraint people expect it to be, because agent tasks are measured in seconds to minutes.
Independent numbers are available: CreateOS placed #2 of 22 providers on the staggered-launch test in the ComputeSDK sandbox benchmarks, and 4th of 22 on mean composite. Both figures are in the public dataset — check them rather than taking ours.
Common questions
What is a Firecracker sandbox?
A Firecracker sandbox is a micro-VM that runs code with its own guest kernel and its own network namespace. It boots in roughly 100–150ms, which is fast enough to create one per agent task instead of sharing a long-lived environment.
Is Firecracker better than Docker for running AI agents?
For code an AI model generated, yes — because the boundary is different in kind, not degree. A container shares the host kernel, so a kernel-level escape affects the host. A Firecracker micro-VM runs its own kernel, so the same class of escape is contained. Docker remains the better choice for code you wrote and trust.
Can you pause and resume a Firecracker sandbox?
Yes. Pausing writes the micro-VM's memory and disk to storage, and resuming restores it — potentially on a different host. The agent continues with its context intact, which lets you stop paying for compute while a task waits on human approval.
How do you stop a sandboxed AI agent from calling external services?
Enforce an egress allowlist in the kernel rather than in the agent's code. CreateOS uses eBPF, so the rule holds even if a prompt injection changes what the agent tries to do. Allow your own APIs and the model providers you use, deny everything else by default.
Does a Firecracker sandbox give hardware-level isolation?
No. Firecracker is KVM-based, so each sandbox is VM-isolated with its own guest kernel. That is stronger than container isolation but is not TEE-class hardware enforcement such as SGX or SEV. Describing it accurately matters when a security team reviews the claim.
How do you run agent sandboxes inside your own infrastructure?
Run the control plane and storage inside your own boundary. CreateOS supports a self-hosted control plane for exactly this, which is usually what regulated buyers need before agent workloads can touch internal data. CreateOS is SOC 2 Type II and ISO 27001 certified, with reports available under NDA.
About CreateOS
CreateOS is the unified AI execution layer for the enterprise — route, govern, validate, observe. It runs agent workloads in Firecracker/KVM micro-VM sandboxes with fork, pause-resume, VPC and S3-backed disks, with kernel-level egress control via eBPF, and can run entirely inside a customer's own boundary. Built by the team at NodeOps.
Next step
If you are choosing a sandbox for agent workloads, start with what an AI agent sandbox is for the fundamentals, then check pricing for what running one per task actually costs.
