On this page
Pick the isolation primitive from the threat model
Agents run model-written code. Choose the isolation primitive from the threat model, not from a brand name on a pricing page.
That is the whole decision. Containers, gVisor-style user-space kernels, and Firecracker microVMs are not interchangeable labels for "sandbox." Each stops a different class of failure. If you cannot name which primitive you are buying, you do not know the blast radius when the agent installs a package, opens a shell, or follows a prompt injection into an egress call.
This page is a one-screen decision tree: threat model → primitive → when CreateOS Sandbox fits. For the product definition of what an AI agent sandbox is, start there; this post is about choosing the boundary underneath that word.
Three isolation primitives
A shared-kernel container, a gVisor-style user-space kernel, and a Firecracker microVM put the trust boundary in three different places. The table is the map. Everything after it is how to walk the map without marketing noise.
Figure 2. Same word "sandbox," three different trust boundaries.
| Primitive | Boundary | What it typically stops | What it does not stop | Best fit |
|---|---|---|---|---|
| Shared-kernel container (namespaces / cgroups) | Software isolation on one host kernel | Process crosstalk under a cooperative tenant model | Kernel bugs reachable from inside the container; hostile code that can climb to the host | Trusted first-party service code you wrote and reviewed |
| gVisor-style user-space kernel | Syscalls intercepted and handled outside the real host kernel (gVisor docs) | Many kernel-facing attacks that plain containers expose | Workloads that need a full Linux syscall surface; anything that must assume the code is actively hostile and networked | Semi-trusted, syscall-bounded workloads |
| Firecracker microVM | Own guest kernel behind KVM (Firecracker project, GitHub) | Shared-kernel escape class that containers inherit by design | Misconfigured egress (isolation ≠ network policy); lifecycle gaps if you treat the VM as throwaway | Untrusted or model-written code, especially with shell, packages, and network |
Firecracker is the micro-VM monitor AWS open-sourced for serverless isolation (AWS announcement). The project documents sub-second boot and a small per-VM memory footprint. Those numbers matter for density. They are not the reason to pick it for agents. The reason is the guest kernel: the untrusted code no longer shares the host's attack surface the way a container does.
gVisor is the honest middle. It is stronger than namespaces alone and weaker than a VM. Teams reach for it when they want a tighter syscall story without paying full virtualization. That can be correct for bounded tools. It is the wrong default when the agent can write arbitrary code, install packages, and reach the network.
For a deeper cut on why agent threat models break shared kernels, see microVM isolation for AI agents.
Decision tree: threat model → primitive
Walk the agent's actual capabilities. Stop at the weakest primitive that still contains them.
Figure 1. Walk the threat model. Stop at the weakest primitive that still contains it.
1. Trusted service code you wrote
If humans review the code, the deploy path is first-party, and the process cannot install arbitrary packages or open a shell on demand, a shared-kernel container is usually enough. Namespaces and cgroups were built for this case. Do not buy a microVM to feel safer about your own microservice.
2. Multi-tenant untrusted tools
If tenants submit tools, plugins, or scripts that run on shared infrastructure, namespaces alone are the wrong default. You need a stronger boundary than "we cgroup'd it." gVisor can be a step up when the syscall surface is narrow and well understood. If tenants can bring arbitrary runtimes, climb to a microVM.
3. Hostile or model-written code with network
If a model writes the script, nobody reviewed it before execution, and the session can talk to the network, pick a Firecracker-class microVM and an egress allowlist. Isolation without egress policy just moves the incident from "escaped the box" to "exfiltrated through an allowed socket."
Figure 3. Guest-kernel isolation still needs egress enforced outside the guest.
A compact checklist before you commit:
| Capability present? | Climb at least to… |
|---|---|
| Shell / package install / arbitrary code exec | Stronger than plain container |
| Multi-tenant untrusted submitters | gVisor minimum; microVM if syscall surface is open |
| Model-written code (no human review) | MicroVM |
| Network egress to anything beyond a fixed allowlist | MicroVM + kernel-enforced egress policy |
| Secrets or regulated data in reach of the session | MicroVM + allowlist + destroy-on-end (or pause with controlled resume) |
Prompt rules are not a data-plane control. If the policy lives only in the agent framework, a successful injection can rewrite the policy. If the policy lives outside the guest, the agent cannot talk past it.
What "sandbox" marketing hides
The same word covers different boundaries. Vendor pages and category roundups often say "sandbox" when they mean a container with a prettier API, a filtered syscall layer, or a real microVM. Buyers compare products. Security reviews need the primitive.
Three questions cut through the label:
- Does the workload get its own guest kernel? Yes means microVM-class. No means you are still on a shared or intercepted host kernel story.
- Where is egress enforced? Inside the guest (bypassable if the guest is compromised or persuaded) versus outside the guest (kernel / host policy).
- What happens to state? Destroy-only throwaway, or pause / fork / resume as first-class operations.
Category roundups that stop at "use Firecracker" answer question 1 and skip 2 and 3. Platform comparison posts often score DX and price without naming the boundary. For how CreateOS treats networked isolation and how the broader AI agent sandbox platforms landscape frames the problem, those posts stay educational rather than scorecard-driven on purpose.
CreateOS is the unified execution layer for AI. On the Sandbox surface that means a governed place to run untrusted and model-written code, not a rename of container hosting.
State after isolation
Isolation without lifecycle is throwaway compute. Real agents are not one-shot scripts. They wait on humans, branch approaches, and retry failed steps. If every pause means losing the filesystem and every retry means replaying forty minutes of setup, teams either overspend on always-on boxes or under-isolate to keep state.
Three operations matter after the boundary is right:
- Pause / resume. Park memory and disk when the agent is waiting. Resume without rebuilding context. Holding a warm VM while a human reviews a diff is a cost bug, not a security feature.
- Fork. Copy a running session (memory, filesystem, process tree) into a sibling that starts from the same point. Useful for competing approaches, retries, and snapshot-before-risk. Mechanics: forking agent state.
- Destroy. End the session and drop the blast radius. Default for one-shot tool calls.
We cover the "after isolation" half in what happens after Firecracker isolation. The short version: pick the primitive first, then demand lifecycle primitives that match how agents actually run.
When CreateOS Sandbox fits
CreateOS Sandbox is a Firecracker micro-VM runtime for untrusted and AI-generated code. Each sandbox gets its own guest kernel. Isolation is the machine, not a shared-kernel container.
What ships together by default (mechanism claims only; no fabricated customer counts):
- Hardware virtualization boundary via Firecracker (own guest kernel)
- Allowlist-only egress, enforced outside the guest
- Private overlay networking between sandboxes
- Pause, resume, and fork
- Self-hostable control plane and storage (S3-compatible backends)
Fit signals:
- Your agents write and run code nobody reviewed
- You need egress you can defend in a security questionnaire
- You care about session lifecycle, not only cold start
- You want the option to self-host the control plane
Non-fit signals:
- Pure first-party services with reviewed deploys (containers are fine)
- Single short tool calls with no network and no persistence (do not overbuy)
Try it at createos.sh/app/sandbox. Usage pricing is published separately; this post is about the isolation decision, not a rate card.
FAQ
MicroVM vs container for AI agents: which should I use?
Use a container when the code is trusted and reviewed. Use a microVM when the code is model-written, multi-tenant-untrusted, or otherwise hostile-by-default. The difference is whether the workload shares the host kernel. Agents that can open a shell and install packages should not share that kernel with other tenants.
Is gVisor enough for model-written code?
Sometimes, for narrow syscall surfaces and semi-trusted tools. Not as a default for open-ended coding agents with package install, subprocesses, and network. gVisor strengthens the container story; it does not give you a guest kernel. If your threat model assumes the code will try to leave, prefer Firecracker-class isolation and treat gVisor as a middle rung you choose on purpose.
Does a Firecracker sandbox replace egress policy?
No. A guest kernel contains escape classes that containers inherit. It does not decide which outbound hosts the agent may contact. Pair microVM isolation with an allowlist enforced outside the guest. Isolation without egress policy is an incomplete answer for networked agents.
When does self-hosting the sandbox control plane matter?
When data residency, private networking, or change-control requirements say the control plane and storage cannot live only in a third-party SaaS boundary. CreateOS Sandbox is designed to be self-hostable for those cases. If you are prototyping with non-sensitive workloads, managed is usually enough to validate the primitive.
What should I ask a vendor that says "sandbox"?
Ask three things: own guest kernel or shared host kernel; where egress is enforced; whether pause, fork, and resume exist as first-class operations. If the answers are vague, you are buying a label, not a boundary.
Closing
Name the primitive. Match it to the threat model. Add egress and lifecycle after the boundary is right. That sequence beats any vendor roundup that treats "sandbox" as a single product category.
CreateOS Sandbox exists for the case where the unit of isolation has to be a real machine: Firecracker guest kernel, allowlist egress, overlay networking, pause/fork/resume, self-host when you need it. Start at createos.sh/app/sandbox.
