boundary
container
Generated code executes inside the long-lived hosted agent process.
a2a explicit sandbox
Selected code executes in a separate libkrun microVM with its own guest kernel.
separate microVM code execution
Sandbox AI agents behind a hardware boundary.
Hosted agent skills run as Knative or Kubernetes container services. When a skill needs to execute model-generated or otherwise untrusted code, it can send that specific work through `ctx.sandbox` into a separate microsandbox/libkrun VM with a guest kernel and grant-scoped workspace. The microVM boundary is explicit and attached — not a claim about every request.
container-hosted skill · explicit sandbox · guest kernel · scoped workspace
0
VM per one-shot command
authorized workspace mount
0
automatic VM per request
the problem
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.
Containers share the host kernel — a kernel bug becomes a host compromise.
Prompt injection turns an agent into an attacker inside your isolation model.
Broad filesystem mounts let a compromised run read far beyond its task.
Long-lived sandboxes carry state and access forward between untrusted runs.
the a2a way
Put selected code execution behind a separate microVM boundary.
The hosted agent remains a container service. An explicit `ctx.sandbox` call sends a command or named session to microsandbox/libkrun, mounts the authorized workspace at `/workspace`, and returns structured execution results. One-shot commands stop afterward; named sessions can persist until deleted.
microVM for explicit sandbox commandsSeparate from the hosted serviceScoped filesystemLifecycle matched to the jobNetwork control is explicitAny framework can call the sandbox
microVM for explicit sandbox commands
Code sent through `ctx.sandbox` executes in a separate microsandbox/libkrun VM with its own guest kernel. The boundary applies to that code-execution command or session, not to every hosted agent request.
Separate from the hosted service
The agent's HTTP runtime is a Knative or Kubernetes container service. Moving model-generated code into a separate microVM reduces shared-kernel exposure for that command, while the privileged sandbox daemon remains part of the trusted computing base.
Scoped filesystem
A grant-authenticated sandbox call mounts its authorized workspace bucket at `/workspace` with path and write-prefix policy. The guest also has the selected OCI image's root filesystem; it does not receive an arbitrary host-disk mount.
Lifecycle matched to the job
One-shot shell and Python endpoints create a VM for the command and stop it afterward. Named sandbox sessions can span multiple commands and remain available until the caller deletes or shuts them down.
Network control is explicit
Sandbox network access is enabled unless the caller requests `network_disabled`. When requested, the runtime attempts to install guest-local deny rules before executing the command.
Any framework can call the sandbox
A LangGraph, OpenAI Agents SDK, CrewAI, or custom hosted skill can send selected code through `ctx.sandbox`. The framework stays in its container; only the explicit code-execution work crosses into the microVM boundary.
side-by-side
Shared-kernel container vs. libkrun microVM.
escape surface
container
The code shares the hosted container's kernel and process-level authority.
a2a explicit sandbox
The guest is separated by a VM boundary; the privileged sandbox daemon remains trusted infrastructure.
filesystem
container
The hosted process can see its image filesystem and configured runtime resources.
a2a explicit sandbox
An OCI guest root plus a grant-scoped workspace mounted at `/workspace`.
lifetime
container
One lifecycle regardless of whether the job is one-shot or interactive.
a2a explicit sandbox
One-shot VMs stop after the command; named sessions persist until deleted or shut down.
provability
container
Sandbox output is mixed into unstructured process logs.
a2a explicit sandbox
The sandbox result can return workspace and rootfs-capture references; receipt fields are separate and entry-point scoped.
dimension
container
a2a explicit sandbox
boundary
Generated code executes inside the long-lived hosted agent process.
Selected code executes in a separate libkrun microVM with its own guest kernel.
escape surface
The code shares the hosted container's kernel and process-level authority.
The guest is separated by a VM boundary; the privileged sandbox daemon remains trusted infrastructure.
filesystem
The hosted process can see its image filesystem and configured runtime resources.
An OCI guest root plus a grant-scoped workspace mounted at `/workspace`.
lifetime
One lifecycle regardless of whether the job is one-shot or interactive.
One-shot VMs stop after the command; named sessions persist until deleted or shut down.
provability
Sandbox output is mixed into unstructured process logs.
The sandbox result can return workspace and rootfs-capture references; receipt fields are separate and entry-point scoped.
questions
Frequently asked.
How does a2a cloud sandbox AI agents?
Hosted agent skills run as Knative or Kubernetes container services. When skill code explicitly calls `ctx.sandbox`, the selected shell or Python command runs in a separate microsandbox/libkrun VM with a guest kernel. The sandbox is an attached code-execution service, not the envelope for every skill invocation.
What's the difference between a microVM and a container for agents?
A container isolates processes while sharing a host kernel. A microVM supplies a guest kernel behind a virtualization boundary, reducing shared-kernel exposure for model-generated or otherwise untrusted code. On a2a, the hosted service remains containerized and only explicit sandbox work uses the microVM; the privileged sandbox daemon is still trusted infrastructure.
Can a compromised agent access the host filesystem?
The guest receives the selected OCI root filesystem and an authorized workspace mounted at `/workspace`, not an arbitrary host-disk mount. Grant-authenticated workspace access enforces the bucket, path, and write-prefix policy. This narrows access without making an absolute no-escape claim; the privileged sandbox daemon remains in the trusted computing base.
Is the sandbox persistent or per-run?
One-shot `run_shell` and `run_python` calls create a VM for a command and stop it in cleanup. Explicit named sandboxes are intentionally reusable across commands and remain live until deleted or shut down. Workspace writes can persist in object storage, and the implementation does not support a blanket claim that every sandbox disk artifact is deleted after every command.
Do I have to choose which code uses microVM isolation?
Yes. Your hosted framework code remains in its container service. Send the code-execution step through `ctx.sandbox` when you want the separate microVM boundary. Receipt coverage is determined by the execution entry point — authenticated Agent API, public `/invoke`, or standard MCP `tools/call` — and sandbox artifacts are not automatically asserted as receipt fields.
keep reading
Related guides.
All guides live in the guides index.
no ambient trust
Give the agent a boundary, not a shell on your host.
a2a cloud hosts LangGraph, OpenAI Agents SDK, CrewAI, or custom skills as Knative or Kubernetes container services. Send selected code through `ctx.sandbox` for a separate libkrun microVM and grant-scoped workspace. Authenticated Agent API calls and public `/invoke` or standard MCP `tools/call` executions receive platform-signed receipts; connector MCP jobs and formal A2A message/task routes are outside that skill-execution coverage.