Agent code has become the riskiest code most teams run. Agents now write software, install packages and execute it on their own, and a model that reads an untrusted page or file can be steered by prompt injection into running commands outside its task. Where that code runs decides how much damage one bad instruction can do.
That is why the microVM has become the default home for agent code. A microVM sandbox for agents is a small virtual machine with its own kernel, started by API, so whatever the agent runs stays behind a hardware boundary and never touches your host or another agent. This guide covers why agents need one, how it differs from a container, the jobs to run in it and what Solari does for you.
Why Do AI Agents Need a MicroVM Sandbox?
Agents need a microVM because their code is untrusted by design. A coding agent pulls dependencies, runs scripts it wrote a minute ago and executes tests, and any of that can be shaped by text it read along the way. The safe assumption is that some of it will eventually be hostile.
The old answer was a permission prompt before every command, and it does not scale. Anthropic found that constant approvals can lead to approval fatigue, and moved Claude Code to sandboxing with filesystem and network boundaries instead. The agent works freely inside the boundary, and the boundary does the protecting.
Teams running agents for their own customers need that boundary between tenants too. One customer's agent should never read another's files, see its processes or reach its network. That requirement moves agent code off shared servers and into one virtual machine per task.
How Is a MicroVM Different From a Container?
A microVM gives each sandbox its own kernel; a container shares the host's. Containers isolate programs with Linux namespaces and cgroups, which is light and fast, but every container on a host talks to the same kernel, so one kernel flaw is a way out for all of them.
A microVM runs on a hypervisor such as KVM, with a slim virtual machine monitor in front of it. AWS built Firecracker to get strong virtual machine security with minimal overhead for Lambda and Fargate, and Cloud Hypervisor follows the same idea with minimal emulated devices written in Rust. The guest gets a whole machine; the host exposes very little to it.
The old trade-off was start time. A full virtual machine took long enough to boot that teams settled for containers. Snapshots changed that: a microVM started from a prepared snapshot opens straight into its saved state, so an agent gets virtual machine isolation without waiting for a boot.
What Can You Run in a MicroVM Sandbox?
Anything an agent would otherwise run on a developer's laptop or a shared build server. These are the jobs teams move into microVM sandboxes first:
Coding agents. The agent clones a repository, installs dependencies, edits files and runs the test suite on a machine of its own. A broken build or a runaway script ends with that sandbox, not on your CI runners.
Code interpreters. A data agent runs Python it just wrote against an uploaded file and returns the result with its charts. The interpreter keeps variables between calls, so the agent works step by step the way a person works in a notebook.
Untrusted packages and repos. An agent can install an unknown dependency or run a stranger's repo with all outbound network blocked. Whatever the code tries to do, it has nowhere to send your data.
Parallel attempts. An agent prepares a machine once, then starts many copies of it to try different fixes side by side. The best attempt wins and the rest are thrown away.
Long-running tasks. An agent that waits on a model, a tool call or a person can pause its machine and pick up later exactly where it stopped. A paused machine does not count against your limit on running machines.
Computer-use agents. Models with computer use operate software through a screen, which needs a full desktop rather than a shell. The same rule applies: one agent, one machine.
What Role Does Solari Play?
Solari runs sandboxes, desktops and cloud browsers from one API, and every sandbox gets its own microVM by default. Your agent brings the model and the logic; Solari gives it an isolated machine to work in.
A machine of its own. A Solari sandbox runs on Cloud Hypervisor with a dedicated kernel per session behind hardware virtualization. You never share a VM with another organization, so another company's agent cannot reach yours.
No network when you want none. Set isolation to hardened and the sandbox runs with all outbound network blocked, for code you do not trust at all. For light jobs, a cheaper shared tier runs your sandbox as a process tree inside a VM shared only with your own sandboxes.
A fresh machine per task. With Solari you can run up to 100,000 sandboxes at once, each one started clean from a template or a snapshot. Your agent gets its own machine for every task instead of reusing a dirty one.
Snapshot, revert and fork. A Solari snapshot saves a running machine's disk and memory while it keeps working. Revert rewinds the same machine for a clean test run, and new machines started from a snapshot give you as many ready-to-go copies as the job needs.
Pause without losing work. Pause saves memory and running processes, and resume brings the sandbox back exactly as it was. A stopped sandbox keeps its files but not its running state, so pause is the choice for an agent that will come back.
Credentials that do not stay behind. Solari's git commands pass a token to one command only, never into the URL, the git config or the process arguments. Your agent can push a branch without leaving a key on the machine.
Some agents need a screen as well as a shell. Solari desktops are full Linux computers with a live view on the same lifecycle, and Solari cloud browsers let the same agent work on the web, all on one account and one bill. Solari is also about 1.3x faster than E2B on a sandbox's full lifecycle and almost 3x cheaper per sandbox hour.
Where Are Agent Sandboxes Going Next?
Today most teams give an agent one sandbox for one task. Over the next year that changes in four ways:
A machine per agent, by default. Running agent code on a shared server will look the way running a website as root looks today. Every agent, and every customer's agent, will get its own kernel.
Sandboxes that last. Agents that run for hours or days will keep the same machine, pausing between steps and checkpointing as they go. Rebuilding the environment on every run will disappear.
Forking as a way to work. Agents will branch a machine at a decision point, try several paths at once and keep the one that works. It is the git branch applied to a whole computer.
Code, browser and screen together. One task will span a sandbox for code, a browser for the web and a desktop for apps with no API. Teams will want all three under one identity and one audit trail.
What stays human is the trust decision: which code may run, which networks an agent may reach and which results ship under your name. The microVM keeps mistakes contained; people decide what leaves the box.
Get Started With Solari
Start with one job, such as running untrusted repos in a hardened sandbox, then fork that setup across your agent's tasks once it runs cleanly. Older sandbox vendors carry the larger ecosystems; Solari is the younger company and moves faster on speed and price. Solari is the fastest and cheapest way to run cloud browsers and VMs for coding and code-execution agents. Get started with a free account and start running your agents today.
