Coding Agent Sandboxes: Docker vs Brig MicroVM

TL;DR

• Docker Sandboxes are MicroVMs with their own kernel, not containers, despite the Docker name.
• Brig keeps its credential file on memory-backed tmpfs, so the secret never reaches host disk while an agent runs.
• Clawk releases idle VM memory after 30 minutes, making disposable agents cheap enough to run per-ticket.

A coding agent that can edit files, push commits, and execute shell commands is a privilege escalation waiting to happen. Hand it your host credentials and a prompt injection turns into a key leak. The fix is not a bigger LLM, it is a boundary. Three MicroVM tools now compete for that boundary: Docker Sandboxes, Brig, and Clawk, with host-based sandboxes that scope the agent through the operating system’s own entitlements as the weaker contrast. Most teams pick wrong because they treat isolation strength as a single knob, which it is not. The real question is whether any shared kernel is acceptable, and the answer decides which path actually gives your agent a genuine separate kernel [1][2][3].

Why Shared-Kernel Isolation Fails Coding Agents

In our assessment, containers solved packaging, not hard isolation: a container shares the host kernel, so a kernel-level bug can reach the host directly. For a coding agent that interoperates with arbitrary tool output, that shared plane is where the risk concentrates.

The failure mode is concrete: the agent reads a file; the file contains hostile instructions (a pattern covered in persistent state attacks on coding agents ); and now you have execution of attacker-controlled text inside a process that shares your kernel. Even with seccomp and namespace filtering, isolation stays a filter over one kernel rather than a second kernel.

Host-based sandboxes share the same flaw from a different angle. They can restrict files, network, and process spawning, but the agent still runs as a normal process on the host kernel, so a bug in enforcement is a direct path to your home directory.

That single fact pushed the field toward MicroVMs — a MicroVM gives the guest its own kernel, so a crash or compromise stays inside the boundary; the guest cannot reach anything you did not map in, because no shared kernel carries the pointer. The three tools below all give the guest its own kernel and differ mainly in credential handling and lifecycle.

Three MicroVM Sandboxes, Side by Side

Adoption is easy to measure and says little about the security model underneath: as of 2026-10-17 Brig had roughly 230 GitHub stars and Clawk roughly 1,000 [2][3]. A popular project can still ship a weak model and a niche one can be airtight.

Docker Sandboxes wrap a MicroVM in a managed workflow. Brig runs the agent inside Apple’s Virtualization.framework on macOS, where the guest gets a dedicated kernel with no container shim between it and the hypervisor. On Linux, Brig drives nerdctl and hands the container to the urunc shim, so the path differs there [4]. Clawk uses the same Virtualization.framework to spin up disposable Linux VMs: root access inside the guest, host files and keys kept outside [3].

The telling difference is what each treats as its trust boundary: Brig and Clawk lean on a hypervisor as the hard line. Docker Sandboxes starts from the same MicroVM base but keeps the local product free and standalone, while the optional Cloud Sandboxes and the organization-level policy controls come as add-ons on top [1].

Platform support is the first real filter. Brig targets macOS 15+ on Apple silicon (macOS 14 works with BRIG_HYPERVISOR=vz and BRIG_NETWORK=shared) and Linux x86-64/arm64 [2]. Clawk is narrower, requiring macOS 14+ on Apple silicon with Linux still experimental via Firecracker [3]. Docker Sandboxes, by contrast, runs its VMM natively across macOS, Windows, and Linux [1].

Where Credentials Actually Land: The Boundary That Matters

Kernel isolation is necessary but not sufficient: the second-order risk is credential handling, and here the three tools diverge sharply.

Brig’s model is the strictest: the guest cannot reach the host keychain, SSH agent, secret manager, or any directory outside explicitly mounted paths. Credentials must be delivered on purpose, and when they are, the files land on memory-backed tmpfs mounts that never touch host disk while the agent runs [4] — wipe the VM and the secret is gone.

Clawk keeps host files and keys isolated by default and forwards the SSH agent only for git operations, paired with network allow-listing that blocks connections to unknown servers [3]. Docker Sandboxes leans on the VM boundary itself and offers organization-level AI Governance for teams that want central control, though its product page does not detail credential or network handling [1].

Idle Agents: The Cost of Leaving a VM Running

Disposable VMs only make sense if they are cheap to stand up and tear down. Clawk handles this explicitly: idle VMs release their memory and stop after 30 idle minutes, so an abandoned agent does not quietly burn RAM [3]. Suspending a VM to disk is a manual step today (the clawk snapshot command), with automatic idle snapshot still on the roadmap.

