What Is Agent Isolation (and Why Containers Aren't Enough)?

Quick answer
Isolation is four boundaries: filesystem, network, credentials, and host process. A container gives you the first and part of the last.
A container with your home directory mounted, your tokens in the environment, and open egress is not a sandbox; it is your machine with extra steps.
Give each run a fresh workspace, a scoped identity, and an explicit egress policy.
Disposable environments beat long-lived ones, because state accumulated between runs becomes part of the attack surface.
Test isolation by trying to reach something the run should not: a production host, the metadata service, another run’s workspace.

What does an agent need to be isolated from?

From the host: other files, other processes, and the credentials of whoever started it. From the network: anything the task does not need, especially the cloud metadata endpoint and internal services. From other runs: workspaces, logs, and secrets that belong to a different task.

Those are separate controls. A container can give you a filesystem and a process boundary while leaving the network wide open and the credentials in the environment. That combination is common and provides much less protection than it appears to.

Why is a container not automatically a sandbox?

Because containers share the host kernel and are usually configured for convenience: a bind mount of the project, the developer’s environment passed through, and default network access. None of that is malicious; it is how people ship. It also means a command in the container can read the same files and reach the same hosts as the process outside it.

Real isolation is a set of deliberate choices: a read-only base, a writable workspace only, no host environment, a network policy, and a non-root user. Without those, the container is a packaging format, not a security boundary.

# A more isolated run
docker run --rm -it \
  --network agent-net \
  --read-only --tmpfs /tmp \
  --user 10001:10001 \
  --cap-drop ALL --security-opt no-new-privileges \
  -v "$PWD":/workspace:rw -w /workspace \
  --env-file .agent-env \
  agent-image:1.4.2

What does isolation look like for a hosted agent?

A fresh VM or microVM per run, an identity issued to that run, and a network policy that permits only the registry and the task endpoints. The workspace is destroyed at the end, so nothing persists except what was deliberately committed.

The advantage over a shared container host is the boundary between runs. Two runs on the same kernel can potentially see each other’s processes or mounts if the configuration is wrong. A per-run VM makes that failure much less likely.

How do you verify isolation?

Attempt the things the run should not be able to do: read a host path outside the workspace, resolve the metadata endpoint, reach production, write outside the workspace, and persist a file after the run ends. Each attempt should fail for the right reason.

Run the same test from inside the agent, not just from the host. The agent has the same permissions as the shell it runs, so if a shell command can reach something, so can an injected instruction.

Where this bites vibecoders
The usual setup is a dev container that mounts the home directory and inherits the shell environment. It feels isolated because it is a container, but it can read your SSH keys and call any API you can. Fix the mounts and the environment before calling it a sandbox.

Where AI coding assistants get this wrong

Mounting the home directory into the workspace.
Passing the host environment and tokens into the container.
Leaving default network access enabled.
Running as root because the base image does.
Reusing one long-lived workspace across unrelated tasks.
Assuming a container boundary covers credentials and network.

Checklist

Use a read-only base with a writable workspace only.
Run as a non-root user with no new privileges.
Pass only the environment the task needs.
Apply an egress allowlist and block the metadata endpoint.
Use a fresh workspace per run where possible.
Test what the run cannot reach.

FAQ

Is a VM better than a container?

It gives a stronger boundary, at the cost of start time and operational overhead. For an agent that runs arbitrary commands with credentials, the stronger boundary is usually worth it. For a read-only review job, a well-configured container may be enough.

Does isolation stop prompt injection?

No, but it limits what a successful injection can do. That is the point: the model may still be convinced, but the run cannot reach the data or the destination that would make the injection harmful.

What about secrets the task genuinely needs?

Issue them to the run, scoped and short-lived, rather than baking them into the image or the host environment. Prefer a proxy that holds the credential so the agent calls an operation instead of holding the key.

How long should a workspace live?

For the run, or for a short debugging window. Long-lived workspaces accumulate state, credentials, and half-finished changes, and they make “which run did this?” harder to answer. Recreate them from a recipe instead of preserving them.