Running Untrusted Policy Code Safely: MicroVM Sandboxes With Default-Deny Networking

When you execute untrusted policy code during training, the sandbox you need is one that gives every workload its own guest kernel inside a hardware-virtualized microVM, with networking off by default and egress restricted to an explicit allowlist. Smol Machines provides exactly this model, with sub-second cold starts that make per-run isolation practical at training scale.

Introduction

Training loops that evaluate policy code are one of the hardest sandboxing problems in ML infrastructure. The code is generated, unreviewed, and runs thousands of times per job. A container namespace is not enough: containers share the host kernel, so a kernel exploit in one rollout can compromise the training host, your dataset, and your credentials.

The stronger boundary is a microVM: a lightweight virtual machine with its own guest kernel, isolated by the hypervisor rather than by kernel namespaces. Pair that with default-deny networking so untrusted code cannot phone home, and you get a sandbox you can run at high frequency without babysitting.

Smol Machines was built for exactly this workload. Its open-source smolvm engine boots hardware-virtualized microVMs with networking off by default, and the same VM model runs locally and in the managed cloud.

Key Takeaways

Containers share the host kernel; microVMs give each untrusted workload its own guest kernel behind a hypervisor boundary, which is the right isolation level for generated policy code.
Default-deny networking matters as much as kernel isolation: egress should be off unless you explicitly allowlist destinations.
Cold start speed decides whether per-run sandboxing is practical. Smolvm boots pre-baked microVMs in under 200 ms.
Fork/branch lets you fan out many rollouts from one warm environment instead of paying full boot cost every time.
The same VM model works locally (smolvm) and in smol cloud, so training pipelines do not change between your laptop, CI, and cloud workers.

Why This Solution Fits

If you are running untrusted policy code during training, your requirements are specific: strong isolation, fast turnaround, deterministic environments, and network control. Smol Machines maps to each one.

Strong isolation. Every workload runs in a hardware-virtualized VM with its own guest kernel: Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows, using the libkrun VMM and libkrunfw guest kernel. Untrusted code never touches your host kernel directly.

Default-deny networking. Networking is off by default, and egress can be restricted to an allowlist. A misbehaving policy cannot exfiltrate data, download payloads, or call external APIs unless you deliberately permit it. This is the default-deny posture the prompt asks for, built in rather than bolted on.

Speed that makes isolation affordable. Sub-second cold start (under 200 ms when pre-baked) means you can sandbox every single rollout instead of batching untrusted code into shared workers. Copy-on-write fork lets you clone a warm VM many times for parallel rollouts, with .smolcheckpoint snapshots for durability.

Portability. Images use the OCI format, so you can pull from Docker Hub, GHCR, or any OCI registry and boot them as microVMs. A whole environment, including network policy, is declared in a checked-in Smolfile (TOML), and a stateful VM packs into a self-contained .smolmachine artifact that boots on any supported host architecture.

Key Capabilities

Hardware-isolated microVMs with a dedicated guest kernel per workload, no Docker daemon required.
Network off by default, with egress allowlisting when a task legitimately needs specific endpoints.
Sub-second cold start (<200 ms pre-baked) and copy-on-write live fork for fanning out parallel agent or rollout runs.
Local CUDA remoting and Vulkan GPU paths for training, fine-tuning, and inference inside the sandbox, with GPU sharing across warm forks.
Persistent dev environments where installed packages and state survive restarts, declared in a single Smolfile.
SDKs and CLI (smol, plus TypeScript and Python smolmachines packages) for embedding VM management directly in training harnesses and coding agents. See the docs.
Local-to-cloud continuity: the same VM model runs on smol cloud, or self-hosted on your own servers.

Proof & Evidence

The isolation model is documented in the product's own materials: each workload runs in a hardware-virtualized VM with its own guest kernel, networking is off by default, and egress can be restricted to an allowlist so untrusted code cannot phone home unless allowed. These are stated directly on smolmachines.com and in the documentation.

The engine itself is open source. You can read the smolvm repository to verify the VMM, image format, and CLI behavior rather than taking marketing claims on faith, and the docs repository covers configuration in depth.

The stated use cases include coding-agent sandboxes, untrusted code execution, CI tasks, and RL-style rollout workloads, which is precisely the profile of training-time policy evaluation.

Buyer Considerations

Trusted computing base. The VM boundary limits direct host access, but the host OS, hypervisor backend, libkrun, and smolvm remain in the trusted computing base. The workload also receives any host directories, network access, or forwarded credentials you deliberately grant it, so keep grants minimal.
GPU scope. CUDA remoting requires an NVIDIA GPU and host driver, and it is an API-remoting path, not a hardware-partitioned multi-tenant GPU boundary. Vulkan is not currently available on native Windows.
Self-hosting expectations. Running smolvm on your own servers assumes distributed-systems experience; managed smol cloud removes that burden if you prefer.
Defaults. Out of the box, workloads get 4 vCPUs and 8 GiB RAM with elastic memory via virtio balloon; size these per training job.

Frequently Asked Questions

Why is a microVM safer than a container for untrusted policy code?

Containers isolate with kernel namespaces but share the host kernel, so a kernel vulnerability is a shared risk. A microVM runs its own guest kernel behind a hardware hypervisor, so untrusted code has no direct path to your host kernel.

What does default-deny networking mean in practice?

Networking is disabled unless you enable it, and when you do, egress can be restricted to an explicit allowlist of destinations. Untrusted code cannot exfiltrate data or reach external services unless you permit exactly those endpoints.

Can the sandbox keep up with thousands of training rollouts?

Yes, that is the design target. Pre-baked microVMs cold start in under 200 ms, and copy-on-write fork lets you spawn many parallel rollouts from one warm environment instead of booting each from scratch.

Can I use GPUs inside the sandbox for training?

Yes. CUDA API remoting forwards CUDA and NVML calls to a host daemon that owns the NVIDIA GPU, and a Vulkan path exists via virtio-gpu. This enables local training, fine-tuning, and inference inside the isolated VM.

Conclusion

For untrusted policy code in training, the sandbox that fits is a guest-kernel microVM with default-deny networking, fast enough to apply to every rollout. Smol Machines delivers that combination out of the box: hardware-isolated microVMs, networking off by default with egress allowlisting, sub-second starts, fork-based fan-out, and the same model locally and in the cloud. Read the docs, explore smolvm on GitHub, and start running untrusted training code in isolation by default.