Sandbox AI agents behind a hardware boundary.
An autonomous agent executing tool calls is code you don't fully trust. A container puts it one kernel bug away from your host. a2a cloud runs every agent inside a libkrun microVM instead — its own kernel behind a hardware virtualization boundary, a scoped filesystem, and an ephemeral lifetime. Isolation an untrusted run can't simply walk out of.
microVM · own kernel · scoped FS · ephemeral
A container is not a boundary for untrusted code.
Most 'sandboxed agent' setups are containers: namespaces, cgroups, and seccomp over one shared host kernel. That's fine for code you wrote and trust. An agent running model-chosen tool calls, reachable by prompt injection, is not that code — and against it a container is one kernel vulnerability away from the host. Broad mounts widen the blast radius, and long-lived sandboxes accumulate state and standing access for the next injection to inherit.
Every run executes in its own microVM.
libkrun gives each run a real virtual machine with its own kernel behind a hardware boundary. The filesystem the run sees is scoped by grant, the VM is ephemeral, and the boundary that was in force is recorded in the run's signed receipt.
microVM, not container
Each run executes inside a libkrun microVM with its own kernel behind a hardware virtualization boundary. It is not a namespace-and-cgroup slice of a shared host kernel — the isolation is at the CPU, not the syscall filter.
A hardware boundary
A container escape is a kernel bug away from the host. A microVM escape means breaking the virtualization boundary itself — the same class of boundary cloud providers use to separate tenants. That's the boundary an untrusted agent runs behind.
Scoped filesystem
The guest sees only the files the run is granted, not the host's disk. Filesystem scope is part of the grant — audience, TTL, and the exact paths the run may touch — so a compromised agent can't wander the box.
Ephemeral by default
The microVM is torn down after the run. There is no long-lived, ever-mutating sandbox accumulating state and access for the next prompt injection to inherit — each run starts from a known boundary.
Isolation that produces evidence
The run's boundary and what it was allowed to do are recorded in the receipt: the scoped grant, the tool calls, the outputs. Sandboxing isn't just containment — it's containment you can later prove was in force.
Any framework, same boundary
LangGraph, OpenAI Agents SDK, CrewAI, or custom Python/TS — the framework runs inside the microVM unchanged. You don't rewrite the agent to get the boundary; you deploy it and the boundary is there.
Shared-kernel container vs. libkrun microVM.
Frequently asked.
How does a2a cloud sandbox AI agents?
Each agent run executes inside a libkrun microVM — a lightweight virtual machine with its own kernel behind a hardware virtualization boundary. It is not a container sharing the host kernel through namespaces and cgroups. That means an untrusted agent runs behind the same class of boundary cloud providers use to separate different customers' workloads.
What's the difference between a microVM and a container for agents?
A container is isolation in software: namespaces, cgroups, and seccomp over one shared host kernel, so a kernel vulnerability can become a host compromise. A microVM gives the guest its own kernel behind a hardware virtualization boundary, so escaping means breaking the VM itself — a much stronger boundary for code you don't fully trust, which is exactly what an autonomous agent executing tool calls is.
Can a compromised agent access the host filesystem?
No. The guest only sees the files the run's scoped grant permits — specific paths, bounded by audience and TTL — not the host disk. Combined with the microVM boundary, a compromised or prompt-injected run is contained to what it was explicitly granted, and it can't wander the host.
Is the sandbox persistent or per-run?
The microVM is ephemeral by default and torn down after the run. There is no long-lived sandbox accumulating state and standing access for the next injection to inherit; each run starts from a known boundary. Persistent state lives in the agent's managed Postgres, reached through scoped grants, not in the sandbox itself.
Do I have to change my agent code to get microVM isolation?
No. LangGraph, OpenAI Agents SDK, CrewAI, or custom Python/TypeScript agents run inside the microVM unchanged — you deploy the agent and the boundary is there. The isolation, the scoped filesystem, and the receipt that records them are platform primitives, not something you wire into the agent.
Related guides.
All guides live in the guides index.
Give the agent a boundary, not a shell on your host.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — and runs each invocation inside a libkrun microVM with a scoped filesystem and an ephemeral lifetime. Managed Postgres, an MCP server, an API, a frontend, scoped grants, and an Ed25519-signed receipt per run. The boundary is a primitive, not a config flag.