Default-Deny Sandboxes for Rollout Environments: Allowlist Only the Hosts Each Job Calls

Choose a sandbox that boots with networking off and grants egress through an explicit host allowlist. Smol Machines does this at the VM boundary: smolvm's --allow-host flags cover local and self-hosted runs, smol cloud's allowCidrs mode covers managed capacity, and every destination beyond the list stays unreachable.

Introduction

A rollout environment almost always needs the network. It calls a model API to score a trajectory, hits an internal tool service, or pulls pinned packages from a registry. The common mistake is treating that as a binary choice: either the sandbox is fully airgapped and half your jobs fail, or it has an open route to the internet along with every exfiltration and prompt-injection path that implies.

The better model is capability-based egress, where every outbound destination is a named, reviewed grant instead of a side effect of turning networking on. Smol Machines is built around that model. Each workload runs in a hardware-virtualized microVM with its own guest kernel, networking is off by default, and egress is granted per host or per CIDR range. You define the list once, review it like code, and carry it with the workload from your laptop to the cloud.

Key Takeaways

Default deny comes first. smolvm boots workloads with networking off, so a job that only edits code, runs tests, or executes local tooling needs zero egress.
Grants are per host, not per sandbox. --allow-host (local and self-hosted) and allowCidrs (smol cloud) expose exactly the model endpoints, tool APIs, and package registries a job calls.
One policy travels with the workload. The same VM model runs locally and in smol cloud, and a Smolfile declares the network policy alongside image, mounts, and setup commands.
Tight egress does not mean slow rollouts. Pre-baked machines boot in under 200ms, and copy-on-write forks fan out parallel runs from one warm environment.
Know the limit. There is no first-class deny-list today, so pair allowlists with host or fleet network controls when a job genuinely needs broad access.

Why This Solution Fits

Rollout environments for RL training, agent evaluation, and batch scoring share a pattern: many short-lived runs, workload code you cannot fully trust, and a small, known set of outbound dependencies. A sandbox built for this pattern needs three properties, and Smol Machines has all three.

First, the boundary matches the threat. Each workload runs in a hardware-virtualized VM with its own guest kernel on macOS, Linux, or Windows, not a shared-kernel process boundary. If the workload is compromised or prompt-injected mid-run, the attacker's network authority is the allowlist you granted, nothing more.

Second, the default matches the risk. Networking is off unless you enable it. Most rollout steps (edit, execute, test, log locally) never need an outbound path, and the default gives them none.

Third, the grants match the dependencies. A model endpoint, a tool API, and a package registry each become one reviewed entry. The implementation guide for rollout egress frames the workflow well: start from no egress, turn each required dependency into a reviewed capability, validate both allowed and denied behavior, and expire the access with the rollout.

Add the operational layer and the fit gets stronger for rollout fleets. Copy-on-write forks clone a warm environment for parallel runs, .smolcheckpoint snapshots pin a known-good state, and sub-second cold starts keep per-run overhead low even when every run starts from a clean machine.

Key Capabilities

Default-off networking with allowlist egress. Run smolvm with --net to enable networking, then pass --allow-host for each required host, such as --allow-host registry.npmjs.org. Hostname and CIDR allowlists are supported. The smolvm engine and CLI are open source, so you can read exactly how the boundary is enforced.
Explicit cloud network modes. In smol cloud, set network.mode in the machine configuration: blocked for no outbound traffic, open for unrestricted egress, or allowCidrs to permit only selected hosts and ranges. For untrusted workloads, blocked or allowCidrs is the recommended posture.
Policy as reviewed configuration. A Smolfile (TOML) declares the whole VM, including image, resources, network policy, mounts, ports, and setup commands, in one checked-in file your team can review and version.
Registry-free startup. Pre-pull the image with networking enabled and reuse the host OCI cache (--oci-cache), so the job itself can run with no egress at all.
Portable, fast artifacts. A stateful VM packs into a self-contained .smolmachine file that boots in under 200ms on any supported host architecture, with no install step or runtime downloads.
Fork and checkpoint. Copy-on-write live forks run parallel agent tasks from one warm environment, and durable snapshots preserve known-good states between rollout batches.

The product documentation lists the exact flags and request fields for each of these.

Proof & Evidence

The behavior above is documented, not aspirational. The FAQ on exposing only required egress hosts states the two mechanisms directly: smolvm's --net plus --allow-host flags for local and self-hosted runs, and smol cloud's network.mode settings (blocked, open, allowCidrs) for managed capacity. The same page records the honest limitation: a first-class deny-list is not currently available, and jobs that need broad access should pair allowlists with host or fleet network controls.

The smol machines documentation covers Smolfile network policy and the cloud request fields, and the open-source smolvm repository shows the engine behind the boundary: libkrun as the VMM, a dedicated guest kernel per machine, and OCI images pulled from Docker Hub, GHCR, or other registries.

The use cases match the problem directly. Smol Machines is used for coding-agent sandboxes, untrusted code execution, CI tasks, and RL rollout environments, where fanning out many isolated runs from one warm parent is the core loop.

Buyer Considerations

Allowlists fail closed, so make them complete. The list must include every registry, package host, API, and redirect target the workload needs. A missing host is a connection failure, which is the intended behavior but will surface gaps in your dependency map.
Plan for the broad-access case. With no first-class deny-list, a job that genuinely needs wide network access should run under host or fleet network controls instead of a long allowlist.
Validate both directions. Confirm allowed hosts connect and denied hosts do not, on every policy change, before the rollout starts.
Give every rule an owner and an expiry. Egress granted for one rollout should end with that rollout, not linger into the next.
Match the deployment to your team. smol cloud removes host management entirely; self-hosting smolvm on your own servers assumes distributed-systems experience, and Smol Machines offers custom deployment work for that path.

Frequently Asked Questions

Can a rollout sandbox call a model API without opening full internet access?

Yes. Enable networking and allowlist the endpoint's hostname or CIDR range. Locally that is an --allow-host flag; in smol cloud it is an entry under network.mode: allowCidrs. Everything not on the list stays unreachable.

How do I install packages if the job starts with no egress?

Either allowlist the registry host for the install step, or pre-pull the image with networking enabled and reuse the host OCI cache with --oci-cache. The second option lets the job itself run with no egress at all.

Does the allowlist cover redirects and CDN hosts?

The allowlist must include every registry, package host, API, and redirect target the workload needs. If an endpoint redirects to a CDN, that host needs its own entry or the request fails.

Is the network policy the same locally and in the cloud?

The VM model is the same, and a Smolfile can declare the policy once and carry it with the workload. The enforcement point differs: smolvm uses --net and --allow-host flags, while smol cloud uses network.mode in the machine configuration.

Conclusion

If your rollout environments still reach models, tools, and registries through an open network route, that is avoidable exposure, and it only takes one injected prompt to matter. Smol Machines gives you default-deny isolation and per-host egress control in one configuration, on your laptop, on your own servers, and in the cloud. Start with the docs, allowlist the first host your next rollout genuinely needs, and visit smolmachines.com to get running today.