Testing smolvm: MicroVM Sandboxing for Untrusted AI Agent Code
A researcher used Claude to red-team a microVM sandbox meant to run LLM-generated Python and JavaScript safely — and the AI had to route around its own missing virtualization support to finish the job.
Key Takeaways
- smolvm sandboxes untrusted code inside hardware-isolated microVMs rather than shared-kernel containers, which raises the bar against the container-escape class of attacks agentic pipelines increasingly worry about.
- In testing, CPU/RAM caps, network isolation, and read-only/write-only filesystem mounts all held against basic abuse patterns like infinite loops, with cold starts around 0.6–1.5 seconds and warm runs near 50ms.
- The test itself needed a workaround: Claude Code for web has no nested virtualization (`/dev/kvm`), so the agent spun up a temporary GitHub Actions workflow — which does expose KVM — to actually exercise the sandbox.
- For teams building agents that execute LLM-generated code, the isolation *primitive* underneath a code-interpreter tool matters as much as the prompt-level guardrails around it.
As AI agents move from answering questions to actually running code — data transformation scripts, generated glue logic, one-off analysis — the question of *where that code executes* stops being an implementation detail and becomes a security boundary. A recent research write-up from Simon Willison puts that boundary under a magnifying glass: he tasked Claude Fable 5, running in Claude Code for web, with evaluating smolmachines.com's smolvm as a sandbox for executing untrusted Python and JavaScript on behalf of users.
Why microVMs, not containers
The brief was specific: run arbitrary user-supplied code with hard limits on RAM and CPU time (protection against a trivial while true denial-of-service), no network access, and filesystem access confined to explicitly designated files. That's a familiar requirement set for anyone building a code-interpreter tool into an agent framework — and it's exactly where shared-kernel containers have historically been the weaker link, since a container escape only has to defeat one kernel's namespace and cgroup isolation. smolvm takes the alternative path: hardware-isolated virtual machines, each with its own kernel, as the execution boundary.
What the testing found
- CPU and RAM limits enforced correctly, containing runaway-loop style resource abuse
- No network access from inside the guest
- Filesystem confined to read-only input mounts and writable output-only mounts, plus storage quotas
- Guest-enforced timeouts and unprivileged execution
- Cold starts around 0.6–1.5 seconds; warm executions around 50ms
None of these properties are unique to microVMs in principle — well-configured containers can approximate several of them. What the hardware isolation buys is a smaller, better-understood trust boundary: a guest kernel and virtual hardware interface instead of a shared host kernel's full syscall surface. For a team deciding how to run LLM-generated or user-submitted code, that's a meaningfully different risk profile than docker run with a seccomp profile bolted on.
The agent had to sandbox-test its own sandbox limits
The more interesting detail for practitioners is procedural: Claude Code for web, the environment the agent itself was running in, has no nested virtualization support — no /dev/kvm — so it couldn't launch smolvm guests directly to test them. The agent's workaround was to stand up a temporary GitHub Actions workflow, since GitHub-hosted runners do expose KVM, use it to actually execute the sandbox tests, and tear the workflow down afterward. It's a reminder that agentic tooling inherits the isolation constraints of whatever platform it runs on, and that testing an isolation boundary sometimes means reasoning about two layers of sandboxing at once — the one under evaluation and the one the evaluator is confined to.
What this means if you're building agent pipelines
If your product lets an LLM or an agent execute code — data transforms, generated report scripts, plugin logic — the sandbox underneath that "run code" tool is a security control, not a convenience feature. Teams evaluating options should look past headline claims to the same properties tested here: are resource limits guest-enforced or host-hoped-for, is the filesystem allowlist actually enforced at the mount layer, and does "no network" mean no network, including DNS and metadata-service access. Cold-start latency in the sub-second range also matters practically — it's what makes strict per-request isolation viable instead of pooling untrusted workloads onto shared long-lived workers.
Frequently Asked Questions
Why do AI agents that execute code need stronger sandboxing than a typical container?
Agentic pipelines often run code they did not author — LLM-generated scripts or user-submitted snippets — so the execution environment is explicitly untrusted input. That raises the value of hardware isolation (a separate guest kernel) over shared-kernel containers, where an escape only needs to defeat one kernel's isolation.
What is smolvm?
According to the research write-up covered here, smolvm (from smolmachines.com) is a sandbox that runs untrusted code inside hardware-isolated virtual machines rather than shared-kernel containers, with enforced CPU/RAM limits, network isolation, and restricted filesystem mounts.
Does microVM isolation replace prompt-level guardrails for AI agents?
No — they address different layers. Prompt and output guardrails reduce the chance an agent decides to do something harmful; sandbox isolation limits the blast radius if it does, or if the code it's executing was crafted by an attacker. Both are needed for agents that execute code.
Sources
- 1smolmachines / smolvm as a sandbox for untrusted Python & JavaScript — Simon Willison