Choosing your rung

You now have the whole map: the shared/own-kernel fault line, the five features a container is made of, the escape that shows what they cost when one is missing, and the two walls a serious microVM stands behind. This chapter turns that into decisions. Four rules, in order.

Rule 1, match the tier to the threat

Read the ladder above against a single question: how much do you trust the code? Over-isolating trusted code buys friction for nothing; under-isolating hostile code is false comfort, which is worse.

For code you trust, your own project, your own dependencies, an agent you are actively supervising, a dev container is the right tier. You want reproducibility and resource limits there. For code you do not trust, an autonomous agent running code it wrote, an untrusted dependency, anything you would not run on your laptop bare, you want a microVM and its hardware boundary. On macOS that is Apple container; on Linux, Podman + krun if you want a microVM from the familiar container CLI, or Incus if you want a full VM with a one-flag upgrade path from a container (incus launch --vm). The tier follows the threat.

One note about the top of the ladder: there is no rung called "secure." A microVM's hardware boundary is enforced by KVM, which is kernel code; its devices are emulated by a VMM, which is userspace code parsing hostile input; the CPU underneath has had boundary-crossing bugs of its own. Every tier buys a reduction in attack surface and nothing stronger. The gradations are real, a kernel bug reachable from any process is a far wider door than a bug reachable only through a device backend, but gradations are what they are. The useful question is "secure against what, at what cost."

Rule 2, the mount is a hole you cut in the boundary

You can pick a perfect boundary and then hand the code your whole life through a bind mount. A mounted host directory is a hole you deliberately cut in the wall, and everything reachable through it is exposed no matter how strong the wall is. Treat the mount as a spectrum and cut the hole as small as the work allows:

• Full host mount ($HOME or a big tree), maximum blast radius; a single escape-via-mount reaches everything.
• Scoped mount, only the project directory, read-write.
• Read-only mount, the sandbox reads your files but cannot modify them.
• No mount + remote editing, the files live in the sandbox; your editor reaches in over a protocol.
• No mount + in-VM editor, vim/neovim inside the box; nothing shared. The safest end.

Most people believe the first and last are the only options, desktop editor with the project bind-mounted, or a terminal editor and no comforts. That is a false binary. Remote editing breaks it: VS Code Remote-SSH and JetBrains Gateway put the editor UI on your host and the editor backend inside the sandbox, with no bind mount at all. You get your real desktop editor and the files never leave the box. You do not have to choose between ergonomics and safety.

And whatever you mount, never mount $HOME, ~/.ssh, or ~/.aws. Dragging your keys and cloud credentials into a sandbox turns any escape-via-mount, or any prompt-injected agent, into full credential theft. The isolation was supposed to protect those secrets; mounting them in defeats the entire point.

Rule 3, an isolated box with open network still leaks

The last hole is the network. A perfectly isolated box with an open network connection can still exfiltrate everything it can read, your code, any mounted secret, the contents of its own environment, the first time it is prompt-injected or runs a malicious dependency. Isolation contains the blast; egress is how the blast gets out.

For anything untrusted, run default-deny egress with an allowlist: block everything, then open only your package registries and the specific APIs the work needs. And block the cloud metadata endpoint 169.254.169.254, an SSRF or a curious agent that reaches it can read your cloud instance's credentials, which is the same credential-theft outcome as mounting ~/.aws, delivered over the wire.

Rule 4, keep the keys out of the blast radius

Notice what every rule so far is really protecting: your credentials. The realistic failure with an AI agent is a prompt-injected agent reading your API keys, tokens, and cloud credentials and posting them somewhere; kernel escapes are the rare case. So the strongest move is to make sure the code never holds the secret in the first place.

The pattern is credential brokering: a trusted proxy holds your secrets and injects them into outbound requests at the egress boundary, only for allowlisted destinations. The sandboxed code only ever sees a placeholder, so even a fully compromised agent has nothing to steal. You have seen this shape before, 1Password op run, service-mesh sidecars, LLM gateways that hold the provider key; it is the same idea aimed at your dev sandbox.

Most tools do not do this, your secrets sit in the environment where any code can read them, which is why default-deny egress matters so much as a backstop. But a few bake it in: microsandbox interpolates secrets into requests at its proxy so the guest can never read them, reducing theft to defeating the proxy's upstream TLS verification. Modal has a managed secrets store that injects credentials for you, though code in the box can still read them once injected. Others, like E2B, just forward plain environment variables, which their own docs note are not private inside the sandbox. When you can choose it, brokered beats managed beats exposed.

Where to go next

Those four rules, match the tier, shrink the mount, lock the egress, keep the keys out of reach, are the whole job. To put a name to the tools, browse the dictionary by isolation tier. And to see how the real coding agents answer these questions, what boundary each one runs behind, and what its egress default actually is, the agents pages lay them out side by side.

One thing this chapter deliberately left out: picking the right rung tells you nothing about whether the rung is maintained. The next chapter is about the build you are actually running, and the questions to ask a vendor before you trust one.