AI Agent Sandboxes Stop Escapes. They Don't Tell You What Happened Inside.

Docker just shipped Docker Sandboxes, a product that runs AI coding agents — Claude Code, Codex CLI, Copilot CLI, Kiro, OpenCode — inside dedicated Firecracker microVMs. Each sandbox gets its own kernel, an isolated filesystem mount of your project workspace, and a network policy that blocks everything except an explicit allowlist of hostnames. When the session ends, the entire environment is discarded.

For the developers running agents in YOLO mode (--dangerously-skip-permissions) this is a meaningful step forward. The sandbox contains the blast radius. Your host stays untouched.

But containment is not visibility. A sandbox tells you whether an agent escaped. It tells you nothing about what the agent did while it was inside.

That gap matters more than the escape risk for most organizations.

Why Containers Were Never Enough

Before Docker Sandboxes, the common advice for running AI agents "safely" was to use a Docker container. Mount only the project directory. Drop the container when done. That advice was always weaker than it sounded.

Docker containers share the host kernel. Namespace and cgroup separation is real, but it is enforced in software, by the same kernel that the container is running on. Container escapes — exploiting kernel vulnerabilities from inside a container — are a documented and recurring class of CVE. CVE-2019-5736 (runc overwrite), CVE-2022-0492 (cgroup escape), CVE-2024-21626 (runc again) — these are not theoretical. They require a motivated attacker, but an AI agent manipulated via prompt injection is not a trustworthy process.

Firecracker microVMs are different in kind, not degree. Each sandbox runs its own Linux kernel, isolated from the host by the hardware virtualization boundary (KVM). A guest kernel exploit does not propagate to the host. This is the same isolation model used by AWS Lambda and Fly.io machines, where untrusted code from arbitrary customers runs on shared hardware.

So Docker Sandboxes is solving the right problem with the right primitive.

The containment story is solid. The problem starts after containment.

What a Sandbox Actually Stops

It helps to be precise about the threat model. A microVM sandbox with network policy controls the following 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.

Host persistence after session. When the sandbox is discarded, the agent's installed packages, modified configs, and shell history go with it. There is no persistence on the host.

These are real and meaningful controls. For unattended agent workloads — nightly refactoring jobs, CI-triggered code review agents, autonomous test generation — this containment model is the right foundation.

What a Sandbox Does Not Stop

The sandbox boundary is the microVM perimeter. Everything inside that perimeter is opaque.

You have no audit trail of agent actions. The agent read a file, wrote a file, ran a shell command, made a network request. None of this is recorded in a structured, reviewable format outside the agent's own session log — which is itself inside the sandbox and controlled by the agent process. If the agent deletes its own logs before the session ends, the record goes with it.

The agent can do significant damage within its allowed scope. An agent manipulated via prompt injection — a malicious string in a file it was asked to summarize, a poisoned dependency README — can delete your entire project workspace, overwrite critical configuration, push to git remotes (if git credentials are mounted), or exfiltrate source code to any of the allowed hostnames. The sandbox stopped it from reaching your host. It did not stop it from acting against the project it was given access to.

The network allowlist is static and coarse. If api.github.com, registry.npmjs.org, or pypi.org are on the allowlist — and they almost certainly are for any real development workflow — an agent that installs a malicious package or pushes to a compromised remote has legitimate network access to do so. The allowlist prevents beaconing to arbitrary attacker infrastructure, but it does not prevent exfiltration via channels that are legitimately open.

You cannot reconstruct what happened after the fact. If a sandbox session produces unexpected output, deletes files, or commits surprising code, you have no kernel-level record to audit. The agent's session log, if it exists and was not tampered with, tells you what the model intended. It does not tell you what actually executed at the syscall level.

This is the blind spot. And it is not a flaw in Docker Sandboxes — it is a gap in the current AI agent security stack that no product has addressed.

What eBPF Sees

eBPF (Extended Berkeley Packet Filter) is a Linux kernel technology that lets you attach small programs to kernel events — syscall entry/exit, network packet processing, filesystem operations — without modifying the kernel itself and without adding a security boundary that can be evaded. Tools like Cilium Tetragon and Falco use eBPF to generate structured audit events for everything a process does.

Applied to an AI agent sandbox, eBPF running on the host can observe events that occur inside the microVM:

