The Snapshot Is the Audit Trail

The question is not where an AI agent should run. The question is where any program should run. All of these execute code you did not write, against a machine that has access to things you care about:

• A browser tab
• An editor plugin
• A build script
• A CLI tool you just installed
• A dependency that arrived three levels deep in a package tree

The AI agent is the most recent and most dramatic version of a problem that has existed as long as software has been shareable.

The agent did not invent the threat. It just runs more code you did not write, faster, with less supervision.

The conventional answer has been process isolation, user permissions, and containers. All of these are partial. A container shares the host kernel; kernel exploits escape it. A process running as non-root can still read files the user owns, exfiltrate credentials from environment variables, or make network calls anywhere it wants. A browser tab with a JavaScript exploit can reach anything the browser process can reach, which is typically the user's entire session. The isolation is better than nothing and worse than it looks.

The microVM is a different answer. Firecracker, the virtual machine monitor AWS built to run Lambda and Fargate, boots a minimal Linux guest in under 125 milliseconds with a memory footprint measured in megabytes. Cloud Hypervisor, QEMU, and Kata Containers cover different points in the tradeoff space. The hardware boundary is real: a separate kernel, hardware-enforced memory isolation, no shared kernel surface to exploit. What runs inside cannot reach what runs outside except through explicitly configured channels.

Everything Is a Candidate

Any software that runs code you did not author is a candidate for sandbox execution. The list is longer than most people keep in mind.

Browsers

Every website you visit executes JavaScript in your browser process, with access to your cookies, local storage, clipboard, and whatever APIs the browser exposes. Browser vendors spend enormous effort on sandboxing renderer processes, and exploits still land regularly. Running the browser itself inside a microVM means a successful exploit reaches the guest, not the host. Your SSH keys, your password manager, your other open applications: structurally unreachable.

Editors and plugins

VS Code executes extension code with the same privileges as the editor process, which typically has access to your entire home directory, your git credentials, your environment variables, and your terminal. The VS Code marketplace has had repeated supply chain incidents. An editor running in a microVM with a mounted project directory and explicit network policy is a meaningfully different security posture than an editor running natively with ambient access to everything.

Package installs and build steps

npm install, pip install, cargo build: all of these execute lifecycle scripts, build scripts, and procedural macros that can do anything the process is allowed to do. Supply chain attacks via malicious packages are a standard threat model. Running installs inside a microVM scoped to the project directory means a malicious package can exfiltrate the project files but not your SSH keys, your AWS credentials, or your other projects.

A CI build step, a Makefile target, a downloaded binary you ran once to try: same pattern. Code you did not write, executing with the trust level of whatever process runs it, which is usually too high.

The Isolation Argument

The kernel boundary is what makes microVM isolation qualitatively different from container isolation.

• Container escape requires finding a vulnerability in the kernel interface the container runtime exposes: a real but bounded attack surface.
• MicroVM escape requires finding a vulnerability in the hypervisor itself: a much smaller, more audited, more formally verified codebase.

Firecracker's attack surface is intentionally minimal: no device emulation beyond what is strictly necessary, no legacy hardware support, no complex BIOS.

Ephemerality is the other property that matters. When a run ends, the VM is discarded. The next run starts from a clean snapshot. Persistence is opt-in: you choose what state survives across runs, rather than having everything persist by default and trying to clean up what should not have. Instead of asking "did I remember to clean up the sensitive data," you ask "did I explicitly decide to keep this."

The Snapshot Argument

Snapshots are what turn microVM sandboxes from a better security posture into a genuinely different observability primitive.

A log tells you what the software said it did. A snapshot tells you what it actually did, in a form you can load, inspect, and replay.

A snapshot captures the complete filesystem state, process tree, network state, and memory contents at any point in the run, as a point-in-time image. If something went wrong, you do not reconstruct the sequence from log entries. You restore the snapshot and look at the machine as it was at the moment of interest.

A log is a narration. A snapshot is the scene. You can diff two snapshots to see exactly what changed between any two points. You can restore to any checkpoint and rerun from there with different inputs. You can hand a snapshot to someone who was not present for the original run and they can inspect it independently, without trusting your account of what happened and without needing the original environment to still exist.

Copy-on-write filesystems like ZFS make this cheap. Each snapshot shares unchanged blocks with its parent. A run that touches a small fraction of the total filesystem costs almost nothing in additional storage. Keeping every snapshot from every run for months is practical at current storage costs. The constraint is not storage. The constraint is having built the tooling to take snapshots routinely rather than treating them as a special forensic measure.

The Fork Argument

Forking a running VM state means taking an exact copy of a machine mid-run and diverging from that point. Two identical environments from the same starting state, each able to take a different path.

For demos and bug reproductions: share a running session link and the recipient gets the exact same environment, the same running processes, the same filesystem state. No setup instructions. No "works on my machine." The context is the fork.

For experiments: fork at any decision point and vary a single factor: a different configuration, a different version of a dependency, a different network policy, a different set of permissions. You get a branching tree of runs, each traceable back to the exact state it diverged from. You can compare outcomes across branches against an identical starting point, which is a kind of experiment design that is otherwise very hard to achieve reliably.

For AI agents specifically: forking makes counterfactual tracing practical rather than theoretical. You can answer "what would the agent have done with restricted access at this point" not as a reconstruction from logs but as an actual parallel run you can compare against the original branch.

The Lineage Argument

Every snapshot has a parent. The tree of snapshots from a run, including its forks and their forks, is a directed graph with a known root. That graph is the complete lineage of every state any process in the sandbox ever occupied.

This is a provenance record implemented at the infrastructure layer rather than the application layer. The lineage exists:

• regardless of what the software says about itself
• regardless of whether the application log was tampered with
• regardless of whether anyone thought to enable auditing before the run started

The snapshot tree is a fact about the storage system, not a claim made by the software running inside it.

iximiuz Labs runs playground VMs on this model: instant start, full SSH access, snapshot persistence across sessions, fork-on-demand, shareable running session links. opencomputer.dev is working toward the same primitive at a million-sandbox scale. The hard parts at the component level (fast VM boot, efficient copy-on-write snapshot storage, live fork of running state) are solved. What is being built is the coherent platform layer on top of them.

The Default That Is Missing

None of this requires new research. The components exist, are open source, and are production-proven at scale. What is missing is the default.

Most software today runs with ambient access to the user's environment: the home directory, the network, the credentials in environment variables, the other processes. This is the default because it is convenient and because the cost of the alternative used to be prohibitive. A VM that takes minutes to boot and gigabytes to store is not a practical default for running a CLI tool. A VM that boots in 125 milliseconds and shares unchanged filesystem blocks with its parent snapshot is a different calculation.

Qubes OS made compartmentalization the entire security model of a desktop operating system: every application domain runs in a separate VM, and moving data between domains is an explicit act. It is the right idea and the wrong ergonomics for most people. The direction that microVM tooling is moving is the same security model with ergonomics that do not require the user to restructure how they think about their computer.

The microVM sandbox should be the default execution environment for anything that runs code you did not write, in the same way that HTTPS became the default for any connection carrying real data. Not because every case requires it, but because the cost of the protection is now low enough and the cost of the absence is high enough that running without it is the choice that needs to be justified, not the other way around.

When boot is 125 milliseconds and storage is shared blocks, running unsandboxed stops being the convenient default and starts being the thing you have to defend.