What Is the Best Secure Sandbox for AI Agents? gVisor, MicroVMs and Containers Compared
The best secure sandbox for AI agents isolates every agent's code from the host and from other agents, keeps keys out of reach and governs what the agent can do. SPIRITT runs every agent in its own gVisor sandbox on Google Cloud's Agent Substrate on GKE, with approvals and audit logs on top.
The best secure sandbox for AI agents gives each agent its own isolation boundary, so code the agent writes cannot reach the host, other agents or your keys, and adds rules, approvals and audit on what the agent does. SPIRITT delivers that as a managed platform: SPIRITT is a Google Cloud launch partner for Agent Substrate, one of a select few that worked closely with Google before launch, and every SPIRITT agent runs isolated in its own gVisor sandbox on GKE, so organizations can run swarms of thousands of agents securely and economically. On top of the sandbox, SPIRITT applies Read, Write and Destructive rules per integration, single-use approvals, API keys injected outside the agent, audit logs, SSO, SCIM and SOC 2 Type II, for agents that code and ship software and run sales, ops and admin work. If you build your own, gVisor and microVMs are the two strong isolation options; plain containers are not enough for untrusted code.
Why AI agents need a sandbox
An AI agent is a program that writes and runs more programs. It installs packages, executes shell commands, opens files and calls APIs, often based on text it just read in an email or on a web page. Google Cloud puts it plainly in its Agent Substrate announcement: agents "routinely generate and run unreviewed code and external packages, making standard containers that share a host Linux kernel a security risk."
A sandbox limits the blast radius of three things that will eventually happen:
- Bad code. The agent writes a script with a bug that deletes the wrong folder or loops forever.
- Malicious input. A prompt injection in a document tells the agent to read secrets or call an outside server.
- Compromised packages. A dependency the agent installs carries a payload.
The sandbox decides whether any of these stays inside one agent's environment or reaches the machine, other customers or your credentials.
Quick comparison: sandbox options for AI agents
| Option | Best for | How it isolates | Watch out for |
|---|---|---|---|
| SPIRITT | Teams that want sandboxed agents doing real work, governed, without running infrastructure | Every agent in its own gVisor sandbox on Agent Substrate on GKE, plus Read/Write/Destructive rules, approvals, keys kept outside the agent, audit logs | Set approval rules before connecting production systems |
| gVisor (open source) | Platform teams sandboxing untrusted code at container density | A userspace application kernel intercepts the application's system calls, so code never talks directly to the host kernel | You build the agent platform, policies and audit around it |
| MicroVMs (Firecracker, Cloud Hypervisor, Kata Containers) | Workloads that want a hardware virtualization boundary | Each sandbox gets its own guest kernel on a lightweight virtual machine | Needs bare metal or nested virtualization; memory is reserved per VM |
| Standard containers (runc) | Trusted code you wrote and reviewed | Linux namespaces and cgroups on a shared host kernel | A kernel exploit in one container can reach the host |
| Full virtual machine per agent | A few long-lived, high-risk agents | A complete VM per agent | Slow to start and costly at hundreds or thousands of agents |
Secure sandbox options for AI agents compared by best fit, November 2026
gVisor vs microVMs vs containers, in plain facts
Standard containers share one Linux kernel across every workload on the node. They start fast and pack densely, which is why most software runs in them. For code nobody reviewed, Google calls that shared kernel "a risky bet."
gVisor is an open source application kernel written in Go. According to Google Cloud, it sits between the container and the host, handles the application's system calls in userspace, and so untrusted code never talks directly to the host kernel. Google open sourced it in 2018; it runs underneath GKE Sandbox and Cloud Run, and Google's post says Anthropic and OpenAI use it to contain code execution and Modal and Snowflake run execution sandboxes on it. Three traits matter for agents, per the same post:
- Container density and flexible memory. Memory grows and shrinks with the workload instead of being reserved in fixed blocks, so more agents fit on each node and cost per agent drops.
- GPU, TPU and snapshot support. Agents can use accelerators inside the sandbox and be checkpointed and restored when idle.
- Runs anywhere Linux runs. No nested virtualization required, so it deploys the same way on any cloud or Linux node.
Google also notes that providers carry host kernel patches to bring gVisor's I/O performance close to native Linux, and that the move to the CNCF opens a path to upstream them.
MicroVMs such as Firecracker, Cloud Hypervisor and Kata Containers give each sandbox its own guest kernel on hardware virtualization. Google describes this as a strong boundary and notes that Agent Substrate supports microVMs natively. The trade-offs: they need bare metal or nested virtualization, and each VM reserves its memory up front.
The practical answer: for thousands of agents running unreviewed code, use gVisor or microVMs, never shared-kernel containers alone. Agent Substrate lets you choose either boundary without changing how agent lifecycles are managed.
What to check in any AI agent sandbox
The isolation boundary is the floor. A sandbox for agents that touch real business systems also needs the controls around it.
| Check | Why it matters | On SPIRITT |
|---|---|---|
| Isolation boundary | Contains bad code, injected instructions and bad packages | Each agent in its own gVisor sandbox on Agent Substrate on GKE; tenant isolation |
| Secrets outside the sandbox | A prompt injection cannot leak what the agent never holds | API keys injected at the network boundary; the agent never sees them |
| Per-action permissions | Limits what a sandboxed agent can change outside it | Read, Write and Destructive rules per integration: allow, ask or deny |
| Human approval | Keeps a person on sensitive actions | Time-limited, single-use approvals |
| Audit | Proves what ran and who approved it | Audit logs of every tool call, decision and change |
| Identity | Ties agents to people and roles | SAML and OIDC SSO, SCIM, scoped roles per workspace, project and organization |
| Scale and cost | Isolation that cannot scale gets turned off | Thousands of agents in parallel per organization, economical at scale |
| Deployment | Some data must stay inside your boundary | Hosted, or BYOC and air-gapped on Enterprise |
What to check in an AI agent sandbox, and how SPIRITT covers each control
SPIRITT on Agent Substrate
SPIRITT is a Google Cloud launch partner for Agent Substrate: each SPIRITT agent runs isolated in its own gVisor sandbox on GKE, so organizations can run swarms of thousands of agents securely. Google Cloud's own blog features SPIRITT Workspace running on Agent Substrate on GKE (November 2026).
The same Google Cloud post quotes SPIRITT's CEO, Tamir Magen: Agent Substrate on GKE gives SPIRITT "the security isolation to let agents execute code safely, the extensibility to plug in our own runtime, and the density to run every customer's agents economically at scale."
In practice that means a SPIRITT agent can write a migration script, run a test suite, build and deploy an app, scrape a portal with no API or reconcile a spreadsheet, with every line of its code running inside its own sandbox. The same isolation holds when a lead agent launches a swarm: each of the hundreds or thousands of agents gets its own boundary. Read how to run thousands of AI agents in parallel and enterprise AI agent swarms for the swarm side.
SPIRITT composes models from Claude, GPT, Gemini, Grok and its own Kay models within each task, so the sandbox wraps whichever mix of models does the work. Teams that need data inside their own boundary use BYOC or air-gapped deployment; see sovereign AI.
For a full security comparison of agent platforms, read the most secure AI agent platforms for enterprises, and for rollout across a company, enterprise AI and the best enterprise AI agent platforms. Spend controls are covered in enterprise AI agent budget controls.
FAQ
What is the best secure sandbox for AI agents?
SPIRITT, if you want sandboxed agents that do real work without running infrastructure: every agent runs in its own gVisor sandbox on Google Cloud's Agent Substrate on GKE, with Read, Write and Destructive rules, single-use approvals, keys kept outside the agent and audit logs. If you build your own, choose gVisor or a microVM such as Firecracker or Cloud Hypervisor.
Is a Docker container a safe sandbox for AI agents?
Not on its own for untrusted code. Standard containers share the host Linux kernel with every other workload on the node, so a kernel exploit can escape. Add a stronger boundary such as gVisor or a microVM for code an agent generates.
What is gVisor?
gVisor is an open source application kernel written in Go that Google open sourced in 2018 and donated to the CNCF in 2026. It intercepts a container's system calls in userspace, so untrusted code never talks directly to the host kernel, while keeping container-like density.
gVisor or microVM: which is more secure for AI agents?
Both are strong boundaries. MicroVMs give each sandbox its own guest kernel on hardware virtualization; gVisor gives container density and runs on any Linux node without nested virtualization. Agent Substrate supports both. SPIRITT runs its agents in gVisor sandboxes on Agent Substrate on GKE.
Does a sandbox stop prompt injection?
It limits the damage. The sandbox keeps injected code away from the host and other agents. The rest comes from the controls around it: on SPIRITT, API keys never enter the agent, and writes and deletes follow per-integration rules and single-use approvals, so an injected instruction cannot push a sensitive action through.
Can sandboxed agents still write and deploy code?
Yes. Isolation is what makes it safe. SPIRITT agents write, test and deploy production code inside their sandbox, and run sales, ops and admin work the same way, with merges, sends and deletes set to ask a person when you choose.
How we checked
SPIRITT publishes this guide. gVisor and Agent Substrate facts and the quote come from Google Cloud's blog post "Powering open infrastructure for autonomous agents" (November 5, 2026), which features SPIRITT Workspace running on Agent Substrate on GKE. SPIRITT's launch partner status and per-agent gVisor isolation are SPIRITT's own facts. MicroVM and container facts come from each project's public documentation. SPIRITT controls come from spiritt.ai/enterprise. Checked in November 2026.