That distinction matters operationally: memory release is automatic and safe; disk suspension is still a deliberate action. If you batch many short agent runs, expect the memory savings immediately but plan your own snapshot cadence until the roadmap lands [3].

Brig’s model is local only, which sidesteps cloud costs but shifts lifecycle management onto you. Docker Sandboxes offers Cloud Sandboxes for detached runs on Docker-managed infrastructure, moving both cost and cleanup off your machine [1].

The tradeoff is not purely cost: a local VM means your secrets never leave your machine; a cloud sandbox means an interrupted run survives your laptop closing. Teams that want unattended, long-running agents may lean toward the cloud option for that reason; shops that prioritize data locality stay local. Neither is wrong. The deciding variable is how your agents behave when nobody is watching.

Choosing a Coding Agent Sandbox for Production

The decision table below maps each path to the three criteria that actually separate them in production: kernel boundary strength, credential lifecycle, and operational footprint.

The trap is equating the Docker brand with container isolation: Sandboxes run a MicroVM under the hood, and that kernel separation (not the branding) is what keeps a prompt injection from becoming a host compromise [1].

Do not over-engineer for a threat model you do not have: if your agents only read a fixed set of repositories and never touch production credentials, a well-scoped host sandbox may be enough. The moment your agent can run arbitrary shell or pull third-party tool output, the shared kernel becomes the wrong risk to accept.

Performance deserves a measurement on your own workload. Docker describes its cold starts as fast enough that there is no reason not to sandbox [1], but we did not find a boot-time comparison across the three tools, so benchmark the loop you actually run. Every extra mount is also a surface you have to audit later.

Start from a concrete job, not a global policy. Consider two teams: one running agent-driven code review wants the strongest credential boundary and tolerates a slightly slower first boot; another running hundreds of short exploration runs cares about teardown speed and idle memory above all. Those two teams reach different tools from the same table.

Practical Takeaways

1. Pick Brig when credential isolation is the hard requirement: its tmpfs-backed secrets never touch host disk [4].
2. Choose Docker Sandboxes when you need organization governance options and cloud portability across macOS, Windows, and Linux [1].
3. Use Clawk for per-ticket disposable VMs, and rely on its 30-minute idle memory release to keep abandoned agents from leaking RAM [3].
4. Treat any shared-kernel setup (containers, host entitlements) as a filter, not a boundary, and reserve MicroVMs for workloads that run untrusted code.

Conclusion

Skip containers for any agent that can execute shell, because a shared kernel is the risk to design out rather than filter. Brig, Clawk, and Docker Sandboxes all close the hole with a separate kernel, and what remains between them is operational rather than fundamental. The genuinely open question is whether MicroVM primitives become a commodity every platform adopts, at which point the differentiator shifts to credential lifecycle and idle efficiency. Ship the boundary first, then pick the lifecycle that matches how long your agents actually run.

Frequently Asked Questions

Are Docker Sandboxes containers or virtual machines?

They are MicroVM environments with their own kernel, not containers. Docker’s product page states this explicitly, so do not assume container semantics or host-kernel sharing [1].

Does Brig forward my SSH keys automatically?

No. Brig’s guest cannot reach the host keychain, SSH agent, secret manager, or any directory outside explicitly mounted paths. Credentials must be delivered on purpose, and when they are, they land on memory-backed tmpfs mounts that never touch host disk while the agent runs. That design is intentional rather than a missing feature, because a compromised agent holds only the secrets you chose to hand it and nothing more. It also keeps the blast radius small, since a leaked key cannot cascade into the host keychain or unrelated repositories. Deliver a key only when the task genuinely needs git or SSH access, and prefer short-lived tokens over long-lived ones [4].

Does Clawk suspend idle VMs to disk automatically?

Not yet. Idle VMs release memory and stop after 30 idle minutes automatically, but suspending to disk is a manual clawk snapshot step, with automatic idle snapshot on the roadmap [3].

Can I run these on an Intel Mac?

No. Brig’s support table lists Intel Macs as unsupported, and Clawk requires Apple silicon [2][3]. The platform table above has the exact requirements.

Sources

Image Credits

• Cover photo: Image generated with gpt-5.4-image-2 (Agents’ Codex AI illustration)
• Figure 1: Image generated with gpt-5.4-image-2 (Agents’ Codex AI illustration)