Workspace isolation
Git worktrees, copies, reflinks, overlays, snapshots. Great at containing accidental edits; not a defense against a process that can see the host.
September 2026 · practical, evidence-led
Give an agent a room, not the whole house.
A field guide to the isolation layers, secret boundaries, and repositories worth considering before an AI coding agent meets your machine.
Not a directory. Not a guarantee. A map of tradeoffs, evidence, and likely weekend-wasters.
VM boundary
container
policy
AI
✦credential
broker
broker
YOUR MODEL IS NOT YOUR SECURITY BOUNDARY ✦ YOUR MODEL IS NOT YOUR SECURITY BOUNDARY ✦ YOUR MODEL IS NOT YOUR SECURITY BOUNDARY ✦
The useful mental model
“Sandbox” is a stack of answers to different questions.
A container answers “which processes, files, and network namespace?” A microVM or VM adds a guest kernel. A policy layer narrows what a process can ask for. A credential broker lets an API call work without handing over the actual key.
These layers complement one another. They do not make each other magically safe.
Landscape
Six layers that matter
Move down the stack when the work becomes less trusted, more autonomous, or more credentialed.
Process policy
Landlock, seccomp, bubblewrap, AppContainer, Seatbelt. Strongly useful narrowing; still shares an OS kernel with its host.
Rootless container
Namespaces, cgroups, image layers, unprivileged user mappings. A sensible everyday boundary—if mounts, sockets, and networking are disciplined.
Application kernel
gVisor interposes a user-space kernel-like layer for many calls. It aims to reduce direct exposure to the host kernel without becoming a full VM.
MicroVM
Firecracker, Cloud Hypervisor, crosvm and Kata use hardware virtualization. Better kernel separation, more image/network/snapshot engineering.
Full VM / desktop VM
A separate operating system is often the boring answer. It has the broadest compatibility and clearest blast-radius reduction, at a cost in resources and setup.
Starting points
Pick the smallest boundary that fits the job.
I want safe-ish daily local coding
Use a dedicated OS account or WSL2/VM plus rootless Podman, a project-specific mount, no Docker socket, a separate home, and network rules. Keep changes in a worktree or exported patch.
See the daily stack →I want to run stranger code autonomously
Use a disposable VM or microVM. Disable shared folders by default, keep secrets out, and choose an explicit egress allowlist. Reset from a known image.
See the stronger stack →The agent needs APIs but not my keys
Give it a scoped operation or placeholder token, then inject the real credential at a trusted proxy or broker. The broker only works when it is the only route to the service.
See the secret stack →Security reality check
What a layer does not automatically solve.
Container ≠ VM. A conventional container still shares its host kernel. Rootless meaningfully reduces privilege but does not turn unsafe mounts or a Docker socket into safe ones.
VM ≠ no exfiltration. A VM with broad network access, shared clipboard, host folders, cloud credentials, or a browser logged into everything is still highly capable.
Secret proxy ≠ secret safety. It helps only if the agent cannot bypass it, read the vault, reuse a long-lived bearer token, or trick the proxy into an over-broad action.
Worktree ≠ containment. It is excellent change management. It is not a process boundary.
Questions people actually ask
Short answers before the rabbit hole.
Should I just use Docker?
For a known project and a supervised coding agent, a carefully configured rootless Podman/Docker-style workflow is a good starting point. Do not hand it the Docker socket, your full home directory, host networking, or raw credentials. Use a VM first when the blast radius needs to include kernel-level threats or messy GUI/browser work.
Is Podman “safer” than Docker?
Podman makes rootless and daemonless workflows natural, which is helpful. Security comes from the whole configuration: UID mappings, mounts, capabilities, network mode, image trust and any host-control socket. Treat “rootless” as one important property, not the verdict.
Can an agent access a project but nothing else?
Yes, approximately: give it only a dedicated workspace directory in an isolated account/container/VM; make other files unavailable; do not mount your home; and use a separate credential route. Verify from inside the sandbox rather than assuming a configuration did what you meant.
Can I let it use APIs without seeing the key?
Yes. Use a credential broker or request proxy that receives a placeholder/capability from the agent and injects the real credential only for explicit routes. Keep the broker and vault outside the agent’s filesystem and network authority.