AI Agent Sandbox Security: Docker Sandboxes, MicroVMs, and the eBPF Gap | RyeSign inStart free trialMenu

Back to articlesPublishedAugust 10, 2026<br>Reading8 min read<br>AuthorPeter W. NjengaFounder<br>TopicsAi CodingSecurityRuntime Security<br>Docker just shipped Docker Sandboxes. It runs AI coding agents such as Claude Code, Codex CLI, Copilot CLI, Kiro, and OpenCode inside dedicated microVMs using a custom VMM built for cross-platform support on macOS, Windows, and Linux. Each sandbox gets its own kernel, a mounted workspace, and a network policy that only allows approved hostnames. The workspace mount is live on your host filesystem throughout the session. VM state - installed packages, shell history, files written inside the VM - persists across restarts and is discarded only when the sandbox is explicitly removed.

For developers running agents in YOLO mode (--dangerously-skip-permissions), this is a real improvement. If the agent goes sideways, the host should stay clean.

But a sandbox only answers one question: did the agent get out?

Most teams will need a different answer first: what did the agent do while it was in there?

Why Containers Were Never Enough

Before Docker Sandboxes, the usual advice was to put the agent in a Docker container. Mount only the project directory. Delete the container when the job is done. That sounds cleaner than it is.

Docker containers share the host kernel. Namespaces and cgroups help, but the same kernel still enforces the boundary. Container escapes are a recurring class of CVE: CVE-2019-5736 for runc overwrite, CVE-2022-0492 for cgroup escape, CVE-2024-21626 for runc again. None of these are casual attacks. Still, an AI agent manipulated through prompt injection is not a process I would trust by default.

Firecracker microVMs change the shape of the risk. Each sandbox runs its own Linux kernel and is isolated from the host by KVM. A guest kernel bug should not become a host kernel bug. This is the same basic isolation model used by AWS Lambda and Fly.io machines, where untrusted customer code runs on shared hardware.

So the isolation primitive is the right one.

Isolation modelShared host kernelHardware boundaryTypical startupDocker containerYesNo~50msgVisorNo (user-space kernel)No~100msFirecracker microVMNoYes (KVM)~125msFull VMNoYes2-5s

The problem starts after the boundary holds.

What a Sandbox Actually Stops

It helps to be precise. A microVM sandbox with network policy narrows these attack surfaces:

Host filesystem access. The agent can only see and write the project workspace that was explicitly mounted. It cannot read ~/.ssh/, ~/.aws/credentials, your shell history, or any other file on your machine.

Host process access. The agent cannot see or signal host processes. It cannot attach a debugger to your IDE, kill your VPN client, or tamper with other running agents.

Lateral network movement. With a deny-all-except-allowlist network policy, the agent cannot reach your internal network, your cloud metadata endpoint (169.254.169.254), or arbitrary internet infrastructure. It can only talk to the domains you approved.

VM-layer persistence on dispose. When the sandbox is explicitly removed, installed packages, shell history, and files written inside the VM outside the mounted workspace are discarded. The workspace itself is a live mount - the agent reads and writes your host files directly throughout the session, not copies. VM state persists across restarts until you run the dispose command.

Those controls matter, especially for unattended jobs: nightly refactors, CI code review agents, and autonomous test generation. I would rather run those in a microVM than on a developer laptop.

What a Sandbox Does Not Stop

The sandbox boundary is the microVM perimeter. Inside that perimeter, you still have a busy little machine doing real work.

You have no audit trail of agent actions. The agent reads files, writes files, runs shell commands, and opens network connections. The sandbox does not record that in a structured log outside the agent's own session log. That log is inside the sandbox and controlled by the agent process. If the agent deletes it before the session ends, the record goes with it.

The agent can still damage the project. A prompt-injected agent can delete the workspace, overwrite config, push to git remotes if credentials are mounted, or send source code to an allowed hostname. The sandbox stopped it from reaching the host. It did not stop it from using the access you gave it.

The network allowlist is blunt. If api.github.com, registry.npmjs.org, or pypi.org are allowed, and they probably are for real development work, a malicious install or compromised remote has a valid path out. The allowlist blocks random attacker infrastructure. It does not block misuse of channels that are supposed to be open.

You cannot reconstruct what happened after the fact. If a sandbox session produces unexpected output, deletes files, or commits surprising code, you...