• Every open(), read(), write(), unlink() call the agent makes, with the full resolved path
• Every execve() — every subprocess the agent spawns, with its argv
• Every outbound TCP connection the agent opens, with destination IP and port
• Every connect() to a Unix socket
• Every clone() or fork() — every child process

This is not sampling. eBPF events are generated synchronously with the kernel events themselves. You get a complete, tamper-resistant record of agent behavior at the syscall level, written to a stream outside the agent's control.

The key property: the agent cannot suppress, modify, or delete eBPF events. The event stream is written by the host kernel before the agent's process even returns from the syscall. An agent that deletes its own session log does not affect the eBPF record.

What a Complete Audit Trail Looks Like

Here is what structured eBPF telemetry from a Claude Code session inside a Docker Sandbox would look like with Tetragon:

{"process": {"pid": 1847, "binary": "/usr/bin/node", "arguments": "claude --dangerously-skip-permissions"},
 "action": "open", "path": "/workspace/src/auth/session.ts", "flags": "O_RDONLY"}

{"process": {"pid": 1847, "binary": "/usr/bin/node"},
 "action": "open", "path": "/workspace/.env", "flags": "O_RDONLY"}

{"process": {"pid": 2103, "binary": "/bin/bash", "arguments": "npm install lodash-contrib"},
 "action": "connect", "destination": "104.16.1.35:443", "hostname": "registry.npmjs.org"}

{"process": {"pid": 2103, "binary": "/bin/bash"},
 "action": "execve", "path": "/workspace/node_modules/.bin/postinstall-hook", "arguments": ""}

{"process": {"pid": 1847, "binary": "/usr/bin/node"},
 "action": "open", "path": "/workspace/src/auth/session.ts", "flags": "O_WRONLY|O_TRUNC"}

From this stream you can answer questions that are currently unanswerable:

• Did the agent read .env before modifying auth code? (Yes.)
• Did a postinstall hook run after a package was installed? (Yes. What did it do next?)
• Did the agent open a file for writing that it did not have explicit instructions to modify?
• Did any subprocess attempt a connection to an IP not on the allowlist?

These are the questions a security team asks after an incident. Right now, the sandbox discards the environment before those questions can be answered.

Tetragon and Falco: Practical Starting Points

Cilium Tetragon is the more capable option for AI agent observability. It supports TracingPolicy resources that define exactly which events to capture — you can instrument open, execve, connect, and clone syscalls, filter by process binary (claude, node, python), and export structured JSON to any log aggregator. Tetragon runs as a DaemonSet in Kubernetes or as a standalone binary on a Linux host.

A minimal Tetragon policy for AI agent sessions:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: ai-agent-audit
spec:
  kprobes:
    - call: "fd_install"
      syscall: false
      args:
        - index: 0
          type: int
        - index: 1
          type: "file"
      selectors:
        - matchBinaries:
            - operator: In
              values:
                - "/usr/bin/node"
                - "/usr/bin/python3"
                - "/bin/bash"
                - "/bin/sh"
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string"
        - index: 1
          type: "string_array"
    - call: "tcp_connect"
      syscall: false
      args:
        - index: 0
          type: "sock"

Falco is the more accessible starting point if you already have it deployed. Falco's rule language is simpler, and its default ruleset already catches a number of anomalous behaviors. The limitation is that Falco works at a higher abstraction level and misses some syscall-level detail that Tetragon captures. For AI agent workloads — where the anomalous behavior is often subtle (reading a credential file, spawning an unexpected subprocess) rather than dramatic — Tetragon's granularity is worth the additional setup.

Where This Leaves the AI Agent Security Stack

A microVM sandbox and an eBPF audit layer address different parts of the threat model and should be used together:

None of these layers is sufficient alone. A sandbox without visibility is a black box you trust blindly. Visibility without containment means you can see an agent escape but not stop it. The agent permission system is software that runs inside the agent process and can be bypassed by a sufficiently manipulated model. Policy enforcement without a real audit trail cannot be verified after the fact.

The current state of AI agent security has the containment layer. It is missing the visibility layer. That is the gap eBPF fills — and it is the gap that will matter most when the first serious AI agent security incident happens inside a well-sandboxed environment.

The sandbox stopped the escape. The audit log tells you what actually happened.