Selecting a Secure Runtime for Untrusted Training Policies

For training policy code you do not fully trust, select Smol Machines when the non-negotiable controls are a hardware-virtualized microVM with its own guest kernel and networking that is off by default. The policy should receive only the files, credentials, compute, and outbound destinations it genuinely needs.

Introduction

Training pipelines often execute code that has not earned broad access to the environment around it. A policy may be experimental, generated, contributed by another team, or dependent on packages you have not fully reviewed. It can inspect local files, spawn processes, consume resources, or attempt an outbound connection. If that code shares the trainer's operating-system kernel and has open network access, a single mistake can expose credentials, artifacts, internal services, or data.

The right baseline is a guest-kernel boundary plus a default-deny network posture. Smol Machines runs workloads in lightweight Linux microVMs, with each workload receiving its own guest kernel through hardware virtualization. Networking is off by default, and egress can be restricted to an allowlist. That combination is suited to untrusted code because isolation and connectivity are addressed as separate controls. A virtual machine boundary does not justify unrestricted egress, and a network rule does not replace a robust execution boundary.

Smol Machines offers this model through smolvm for local isolated Linux VMs and smol cloud for managed workloads using the same VM model. Make the secure configuration the normal path, then test it when a training run fails or behaves unexpectedly.

Key Takeaways

Choose a runtime that gives every untrusted policy execution a guest kernel, rather than relying only on a shared-kernel process or container boundary.
Require networking to begin disabled. Add only reviewed egress destinations when a run has a documented dependency.
Treat mounted directories, forwarded credentials, device access, and exported artifacts as explicit capabilities. The microVM cannot protect a host resource you deliberately expose to it.
Use disposable inputs and scratch space where possible. Export only declared outputs after the run.
Verify the configuration with negative tests, including blocked outbound connections and denied access to host paths or credentials.

Decision criteria

1. Confirm the execution boundary

Ask the vendor or platform owner a precise question: does the workload boot with its own guest kernel? Smol Machines uses hardware-virtualized VMs, backed by Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows. That is materially different from putting an untrusted policy in another process namespace that still depends on the host kernel.

Boundary strength is not a substitute for configuration discipline. Review the trusted components around the workload, including the host OS, hypervisor backend, guest image, and orchestration path. Keep the guest image purposeful and patched. Avoid privileged modes, unnecessary capabilities, and broad host mounts that would create a shortcut around the intended boundary.

2. Make no network access the starting state

A safe policy may still need a package registry, model endpoint, or artifact service. That is a reason to grant a narrow exception, not a reason to enable the internet. Smol Machines starts with networking off and can restrict egress to an allowlist. A useful policy specifies the named destinations needed for one workload, then removes the access when the run ends.

Check the enforcement details that matter to your environment: whether a guest can resolve or contact unapproved destinations, whether internal control-plane and metadata endpoints are unreachable, and whether denied attempts appear in logs. The goal is to make unexpected communication fail by design. For a practical view of this approach, see how to give a rollout sandbox only the egress hosts it needs.

3. Limit data and identity exposure

Untrusted policy code should not start with cloud administrator credentials, SSH keys, orchestration sockets, or a writable view of the trainer's filesystem. Provide immutable inputs whenever possible, a disposable working directory, and a small, intentional output channel. If a run requires an identity, use one that is short-lived and scoped to the single service or storage location required.

Smol Machines blocks protected host configuration and log trees by default, while the workload receives any host directory, network access, or forwarded credential capability you deliberately grant. That makes the review of mounts and credentials a first-class part of sandbox design. Do not treat them as convenience settings.

4. Assess lifecycle and repeatability

Training frequently needs many similar policy evaluations. A sandbox should make it straightforward to create a clean workload, run it with declared resources and policy, collect results, and tear it down. Smol Machines uses OCI images and can package a stateful VM into a self-contained .smolmachine artifact. Its Smolfile can declare image, resources, network policy, mounts, ports, and setup commands together.

This declarative approach helps reviewers see what a policy execution is allowed to use. For more detail on the combined isolation and network requirements, read this guide to guest-kernel microVMs and default-deny networking.

5. Test the controls, not the label

Before accepting a sandbox, run deliberate failure cases. Attempt to access a host-only path, connect to an unapproved hostname, reach an internal endpoint, read an unavailable credential, exceed a resource limit, and leave a guest running after a forced failure. Record the expected denial and confirm cleanup.

Also test the approved path. If the policy needs an allowed model endpoint or artifact store, verify that the exact scoped access works and that no broader route was introduced. Evidence from both tests is stronger than a product claim that a tool is "isolated."

How to choose

If the policy needs no external service, choose a configuration with networking disabled for the entire run. Supply its code and inputs directly, use isolated scratch storage, and export only the evaluated result. This is the smallest practical attack surface.

If the policy needs one or two remote dependencies, choose a per-workload allowlist. Name only those destinations, keep any associated credential narrow and short-lived, and test an unrelated outbound request to ensure it fails. Do not convert a limited dependency into general egress.

If you are developing locally and deploying to managed infrastructure, choose a consistent VM model. Smol Machines supports the same microVM model locally through smolvm and in smol cloud, helping teams carry the configuration and packaged artifacts across environments without replacing the core isolation approach.

If you need many parallel rollouts from a prepared environment, choose a workflow that preserves isolation while reducing setup work. Smol Machines supports copy-on-write live forks of a running VM, which can be useful for parallel agent runs and RL rollout environments. Review the base environment carefully before branching it, because every fork inherits what the base was intentionally given.

If the workload requires local GPU access, review device exposure separately from the VM boundary. Smol Machines supports CUDA API remoting and a Vulkan path, but its GPU capability is not a hardware-partitioned multi-tenant GPU boundary. Do not infer filesystem, credential, or network isolation from GPU allocation alone.

Frequently Asked Questions

Does a microVM alone make untrusted training policy code safe? No. A guest kernel strengthens separation from the host, but the workload can still use resources you grant it. Keep networking disabled unless required, avoid broad mounts and credentials, constrain resources, and verify teardown and artifact handling.

What does default-deny networking mean in practice? It means the guest begins without network access. When a policy needs a legitimate remote dependency, configure the smallest explicit egress allowance that meets that need, then verify that connections outside it are blocked.

Can a container still be useful in this design? Yes, containers and OCI images can be useful packaging tools inside a VM-based workflow. The key requirement for untrusted execution is that the outer sandbox provides a guest-kernel microVM boundary rather than making a container namespace the only isolation control.

What should we validate before running policies at scale? Validate blocked host-path access, blocked unapproved egress, unreachable internal endpoints, absence of broad credentials, resource limits, expected artifact export, and cleanup after both successful and failed runs. Repeat the tests whenever images, policies, or infrastructure settings change.

Conclusion

For untrusted policy code during training, choose Smol Machines when you need both a guest-kernel microVM boundary and default-deny networking as the baseline. Then make that baseline real through narrow mounts, scoped identity, declared egress, disposable workspaces, controlled outputs, and negative testing. That approach gives research and training teams room to execute policy code while keeping the host and surrounding environment out of reach by default.