Compare
Containers vs sandboxes for AI agents.
Agents run code that a model wrote a second ago and nobody reviewed. A standard container shares the host kernel with everything else on the node. This guide compares the isolation options and when each one fits.
In short
- Containers are a packaging and resource boundary. They are fine for code you trust, and weak for code you don't.
- Sandboxes add a second boundary: a user-space kernel (gVisor), a microVM (Kata Containers with Firecracker) or a confidential VM that also hides memory from the host.
- Isolation is not governance. A perfectly sandboxed agent can still misuse every API it holds credentials for. That is the gateway's job.
Side by side
| Standard container (runc) | gVisor · tier-0 | Kata + Firecracker · tier-1 | Confidential VM · tier-2 | |
|---|---|---|---|---|
| Kernel boundary | Shares the host kernel | A user-space kernel intercepts system calls | Its own guest kernel in a hardware-virtualised microVM | Its own guest kernel; memory encrypted from the host |
| Protects from the host operator | No | No | No | Yes, within the hardware vendor's trust model |
| System-call compatibility | Full | Most workloads; some system calls are not implemented | Full | Full |
| Start-up and overhead | Lowest | Low | Higher: a VM boots per sandbox | Highest: VM boot plus attestation |
| Node requirements | None | None beyond the runtime | Hardware virtualisation (KVM) | AMD SEV-SNP or Intel TDX hardware |
| Good for | Code you wrote and reviewed | Code interpreters, data analysis, untrusted scripts | Build tools, browsers, broader system-call needs | Regulated data, customer secrets, untrusted infrastructure |
Overheads depend on your hardware and workload; measure them on your own nodes.
Why it matters for agents
Model-written code is untrusted code.
A web service runs code your team wrote and reviewed. An agent runs whatever its model produced from its context window, which may include a web page, an email or an issue written by an attacker. One kernel exploit in that code, inside a standard container, becomes a node compromise and a path to every other workload on the node.
Sandboxes shrink that blast radius. gVisor puts a user-space kernel between the agent and the host. A microVM gives each session its own kernel behind hardware virtualisation. A confidential VM goes further and encrypts the session's memory, so even the host operator cannot read it, and proves it with attestation.
None of these stop an agent from calling an API it has a token for. That is why MAQPNA pairs every sandbox with default-deny networking and a gateway that checks each call.
Where MAQPNA fits
Every tier, chosen per agent, governed the same way.
MAQPNA creates each session's sandbox through the upstream kubernetes-sigs/agent-sandbox project, with the RuntimeClass of the agent's trust tier, a default-deny NetworkPolicy and a short-lived identity. Calls leave only through the gateway.
apiVersion: maqpna.com/v1alpha1
kind: Agent
metadata:
name: code-interpreter
spec:
image: registry.example.eu/agents/interpreter:1.2
tier: tier-0 # gVisor; tier-1 microVM; tier-2 confidential VM
policyRef: interpreter-toolsFAQ
Common questions
Is a container enough to run AI agent code?
For code you wrote and reviewed, usually yes. For code a model generated, a standard container is a weak boundary because it shares the host kernel. Use a sandbox runtime such as gVisor or a microVM for untrusted code.
Do I need confidential VMs?
Only when the host operator is outside your trust boundary, for example on shared or third-party infrastructure, or for regulated data that must be protected in use. They need AMD SEV-SNP or Intel TDX hardware.
Can I mix tiers in one cluster?
Yes. In MAQPNA each agent names its trust tier, and only the runtimes installed on your nodes need to be enabled.
Pick the boundary per agent.
Run tier-0 on a laptop today, then choose microVMs or confidential VMs per agent in your cluster.
curl -fsSL https://maqpna.com/install.sh | shbrew install azmxai/maqpna/maqpnairm https://maqpna.com/install.ps1 | iexNo Kubernetes, GPU or API key needed to try it. Every download is checked against its SHA-256 and cosign signature.