Firecracker reports 125 ms startup for microVMs; learn filesystem isolation patterns, threat models, and metrics for AI coding agents. Full breakdown.
Why Filesystem Isolation Matters for Coding Agents
When an AI coding agent runs in a hosted environment, it does more than generate text — it writes files, installs packages, and executes commands. Each of those actions touches a filesystem, and that filesystem is the boundary between the agent's work and everything else on the host. If the boundary is weak, a prompt-injected or simply mistaken agent can read secrets from adjacent tenants, overwrite shared tooling, or leave state behind that poisons the next session.
The goal is to give the agent a filesystem that feels complete and writable while keeping its reach contained. The agent should be able to clone a repo, build it, and run tests without ever seeing another user's data or the control plane that schedules its work.
Isolation Patterns
Different runtimes trade startup speed against blast radius. MicroVMs put a hardware virtualization boundary around each session; Firecracker reports 125 ms startup, which makes per-request VMs practical rather than a batch-only luxury. Containers share the host kernel and start faster still, but the shared kernel is a larger attack surface, so container-based sandboxes lean on user namespaces, seccomp, and read-only mounts to compensate.
- Copy-on-write base images: ship a read-only root filesystem and layer a writable overlay per session, so the agent's changes are isolated and cheap to discard.
- Ephemeral scratch: mount a tmpfs or per-session volume for working state, then destroy it on teardown so nothing survives across agents.
- Scoped mounts: expose only the target repository and its dependencies, keeping host paths, credentials, and sibling workspaces off the mount table entirely.
Threat Models to Design Against
Assume the agent is capable and occasionally adversarial, whether because a repository contains a hostile README or because model output steers it somewhere unintended. The realistic threats are lateral movement between tenants, exfiltration of build secrets and tokens, and persistence — an agent writing to a location that a later session will read and execute.
Defenses follow from those threats: isolate each session so there is no shared writable surface, inject secrets narrowly and revoke them at teardown, and treat every filesystem as disposable. Egress controls matter too, since a contained filesystem does little good if the agent can still POST its contents to an external endpoint.
Metrics That Tell You It Is Working
Isolation is only useful if it is fast enough to run for real workloads, so track startup latency — cold and warm — as your primary cost signal, because it decides whether you can afford a fresh sandbox per request or must pool them. Teardown time and the reliability of that teardown matter just as much: a sandbox that fails to reset is a sandbox that leaks state.
Pair the performance numbers with correctness checks. Verify that each session starts from a known-clean base, that scratch space is empty on boot, and that no mount reaches beyond the intended repository. Watching these together keeps you honest about the central tradeoff — the strongest boundary is worthless if it is too slow to use, and the fastest sandbox is dangerous if it does not fully reset.