Straight answers to the questions everyone asks
These are the questions that show up in every Hacker News thread, Discord channel and internal Slack about agent sandboxing. Each answer starts with the short version, then explains the caveat that makes the short version misleading if you stop reading.
Jump to
Containers and the Docker question
Should I just use Docker?
Yes, with one caveat: not Docker Desktop's default habits. The container engine is
the right first answer — it is fast, well understood, and every agent tool supports it. What you must
avoid is the template culture around it: mounting the Docker socket, running --privileged,
mounting your whole home directory, or using --network host. Those four habits are the
single most common cause of "my container sandbox turned out not to be one". If you are choosing fresh
rather than inheriting, see the next question.
Is Podman safer for this?
Yes, meaningfully, for one specific reason: no root daemon and no socket to steal.
With Docker, anyone who can reach /var/run/docker.sock can ask the daemon to start a
privileged container with your home directory mounted; Docker's own docs treat membership of the
docker group as equivalent to root. Podman has no daemon to reach, runs rootless by
default, and on Windows and macOS it runs its Linux engine inside a VM — which means Windows users get
a hypervisor boundary for free. It shares the same kernel as Docker, so it is not a stronger boundary
once you are inside; it is a smaller attack surface to get in through.
Is rootless enough?
For accidents and most exfiltration, usually. For hostile code, no. Rootless changes what an escape gets you: container root maps to an unprivileged host UID, so a successful escape lands as a nobody rather than a root. That is a large practical improvement and it is not the same as isolation. A kernel privilege-escalation bug or a runtime CVE still gets you out of the namespace — runc alone has had CVE-2019-5736, CVE-2024-21626 and a 2025 trio of procfs mount-race escapes. Rootless also does not reduce the kernel's attack surface, only the privileges behind it.
Does a container count as "isolated"?
It counts as a namespace, not a boundary. The distinction matters because Microsoft's own servicing documentation says shared-kernel containers are not a security boundary and should not be used in hostile multi-tenant scenarios, and the UK's NCSC has said much the same for years. Your agent is not necessarily a hostile tenant — but if the agent is processing untrusted content and has network access, it is a hostile tenant's proxy. Containers reduce blast radius. They do not answer the question "what if the code inside is actively trying to leave?"
What is the practical difference between Firecracker and Docker?
Firecracker boots a separate Linux kernel per workload behind a KVM hardware boundary; Docker does not boot anything. That is the whole security difference and most of the ergonomic difference too. Firecracker has no virtio-fs, so you cannot bind-mount your repository into it — the pattern you know from Docker simply does not translate. You need to build or fetch an uncompressed kernel and materialise a rootfs image, which is why projects exist purely to publish kernel catalogues for it. Docker gives you an OCI image, a volume mount, a shell, and a store of existing answers. MicroVMs buy you a kernel boundary and charge you an afternoon of assembly.
VMs, microVMs and strength
Should coding agents run inside a VM?
If you can afford the setup, yes — it is the only boundary that does not care what the agent does. A VM gives the agent its own kernel: to get to you, code has to escape a hypervisor or abuse a shared host service you deliberately exposed. The cost is real. VMs boot, they take a gigabyte or two, file sharing across the boundary is slower than a bind mount, and your tooling has to live inside the guest. On Windows you are probably already running one — WSL2 is a real Hyper-V VM — and on macOS, Lima, UTM, Tart or Apple's container runtime give you the same thing comfortably; on Linux, Lima, Incus, UTM and Multipass do, since Lima is a VM manager on Linux hosts too. If your threat model includes hostile code, this is the answer, and the microVM chapter is about getting it with container-like economics.
Is a microVM worth the hassle?
On Linux with KVM, yes — if you need the boundary. Without KVM, it is not on the table.
The hassle is concentrated in three places: you must supply a kernel, you must supply a rootfs, and
unless you pick a VMM with virtio-fs (Cloud Hypervisor rather than Firecracker) you cannot hand it a
directory. The reward is 100–300 ms starts from a snapshot pool with a real kernel per workload. If you
are on a VPS without nested virtualisation, or on a machine without /dev/kvm, microVM
projects will simply fail to boot — that is a documented user report pattern, not an installation
mistake. Between microVMs, pick Cloud Hypervisor for features and coordinated security
response, Firecracker for the smallest device model, and treat libkrun-based runtimes
as promising but unmeasured.
What about gVisor? Is it a microVM?
No, and the correction matters because people keep repeating it. gVisor is a
user-space application kernel: your program's syscalls are intercepted and served by a Go program
rather than the real kernel, and a seccomp filter narrows what that program can ask for. There is no
hardware virtualisation and no second kernel. The upside is a very tight host attack surface, continuous
public fuzzing, and the best security posture measured in the independent study we lean on. The
downside is compatibility: io_uring is disabled by default, unimplemented syscalls return
ENOSYS, and one audit found roughly half of tested MCP servers would not start under it.
Test your actual toolchain before you commit.
Does WSL2 provide meaningful isolation?
It provides a real VM with a deliberate hole in it, and the hole is bigger than most people
assume. WSL2 runs a genuine Linux kernel in a Hyper-V utility VM, so you get memory and kernel
separation. But two features exist to make it pleasant: /mnt/c exposing your Windows drives,
and interop, which lets a Linux process launch powershell.exe. A Linux-side sandbox cannot
constrain a native Windows process spawned through interop with your full user token — a 2026 proof of
concept deleted 26.8 GB from D: from inside a bubblewrap sandbox with no approval prompt.
Codex has since masked interop sockets inside restricted filesystems. The mitigations are
interop=false, read-only or no /mnt, and a non-admin account. So: useful, real,
and not a containment claim on its own.
Is a VM overkill for a single developer?
Not if you are running with permissions bypassed, which is how most people actually run agents. The moment you stop approving commands, you have replaced a human check with nothing, and the sandbox becomes the only control left. A full VM costs you perhaps a gigabyte of RAM and a slower file path. Compare that with the cost of an agent with your SSH key rewriting your dotfiles, or of a poisoned dependency reading your cloud credentials. If you are running an agent that you watch and approve command by command, a container or even a Seatbelt profile is a defensible place to stop.
Your host machine, your files, your keys
What happens if the agent runs rm -rf?
It depends entirely on what you mounted, and this is the failure mode that actually bites people. Inside a container with a narrow bind mount, it deletes your project — annoying, recoverable from Git if you have committed. Inside a container with your home directory mounted read-write, it deletes everything your user owns, and a container will happily do it because a bind mount is a deliberate exposure. Inside a VM with no host share, it deletes the guest and you shrug. The fix is not a sandbox, it is a discipline: give the agent a copy of your project, never the original, and treat "apply changes back" as a separate, reviewed operation. See Filesystem Isolation for how to make copies nearly free.
Can the agent steal my SSH keys?
If they are readable from where it runs, yes — and it does not need to be malicious to leak them. Keys leak through log files, stack traces, test fixtures, screenshots, and any command whose output ends up in the model's context. The mitigations, in order of value: do not put the keys where the agent runs (a VM or container with a narrow mount); if it needs Git access, broker it with a scoped, short-lived credential rather than a personal key; never mount the SSH agent socket into an agent you do not fully trust, because an agent holding the socket can use every key in it; and keep an eye on the outbound path, because a key that cannot leave is a key that cannot be exfiltrated.
Can I safely let an agent access my project but nothing else?
Yes, and this is the configuration most people should be aiming for. The mechanism
differs by runtime: a bind mount of just the project directory into a container; a dedicated Unix user
whose only readable tree is the project; a Seatbelt or Landlock profile that allows one path; or a VM
with exactly one shared folder. The trap is that "the project" often contains more than people think —
.env, .git/config with a push token in the URL, .npmrc holding a
registry token, cloud credential files, SSH keys inside a submodule. Path-based allowlists are more
precise than whole-directory grants, but you still have to enumerate what is in there.
Do I need a sandbox if I use Git and have backups?
Mostly, yes — Git protects your history, not your credentials or your machine. Git does solve the worst accident cases: a worktree or a branch means a bad edit is a diff you discard, and that is cheap and worth doing. But an agent with your user's privileges can read your keys, POST your source to somewhere, rewrite your remotes, install a persistence hook, or delete the backup along with the original. Backups help when you notice. Sandboxes help by making the blast radius smaller than "everything this account can reach".
Should I run the agent as a separate OS user?
It is the cheapest meaningful separation available and it is genuinely underrated. A dedicated unprivileged account with its own home, no access to your keys, and ACLs granting write access to exactly one work tree gets you most of Tier 1 and a chunk of Tier 2 for about ten minutes of work. The caveat is that users share the kernel and installed software: a local root exploit defeats it, and anything world-readable is still readable. Tools like SandVault and the "dedicated user" pattern documented in the AI-sandbox dataset are built on exactly this, and their authors use them daily because the setup cost is close to zero.
Network, secrets and the outside world
Can I let an agent use APIs without it ever seeing the API key?
Yes, and this is the single highest-value change you can make this week. The pattern has several names — phantom tokens, credential brokering, host-side injection — and it works like this: the agent's environment contains a placeholder or a local proxy URL, and a trusted proxy outside the sandbox strips that placeholder and substitutes the real credential on the way to the API. The agent can read its own environment all day and learn nothing. nono popularised it with an excellent implementation, Infisical's Agent Vault is a maintained product, and you can build a serviceable version with mitmproxy in an afternoon. Read the Secrets chapter before you build it yourself — there are two failure modes that matter.
Should the agent have internet access?
Usually yes, but only to an allowlist you wrote, and only through something that fails closed. No network at all is the strongest configuration and it breaks package installs, documentation lookup and half of your toolchain. Open network is what most setups actually do, and it is what turns a prompt-injection bug into an exfiltration incident. The middle path is an allowlist: your model provider, your Git host, your package registries, nothing else. Two things to remember: domain allowlists are content-blind, so an allowed host can still be an exfiltration channel, and an allowlist is not a trust boundary — a real incident had an agent escape through a package proxy that had been explicitly allowlisted. Keep DNS and metadata endpoints (169.254.169.254) blocked.
Do all tools respect a proxy?
No, and this is the most common way a network policy silently does nothing. HTTP
proxy environment variables are a convention, not an enforcement mechanism. Node.js ignored
HTTP_PROXY until version 24 unless you set NODE_USE_ENV_PROXY; raw sockets
bypass environment variables entirely; and any tool that falls back to a direct connection when the
proxy is unreachable turns your policy into decoration. Enforce at the kernel where you can — a network
namespace with no route except through a proxy, or a TUN device that captures everything — and test the
fail-closed path deliberately by killing the proxy and watching what the agent does.
Can I just block dangerous commands instead?
Blocklists are the weakest control in the guide and the agent will reason around them.
There is a well-documented pattern of agents finding /proc/self/root/usr/bin/npx to evade a
path block, or simply disabling their own sandbox because they want to finish the task. A review of 39
papers on agent isolation found policy failure rates of 69–98% against real denylists. If you want
command-level control, make it an allowlist of the commands you actually need, keep it deterministic,
and never treat it as a boundary — treat it as a speed bump in front of one.
Are MCP servers part of the sandbox?
Usually not, and that is a hole people forget. MCP servers frequently run on the host, outside whatever boundary you built for the agent, with the host's credentials. Docker Sandboxes' own documentation places the MCP gateway outside the microVM. Every server you add is a capability grant: a filesystem server is a filesystem grant, a shell server is a shell grant, and a server that fetches URLs is a network grant. Audit the list the way you would audit a firewall, and prefer running them inside the sandbox where you can.
GUI, browser and computer use
Can I sandbox GUI programs?
Yes, and there are three sane routes. On Linux, run the application inside a container or VM and forward the display (X11 or Wayland over the boundary, or a VNC/RDP session streamed to your browser). On Windows, WSLg does this beautifully for Linux GUI apps — they appear as normal Windows windows with a VM behind them — and Windows Sandbox gives you a disposable desktop when you need a Windows guest. On macOS, the practical answer is a VM (UTM, Tart, Lume) with screen sharing, because Apple's own App Sandbox cannot confine arbitrary CLI processes at runtime. What you should not do is give a desktop agent a screen attached to your real session and hope the tool sandboxes it.
Is a browser agent more dangerous than a terminal agent?
Yes — the attack surface is larger and it is written by strangers. A terminal agent reads files you chose; a browser agent reads whatever the internet serves it, in a format designed to be interpreted. The published evidence is sobering: computer-use agents hit attack success rates in the tens of percent on realistic adversarial tasks, and a visual prompt injection can be invisible to a human looking at the same screenshot. Browser-use shipped a critical domain-allowlist bypass (a URL userinfo trick) that defeated its only native domain restriction. Put browser agents in a VM with no real credentials, no real session, and a human-visible stream.
The ecosystem question
Why are there suddenly hundreds of agent sandbox projects?
Because the problem is easy to do badly and there is no standard that fits everyone. The most quoted line in the field is that this is like everyone rolling their own auth in 2010 — simple enough to DIY in a weekend, complex enough that no single design suits every workload, and there is no "OAuth for syscalls" yet. Agent companies are also absorbing the primitive: Codex and Claude Code now ship sandboxes, Docker and Cloudflare shipped their own, Google shipped an agent sandbox for Kubernetes. So the wrappers are partly a gold rush and partly a waiting room. Expect most of them to be absorbed, abandoned or archived, and expect the underlying runtimes — containers, microVMs, gVisor — to still be here.
Which repos are actually mature?
A short list, and most of them predate AI agents entirely. Podman and Docker for containers; bubblewrap, minijail and nsjail for process isolation; QEMU/KVM, Incus, Lima, UTM, Multipass and Tart for VMs; Firecracker, Cloud Hypervisor, crosvm and Kata for microVMs; gVisor for application kernels; Wasmtime for WASM; mitmproxy, Vault and SOPS for the credential story. The agent-specific projects that come closest are the ones with either a large company behind them (Docker Sandboxes, gVisor, mxc) or a hardened, reviewed template (Trail of Bits' devcontainer). See Recommended Repositories.
Which ones should I stop trying to install?
Anything with a single author, a hundred stars, no release, and a README that is longer than its test suite. The specific patterns are easy to spot once you know them: last commit measured in months with a starred count in the hundreds; "very early" language in the README; a licence that blocks reuse in the products that use it (GPL desktop wrappers); no releases at all; a microVM wrapper on a machine without KVM; and a security section that describes intent rather than enforcement. Skip for Now names names and explains each one, but the method is more useful than the list: check the commit date, the release count, the maintainer count and the issue-to-user ratio before you spend an evening.