A standard container isolates a coding agent from other processes using kernel namespaces and cgroups, but it still runs on the host kernel. A kernel flaw or a risky mount can break that boundary. Stronger options put a user-space kernel or a hardware-virtualized microVM between the agent and the host.
What a container gives you
Docker's security documentation says namespaces keep processes in one container from seeing or affecting processes in other containers or on the host, and cgroups limit CPU, memory, and disk I/O. Containers also start with a restricted set of Linux capabilities, so root inside a container has fewer privileges than host root. Dropping everything a process does not need is the recommended practice.
What it does not give you
The same documentation points to several ways the boundary weakens:
- The Docker daemon runs as root unless you use rootless mode, so only trusted users should control it.
- Bind mounts can expose host paths. A container that mounts the host root can modify the host filesystem.
- User namespaces, which map container root to an unprivileged host user, are available but not enabled by default.
For a coding agent, the mount point is the practical risk. If you mount the container runtime socket or a home directory into the sandbox for convenience, the agent can reach far beyond the task.
Two stronger designs
| Approach | How it isolates | Stated trade-off |
|---|---|---|
| User-space kernel (gVisor) | An application kernel written in Go intercepts system calls instead of passing them to the host kernel | Reduced compatibility, since not every system call is implemented, and higher per system call overhead |
| MicroVM (Firecracker) | A VMM uses KVM to run each workload in a microVM with hardware virtualization | Security depends on a well-configured Linux host |
gVisor's own documentation frames its goal as minimizing the risk of a container escape, not eliminating it. Firecracker's page states that overall security, including suitability for multi-tenant computing, depends on a well-configured host. Neither source claims a perfect boundary, and you should not either.
Choosing for an agent sandbox
- Ask what the agent can do. If it only edits files and runs tests on code you wrote, a hardened container may be enough.
- If it runs code from outside your trust boundary, such as installs from public registries or unreviewed branches, prefer a user-space kernel or microVM.
- Never mount the runtime socket, host home, or cloud credentials into the sandbox.
- Run as a non-root user and drop capabilities.
- Keep the host patched. Every design above depends on it.
On Kubernetes, the RuntimeClass resource lets you choose a runtime configuration per pod, so sensitive workloads can use stronger isolation while others keep the default. Its documentation notes the extra overhead and recommends limiting who can create or change RuntimeClass objects.
Worked example: three sandboxes for the same agent
Suppose you run an agent that executes tests for a web service. This is an illustrative comparison, not a benchmark.
Sandbox A: a default container. The image is a general purpose Linux base with build tools. It runs as root inside the container. The runtime socket is not mounted. The agent runs the tests, which install packages from a public registry. A malicious install script runs as root inside the container, and can talk to the kernel through ordinary system calls. If a kernel flaw exists and is reachable, that is the path out.
Sandbox B: a hardened container. Same image, but it runs as a non-root user with every capability dropped, a read-only root filesystem, a writable scratch directory, and user namespaces mapping container root to an unprivileged host user. The attack surface is smaller, but the kernel is still shared.
Sandbox C: a microVM. Each task boots a small virtual machine with its own kernel. A kernel flaw inside the guest stays inside the guest unless the hypervisor boundary is also broken. The cost is start time, memory overhead, and a host you must keep configured correctly.
For code you wrote and tests you control, B may be enough. For installs from outside your trust boundary, or for tasks that run content from untrusted pull requests, C is the more defensible choice.
A hardening checklist for container-based agent sandboxes
- Run as a non-root user.
- Drop all Linux capabilities and add back only what a process needs.
- Use a read-only root filesystem with an explicit writable path.
- Do not mount the container runtime socket. Mounting it gives the agent control of the daemon, which Docker's documentation says runs as root unless you use rootless mode.
- Do not bind mount host directories beyond the project workspace.
- Enable user namespace remapping if your runtime supports it, since it is not on by default.
- Apply a seccomp profile and, where available, AppArmor or SELinux policy.
- Set resource limits so one task cannot exhaust the host.
- Use a minimal base image, and scan it.
- Keep the host kernel and runtime patched.
How to read an isolation claim
| Claim you hear | Question to ask |
|---|---|
| "Runs in a container" | Which runtime, which user, which mounts, which capabilities? |
| "Runs in a VM" | Is it single use? Who patches the hypervisor and host? |
| "Uses a hardened runtime" | Which one, and what compatibility limits did you accept? |
| "Isolated per customer" | Per task, per user, or per organization? |
| "Sandboxed" | Show me the network policy and the credential model |
Why the image matters as much as the runtime
A strong boundary does not help if the image inside it is full of outdated packages the agent will call. Treat the base image like any dependency: pin it by digest, rebuild on a schedule, and scan it for known issues. An agent that is told to exploit a vulnerable tool in its own image has no need to escape anything.
Where Safeguard fits
Safeguard does not provide sandbox runtimes. It can scan the dependencies and images that go into them, using SBOM and dependency scanning.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and look at what the base image brings in, because a sandbox inherits every package in its image.
Quick check
Is a microVM always better than a container for an agent?
It gives a stronger boundary, with more overhead and a host that must still be hardened. Match the choice to what the agent runs.
Does gVisor make escape impossible?
No. Its documentation says the aim is to minimize the risk of container escape, not remove it.
Is a rootless container enough for untrusted code?
It reduces the damage from a container escape, because container root maps to an unprivileged host user. It does not change that the kernel is shared, so weigh it against a microVM for hostile code.
Sources
Last reviewed: 19 October 2026.
