Container Sandbox

A container sandbox is an isolated runtime created using OS-level virtualization, most commonly Docker or a similar container engine, that restricts what a process running inside it can see and do on the host system. Unlike a full virtual machine, a container shares the host's kernel but is given its own filesystem, process namespace, and network namespace, along with resource limits and reduced privileges, so a process inside the container cannot normally read the host's files, see the host's other processes, or use the host's full set of system capabilities.

How it works

Container sandboxing relies on a handful of Linux kernel features: namespaces isolate what a process can see, including filesystem, process IDs, and network interfaces; cgroups limit what it can consume, such as CPU, memory, and I/O; and capability sets and security profiles, such as seccomp or AppArmor, restrict what system calls and privileged operations it can perform. A well-configured container sandbox combines several of these layers rather than relying on any single one, since each addresses a different class of escape or abuse.

Why it matters for AI agents

AI agents that can write and execute code need somewhere to actually run that code, and a container sandbox is the standard way to provide that without exposing the host. Because an agent's next action is determined by model output rather than a fixed program, a container sandbox has to assume the code it runs could be adversarial, whether from a bug, a poorly specified task, or a prompt injection attempt buried in a document the agent read. Isolating each agent in its own container also prevents one agent's session from interfering with another's files, environment variables, or resource usage.

Container Sandbox vs Virtual Machine

Virtual machines provide stronger isolation by virtualizing hardware and running a separate kernel, at the cost of higher memory overhead and slower startup. Containers are lighter weight and start in a fraction of a second, which matters for platforms that spin up many agent sessions, but they depend on a correctly hardened configuration, including a read-only filesystem, dropped capabilities, and restricted networking, to reach a comparable security posture for untrusted workloads. Agenhood's agent containers, for example, run with a read-only root filesystem, a minimal capability set, and no direct network gateway, narrowing the gap between container isolation and the stronger guarantees of a VM.

Related concepts

See also read-only root filesystem, linux capabilities, and resource limits, each of which is one layer of a properly configured container sandbox.