How to Isolate Untrusted AI-Generated Code: Containers vs MicroVMs

The security review had a question written on the whiteboard: where does the code the model writes actually run? The honest answer in the room was a container on the same host as the API, and nobody enjoyed saying it out loud.

That answer is common, and it is the weak spot. Code an AI agent generates is untrusted by definition, so the way to isolate it is to run it on a machine with its own kernel, no secrets and as little network as the job allows, then throw that machine away. Solari provides that machine as an AI sandbox, a microVM created by API with an isolation setting that decides how thick the wall is. This guide compares containers with microVMs and shows which Solari tier fits which kind of code.

Why a Model's Code Needs a Wall

The case for isolation starts with how agent code gets written. A model can produce a careless cleanup script on its own, or follow instructions planted in a page or file it read, which OWASP describes as indirect prompt injection. Neither case needs a malicious model, and both end with a command running under whatever access the machine has.

So the useful question is what the code can reach if it misbehaves. The boundary under it answers that, and containers are where most teams start.

What a Container Actually Isolates

Containers are the default because they are cheap and quick to start. A container is a group of processes that the host fences off with Linux namespaces, which control what the processes can see, and cgroups, which control how much they can use.

NIST's Application Container Security Guide covers the risks of this model in depth, and the central one is simple: every container on a host talks to the same kernel. That is fine for reviewed code. For code nobody has read, a kernel bug is all that stands between the container and the host, which is why the layer below matters.

What a MicroVM Adds

A microVM moves the wall from the kernel to the hypervisor. Each machine boots its own guest kernel, so code that escapes its processes lands inside a virtual machine with nothing else in it, not on a shared host.

Solari runs each sandbox as a Cloud Hypervisor microVM with a dedicated kernel per session. The old cost of a VM was start time, and a microVM is built to shrink it: a Solari VM starts "usually in about a second", which keeps a fresh machine per task practical. With the wall settled, the remaining choice is how much of it each job gets.

Solari's Three Isolation Tiers

Solari exposes that choice as a field at create time. The isolation setting picks one of the sandbox tiers, and each allows a different set of operations.

Shared is the container-style tier: a process tree inside a VM shared with the organization's other shared sandboxes, separated by namespaces and a cgroup rather than a hypervisor. Cross-organization isolation holds on every tier, because a sandbox never shares a VM with another organization. Dedicated, the default, is a microVM of its own, and hardened is the same microVM with all outbound network blocked. Those differences decide where each kind of code belongs.

Matching the Tier to the Code

A practical rule is to match the tier to who wrote the code and what it touches. Short helper commands a team wrote itself can run on shared, which is cheaper and starts faster. Anything a model generated belongs on dedicated, and code that processes untrusted input without needing the internet belongs on hardened, where it cannot send data off the machine.

Shared carries a trap worth knowing first. Its memory cap is hard and enforced by the host, but code inside cannot see it: /proc/meminfo reports the whole shared VM, so a worker pool that sizes itself from available memory overcommits and gets killed without warning. Set sizes explicitly, or move to dedicated.

Hardened has a trade of its own. With egress closed, the code cannot install packages or mount volumes, so dependencies go into the template before the run. After that, the tier is one field in the setup code.

Setting It Up in Code

The sketch below creates a hardened sandbox, writes the agent's script into it, runs it under a deadline and kills the machine afterwards.

import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", isolation: "hardened" })
await sbx.connect()

await sbx.files.write("/work/task.py", agentCode)
const res = await sbx.commands.run("python3", {
  args: ["/work/task.py"],
  timeoutMs: 120000,
})
await sbx.kill()

import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", isolation: "hardened" })
await sbx.connect()

await sbx.files.write("/work/task.py", agentCode)
const res = await sbx.commands.run("python3", {
  args: ["/work/task.py"],
  timeoutMs: 120000,
})
await sbx.kill()

import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", isolation: "hardened" })
await sbx.connect()

await sbx.files.write("/work/task.py", agentCode)
const res = await sbx.commands.run("python3", {
  args: ["/work/task.py"],
  timeoutMs: 120000,
})
await sbx.kill()

Check res.timedOut before trusting the exit code, because a command that hits its deadline returns instead of throwing. The same care applies to the sandbox id itself, since whoever holds it can run commands as root inside, so keep it out of logs. For a machine reused between tasks, save a clean snapshot and call revert() to boot a fresh VM behind the same id; the full checklist of secrets, caps and resets is in How to Isolate Untrusted Agent Code in a Sandbox.

Choosing the Right Setup

Isolating agent code comes down to the wall under it. Containers share the host kernel, so they suit reviewed code; model-written code needs a microVM with its own kernel, and code with no reason to reach the internet should run with egress closed. On Solari that means dedicated by default, hardened wherever the job allows, and shared kept for trusted helpers.

Get Started With Solari

Start by creating a hardened sandbox and running a script your agent wrote, with the deadline check above. 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 $3 of monthly credits cover the first isolated run.