On this page
A Firecracker sandbox, gVisor and a shared-kernel container place the execution boundary in different places. A microVM runs a guest kernel; gVisor implements much of the Linux system-call interface in a user-space application kernel; an ordinary container isolates processes while sharing the host kernel. Choose from the code you will run, the authority it receives and the consequence of a failure.
The isolation primitive is only one part of that decision. Network access, credentials, resource limits and retained state need their own controls. For the broader definition, start with what an AI agent sandbox is.
Compare the isolation boundaries
| Primitive | Where the boundary sits | What to verify for an agent workload |
|---|---|---|
| Shared-kernel container | Namespaces isolate resources; the application still uses the host kernel | Runtime privileges, mounted paths, exposed host interfaces and kernel hardening |
| gVisor | Its Sentry application kernel handles the workload's Linux system interface | Supported system calls, filesystem and networking behavior, and application compatibility |
| Firecracker microVM | A virtual machine monitor runs a separate guest kernel using KVM | Guest images, virtual devices, host and VMM hardening, and operational controls |
Linux namespaces give processes separate views of system resources. They are useful isolation mechanisms, but do not give an ordinary container its own kernel. A privileged container or a mounted host socket can also expose authority that the process boundary was meant to limit.
The gVisor architecture guide describes an application kernel designed to reduce direct exposure to the host's system-call surface. This is a security architecture, not merely a label for semi-trusted code. Its interface can differ from the Linux behavior a workload expects, so compatibility must be tested.
The Firecracker design describes a virtual machine monitor with a deliberately limited device model. A guest kernel changes the trust boundary. It does not eliminate the need to secure the host, virtual machine monitor, images or surrounding services.
Do not rank these primitives with a single "secure" score. They have different trusted components, interfaces and operating constraints.
When a Firecracker sandbox is worth evaluating
Consider a microVM boundary when an agent executes unfamiliar code, installs arbitrary packages, runs shell commands or shares infrastructure with other tenants. Those capabilities expand the code and interfaces you must distrust.
The useful question is whether your design needs an independent guest kernel and the application compatibility it supports. The answer depends on the workload and the boundary around it, not on whether a model authored the script. A human-submitted dependency can be just as untrusted as generated code.
Before choosing, run the actual toolchain: its package manager, native extensions, subprocesses and filesystem operations. Confirm what can reach the host, what is mounted, and which credentials are visible. Test cleanup after a crash as well as successful execution. Our microVM isolation guide covers the agent-runtime context.
When to evaluate gVisor or a container
Evaluate gVisor when reducing the workload's direct interaction with the host kernel is important and its supported system interface fits your application. Test the software rather than assuming that every Linux program behaves identically. Application behavior, operational controls and the surrounding threat model matter more than an invented universal ordering between gVisor and microVMs.
A conventional container can fit reviewed first-party services with deliberately limited privileges. That still calls for restricted mounts, appropriate resource limits and careful handling of host interfaces. "We wrote the code" does not make every package or user-provided input trusted.
If neither option meets the required boundary, change the design. Isolation is not a reason to give a workload unrestricted access to a production credential or an administrative socket.
A decision checklist for AI agent isolation
Use these questions before choosing a runtime:
- What can execute? List generated scripts, downloaded dependencies, native binaries and tools. Distinguish reviewed application code from user-controlled inputs.
- Whose workloads share the environment? Identify tenant boundaries and which components must remain trusted.
- Which Linux behavior is required? Test the system calls, networking and filesystem behavior your application actually uses.
- What authority crosses the boundary? Inventory mounted files, tokens, database access and outbound destinations. A well-isolated process can still misuse permissions you gave it.
- How does execution end? Set resource and time limits, define cancellation, and verify what is retained or deleted after failure.
Run the same representative workload against each candidate. Include dependency installation, concurrent execution, a denied network destination and a process that exceeds its limit. A successful hello-world run does not exercise those boundaries.
Network policy is separate from isolation
A guest kernel does not decide which API an agent may call. Neither does a container boundary or an application kernel. An agent can leak data through a permitted connection without escaping its execution environment.
Define destinations from the tool's job. A documentation reader might need one documentation host; a build may need specific package registries. Keep credentials scoped to the intended operation, and verify the deny path from inside the workload. For the application design, see networked isolation.
The enforcement location matters. A rule that the agent can edit inside its own process is different from a policy enforced outside the workload. Document what remains enforced after code inside the environment is compromised, and test against that requirement.
Where CreateOS Sandbox fits
CreateOS: The unified execution layer for AI. CreateOS Sandbox provides Firecracker micro-VM execution with a guest kernel per sandbox. Its lifecycle supports pause, resume and fork; those operations help when an agent waits for a person, retries a step or explores another approach.
Its egress documentation states the default precisely: no egress rules means outbound access is open. A non-empty rule list makes outbound access deny-by-default, allowing the listed destinations. That policy is enforced outside the guest. Set the intended allowlist before running untrusted input. Inbound access is closed by default and is controlled separately.
Do not confuse a private sandbox network with an outbound allowlist. Private connectivity determines how related workloads talk to one another; egress policy determines which external destinations they may reach. Check both for your deployment.
Isolation also does not settle retained state. Decide which process memory and files may survive a pause or fork, who can resume them, and when to destroy the environment. A snapshot containing a credential deserves the same access controls as the running process that held it.
Common questions
What is the difference between a microVM and a container?
A microVM has a guest kernel behind a virtual machine monitor. An ordinary container shares the host kernel while isolating process resources. Both need restrictions on credentials, mounts, networking and host access. Choose the boundary against your workload's authority and threat model.
Is gVisor suitable for untrusted code?
gVisor is designed as a sandboxing boundary that reduces direct exposure to the host kernel through an application kernel. Suitability depends on the application, compatibility and security requirements. Test the real workload and its controls rather than dismissing it as a runtime only for semi-trusted code.
Does a Firecracker sandbox prevent data exfiltration?
A microVM does not automatically restrict outbound destinations or the credentials visible to its applications. Pair the execution boundary with an enforced network policy, limited credentials and appropriate data access. Verify permitted and denied operations from the running workload.
Is CreateOS Sandbox outbound access denied by default?
No. An empty egress rule list permits outbound access. A non-empty list restricts outbound access to the allowed destinations, with enforcement outside the guest. Configure the allowlist before the sandbox processes untrusted input, and check inbound access separately.
Next step
Write down the code, data and network access your agent needs. Compare candidate runtimes against that list, then test the boundary and the failure paths. Explore CreateOS Sandbox when a separate guest kernel and session lifecycle fit the job.
