The support agent was asked to tidy a customer's spreadsheet, and partway through it decided a missing library would help. It wrote an install command for a package nobody had vetted and queued it to run. The engineer watching the logs had a few seconds to decide where that command should land.
The answer is never the machine that holds production keys. Untrusted agent code, meaning anything a model wrote, downloaded or was told to run by a page it read, belongs on a separate machine with no secrets, a closed network and a reset button. Solari provides that machine as an AI sandbox, a microVM created by API from the same account as its cloud browsers and desktops. This guide walks through the controls that make a sandbox a real boundary, in the order to set them.
Why Agent Code Counts as Untrusted
Before any setting, it helps to be clear about the threat. A model does not have to be malicious to run harmful code: it can write a careless cleanup script, or read a web page carrying planted instructions, the pattern OWASP describes as prompt injection. Either way, the command runs with whatever access the machine under it has.
That is why isolation follows the principle of least privilege: the code gets what its job needs and nothing else. A sandbox is where the machine enforces that rule instead of the model's good behaviour.
Least privilege starts with the wall around the code, so the boundary is the first choice.
Pick the Boundary Before the Code Runs
Every control in this guide maps to a setting on the sandbox, and the table below lists them in the order they come up.
The boundary is set with the isolation field at create time, and the sandboxes docs describe each tier. The default, dedicated, is a microVM of its own, so the code runs on its own kernel behind a hypervisor. Shared is cheaper, but it separates sandboxes with namespaces and a cgroup inside a VM shared with the organization's other shared sandboxes.
For code nobody has reviewed, dedicated is the floor. A strong wall still leaves a door open, and that door is the network.
Cut the Network and Keep Secrets Out
Most damage from untrusted code travels outward, so the next control is egress. The hardened tier is a dedicated microVM with all outbound network blocked: the code can compute and write files, but it cannot send anything off the machine. Volumes are refused on hardened for the same reason, since a volume is network storage.
A closed network also means the agent cannot install packages at run time. The answer is to bake dependencies into a custom template on a paid plan, so the unreviewed code meets a ready machine with nothing to download.
Secrets are the other half. Nothing sensitive should sit in the sandbox's environment or files; when an agent must push to a repository, the git helper passes the token to that single command, never in the URL or the config. The sandbox id itself is a credential: whoever holds it, or its control URLs, can run commands as root in that sandbox, so keep it out of logs, tickets and client code.
With the network closed and the secrets out, what remains is how much of the machine the code may use.
Cap What the Code Can Consume
Untrusted code can also do harm through sheer appetite: an endless loop or a script that fills memory. A dedicated sandbox takes cpu from 1 to 8 and memMb up to 16 GB at create time, and a request above those limits is rejected with a 400 instead of being quietly reduced.
Time is capped per command. timeoutMs sets a deadline, and a command that hits it does not throw: it returns with exitCode: -1 and timedOut set to true. Agent loops that read only the exit code miss this, so check the flag before trusting a result. Caps contain a bad run; the last control erases it.
Reset or Throw Away the Machine
A sandbox that ran untrusted code should not carry that run's leftovers into the next job. The snapshots docs describe the pattern: snapshot the clean machine, run the code, then revert() to rewind the same sandbox id. A revert boots a fresh VM from the snapshot and swaps it in, so nothing the code changed survives.
The rule that trips people up is order. Both snapshot() and revert() need a running machine and return 409 NotRunning on a paused one, so resume first. When the job is finished, kill() removes the machine entirely.
Put together, the controls fit in a short block of setup code.
A Minimal Isolated Run in Code
The sketch below creates a hardened sandbox with a fixed size, saves a clean checkpoint, writes the agent's script, runs it under a deadline and rewinds on failure.
Running it costs little. Solari bills sandboxes at $0.0245 per vCPU-hour and $0.0077 per GB-hour on the Professional plan, and the Free plan includes $3 of monthly credits. At a zero balance new sandboxes stop launching instead of adding an overage, so a runaway agent cannot inflate the bill.
Choosing the Right Setup
Isolating agent code comes down to a single rule: treat the code as hostile and give it only what the job needs. In practice that means a dedicated or hardened microVM, no secrets on the machine, explicit size and time caps, and a clean snapshot to rewind to. When the same agent also needs the web, the Solari introduction shows how sandboxes, browsers and desktops share one account and one API.
Get Started With Solari
Start by creating a hardened sandbox, writing a test script from the agent into it and checking the result for a timeout. Solari is built for this job: Solari sandboxes are ready in 90 ms, and over a full sandbox lifecycle Solari is about 1.3x faster than E2B and almost 3x cheaper per sandbox hour. Create a free Solari account and the Free plan's credits cover the first isolated run.
