AI Agent Sandboxing: Containers, gVisor, and MicroVMs

Architecture guidance AI & Agent Security

ELI5 — A room, a guarded workshop, and a separate building

A container is like a locked room in a shared building: it limits access but still relies on the building’s common structure. In the guarded workshop, gVisor’s Sentry is the clerk at the service desk: it receives each system-call request and handles it in its own user-space application kernel instead of passing the workload’s calls straight through to the host kernel. A microVM is more like a separate building, with its own guest kernel behind a hardware virtualization boundary. These choices change isolation boundaries and operating cost; none decides which files, credentials, tools, or network destinations the agent may use.

What the isolation boundary does—and does not—prove

Linux containers share the host kernel. Kernel flaws matter, but escape is not automatic: it requires a reachable flaw, excessive privilege, or unsafe host integration. Docker warns that daemon access can enable host control; do not expose its socket to untrusted workloads. gVisor handles system calls in its Sentry application kernel. Firecracker uses one VMM process per microVM; isolation relies on the KVM boundary plus additional process sandboxing, and host networking must filter guest egress. Read the official sources below. Docker Engine security; gVisor security architecture; Firecracker design.

Configuration contrast: unsafe privileges and layered limits

The first configuration grants a host-control socket and unrestricted networking: avoidable trust paths, not an exploit demonstration. The second is an illustrative baseline; verify runtime support and enforce identity, resource, filesystem, and network policies separately.

Illustrative unsafe container settingsAvoid

services:
  agent-runner:
    image: agent-runner:stable
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /:/host
    network_mode: bridge

Illustrative constrained runsc settingsHarden

services:
  agent-runner:
    image: agent-runner:stable
    runtime: runsc # Configure and verify gVisor with your container runtime
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    network_mode: none
    tmpfs:
      - /tmp:size=128M,mode=0700

A realistic failure path is conditional

Untrusted input reaches the agent

The agent runs code or tools based on repository content or a request.

The workload crosses a boundary

A reachable flaw, exposed socket, writable host mount, or broad credential may create a path outside.

Impact depends on granted access

Reachable files, credentials, and destinations set the scope; a container does not automatically compromise the host.

Independent controls reduce impact

Separate tenants, minimize mounts and credentials, enforce network egress rules, and log activity.

Production review checklist

✓Do not mount the Docker socket, host root, cloud credentials, or unrelated repositories into untrusted workloads.
✓Choose a hardened container, gVisor, or microVM for the threat model; patch kernels, runtimes, and the VMM.
✓Limit CPU, memory, processes, disk, and runtime; use disposable per-job workspaces.
✓Enforce destination allowlists outside the runtime and block metadata endpoints unless explicitly required.
✓Provide short-lived, least-privilege credentials through a broker.
✓Test failure cases and audit effective configuration. A sandbox is one layer, not authorization for tool or data access.

Explore related security topics:Complete Security Directory →