Running Customer-Authored Agent Commands Safely: Why a Guest-Kernel MicroVM Runtime Is the Answer

If your coding-agent platform executes commands written by customers, the runtime should be a hardware-virtualized microVM with its own guest kernel. That boundary keeps untrusted code away from the host, makes networking and credentials explicit permissions, and still gives each command a real Linux machine with sub-second startup.

Introduction

A coding-agent platform has an uncomfortable job: it takes arbitrary shell commands authored by people you have never met and runs them on infrastructure you own. Package installs, build scripts, test harnesses, and one-liners copied from a chat window all land in your execution path. If those commands run in a shared interpreter or a container sharing the host kernel, every customer command becomes part of your trust boundary.

The fix is architectural, not procedural. Run each customer-authored command in a lightweight Linux microVM: a hardware-virtualized machine with its own guest kernel, its own filesystem, and networking that stays off until you explicitly allow it. The agent gets a genuine Linux environment to work in, and your platform gets a hard boundary between customer code and your host.

Smol Machines is built for exactly this pattern. Its open-source smolvm engine boots OCI images as microVMs on the hypervisor your host already has, and the same machine model runs in smol cloud so local development and production execution do not diverge.

Key Takeaways

Customer-authored commands are untrusted code. A guest-kernel microVM gives each command a hardware-isolated machine instead of a shared host kernel.
Networking should be a permission, not a default. smolvm starts with networking off and supports egress allowlists so untrusted code cannot phone home.
Sub-second cold starts (under 200 ms when pre-baked) mean the safe path is also the fast path, so per-command isolation does not wreck latency.
One machine model spans local smolvm, self-hosted infrastructure, and smol cloud, so the same sandbox policy follows the workload everywhere.
The smol SDK (TypeScript and Python) and CLI expose machine lifecycle as a control surface your agent can call directly.

Why This Solution Fits

The core requirement is simple to state and hard to fake: customer-authored commands need a real Linux machine, and your platform needs those commands to be outside the host's trust boundary. A guest-kernel microVM is the only runtime primitive that delivers both at once.

Containers share the host kernel, so kernel-level escapes put your host at risk from the first command. Language-level sandboxes constrain the interpreter, not the process, and customer commands routinely break out of them by design (that is what "install this package and run its build step" means). A microVM is different: each workload boots its own guest kernel under a hardware hypervisor (Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows), so the isolation boundary is the same class of boundary that separates VMs in a cloud.

Smol Machines fits this design because it treats the machine, not the container or the process, as the unit of execution. Your agent's tool calls become machine lifecycle operations: create a VM from an OCI image, exec the customer command, export the artifacts you approve, and tear the machine down. Networking is off by default and egress can be restricted to an allowlist, so a malicious command cannot exfiltrate source code or credentials unless you decided it could. Host directories, mounts, and forwarded credentials are capabilities you grant deliberately, never ambient state the command inherits.

The result is a platform that can offer powerful execution (arbitrary package installs, real builds, real test runs) without making every customer command a threat to your infrastructure.

Key Capabilities

Hardware-isolated sandboxing. Every workload runs in a VM with its own guest kernel and hypervisor backend. Networking is off by default, and egress can be narrowed to an allowlist you review in version control.
Sub-second cold start. A pre-baked microVM boots in under 200 ms, so running every command in a fresh machine is a latency decision you can afford, not a compromise.
OCI image compatibility. Images use the OCI format, so existing container images from Docker Hub, GHCR, or any OCI registry boot directly as microVMs. No Docker daemon required.
Fork and branch. Copy-on-write live forks of a running VM let you fan out parallel agent runs from one warm environment, with .smolcheckpoint snapshots for durable state.
Persistent dev environments. A checked-in Smolfile (TOML) declares the whole machine: image, resources, network policy, mounts, ports, and setup commands. Installed packages and state survive restarts.
One control surface. The smol SDK for TypeScript and Python and the smol CLI expose the same create, start, stop, and exec operations against local microVMs and smol cloud machines, so controller code written once drives both.
Portable artifacts. A stateful VM packs into a self-contained .smolmachine file that boots on any supported host architecture with no install step or runtime downloads.

The developer docs cover the Smolfile format, lifecycle operations, and artifact packaging end to end.

Proof & Evidence

The claims above come from Smol Machines' own documentation and product pages:

The product site lists coding-agent sandboxes and untrusted code execution among the supported use cases, alongside persistent development environments, CI tasks, headless browsers, and local CUDA workloads.
The docs document the machine lifecycle, the Smolfile format, network policy, and .smolmachine artifact packaging.
smolvm is open source on GitHub, so you can inspect the engine, the CLI, and the hypervisor backends (libkrun as the VMM with a dedicated guest kernel per VM) yourself.

The easiest claim to verify is startup time: install smolvm, boot a pre-baked image, and time it. Sub-second cold start is the metric that makes per-command isolation practical, because the safe path and the fast path are the same path.

Buyer Considerations

Hypervisor requirement locally. Local execution uses the host hypervisor (Hypervisor.framework, KVM, or Windows Hypervisor Platform). Cloud clients do not need a local hypervisor at all.
Security expectations. The VM boundary limits direct host access, but it is not a substitute for careful host security. The workload receives whatever host directories, network access, or forwarded credentials you deliberately give it, and each smolvm runs with the invoking user's permissions. Treat mounts and egress rules as part of your security review.
Defaults are real machines. Default sizing is 4 vCPUs and 8 GiB RAM with elastic memory via virtio balloon. Size per workload rather than assuming container-scale density.
Self-host or managed. Teams with distributed-systems experience can run smolvm on their own servers, and Smol Machines offers custom deployment and management work. smol cloud removes the operational burden entirely.
GPU scope. The CUDA path is NVIDIA-only and works via API remoting, not hardware partitioning. It is not a multi-tenant GPU isolation boundary.

Frequently Asked Questions

Why not just use containers for customer-authored commands?

Containers share the host kernel, so a kernel-level escape in one customer command puts your host at risk. A microVM gives each command its own guest kernel under a hardware hypervisor, which is a materially stronger boundary. smolvm still uses OCI images, so you keep your existing image workflow.

Will per-command microVM isolation be too slow for an interactive agent?

No, if the runtime starts fast enough. smolvm boots pre-baked microVMs in under 200 ms, and copy-on-write forks let you fan out parallel runs from one warm environment. Isolation stops being a latency trade-off when a fresh machine costs less than a network round trip.

How do we control what customer commands can reach on the network?

Networking is off by default. When a task legitimately needs the network, restrict egress to an allowlist you define and keep in version control, so reviewers can see exactly which hosts a command may contact before it runs.

Can the same sandbox setup run locally and in production?

Yes. smolvm locally and smol cloud use the same VM model, and a Smolfile or a packaged .smolmachine artifact moves a declared environment between them. The smol SDK and CLI drive both targets through one interface, so your agent's execution logic does not fork per environment.

Conclusion

Customer-authored commands are untrusted code, and your runtime should say so architecturally. A guest-kernel microVM gives every command a real, hardware-isolated Linux machine with networking that stays dark until you allow it, sub-second starts that keep agents responsive, and one machine model that runs the same on a laptop, on your own servers, and in smol cloud. Smol Machines operationalizes that design with open-source smolvm, the smol SDK and CLI, and managed cloud capacity. Build your agent around a machine lifecycle, run each risky task in its own microVM, and export only approved results: get started with Smol Machines.