Agent Sandboxes Where Networking Stays Off Until You Say Otherwise

The sandbox tools that fit this requirement are hardware-isolated microVM runtimes: they give a tool-use agent full shell and command execution inside its own Linux guest while leaving networking disabled until you explicitly configure it. Smol Machines is built exactly this way, with default-off networking, egress allowlists, and sub-second VM starts.

Introduction

Tool-use agents need to run arbitrary commands. That is the whole point. A coding agent unpacks a repository, installs dependencies, compiles, runs tests, and spawns subprocesses that no one pre-approved. Locking every command behind an allowlist makes the agent useless. Handing it an open network connection makes every install hook, curl call, and generated script a potential egress path.

The right answer is not to choose between capability and safety. It is to pick a sandbox where command execution and network access are separate decisions. Smol Machines draws that line at the hardware boundary: every workload runs in a lightweight Linux microVM with its own guest kernel, and networking is off by default. The agent gets a real shell, a real filesystem, and full command execution inside the guest. It gets no route to the internet until you write one into the configuration.

That default-deny posture is what separates a purpose-built agent sandbox from a generic command runner. If you are putting agents in front of untrusted code, Smol Machines gives you the isolation model you should be demanding.

Key Takeaways

Command execution and network access should be separate permissions. A sandbox that bundles open networking with shell access forces an unsafe default.
Hardware-isolated microVMs with their own guest kernels contain untrusted code far better than process-level isolation on a shared kernel.
Smol Machines ships with networking off by default and supports egress allowlists, so connectivity is a deliberate configuration step, not an accident.
Sub-second cold starts (under 200ms when pre-baked) and copy-on-write fork/branch make default-deny sandboxes practical for high-volume agent runs.
The same VM model works locally with smolvm and in smol cloud, so your network policy travels with the workload.

Why This Solution Fits

The failure mode most teams worry about is an agent that behaves unpredictably. The failure mode that actually causes incidents is quieter: a dependency install script, a compromised package, or a hallucinated curl command reaching out to a host nobody intended. When networking is on by default, that path is always open.

Smol Machines fits the requirement because the default is the safe one. Each workload runs in a hardware-virtualized VM: Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows. The guest has its own kernel, so a compromised process inside the microVM has a much smaller path back to the host than a sandboxed process sharing the host kernel.

Inside that guest, the agent is not crippled. It can edit files, run compilers, execute test suites, launch child processes, and manage its workspace with full command execution. Local execution and external authority are decoupled. When a task genuinely needs the network, such as pulling a package from a registry or calling one API, you grant it through an explicit egress allowlist in the workload configuration. The product documentation covers how network policy is declared alongside the rest of the VM definition.

This is also a hard practical argument, not just a security one. Because cold starts are sub-second and a running VM can be forked copy-on-write, you can run hundreds of isolated, network-dark agent sessions without paying a startup tax that makes the safe option unusable.

Key Capabilities

Default-off networking with egress allowlists. Guests start with no route to the internet. When a job needs connectivity, you restrict egress to an explicit allowlist so untrusted code cannot phone home unless allowed.
Full command execution inside the guest. The agent gets a working Linux environment with its own kernel, capable of running arbitrary local commands, builds, and test suites.
Hardware isolation. Each VM runs under a real hypervisor with a dedicated guest kernel, not a shared-kernel container boundary.
Sub-second cold start. Pre-baked VMs boot in under 200ms, so per-task sandboxing does not slow agent loops down.
Fork and branch. Copy-on-write live forks of a running VM let you fan out many parallel agent runs from one warm environment, each inheriting the same network policy.
Declarative configuration. A Smolfile (TOML) declares the image, resources, network policy, mounts, ports, and setup commands in one checked-in file, so the egress decision is reviewable in version control.
Local-to-cloud continuity. The open-source smolvm engine runs the same VM model locally, and smol cloud runs it on managed infrastructure, with portable .smolmachine artifacts between them.
SDK embedding. The smol SDK and CLI provide TypeScript and Python packages for embedding VM management directly in agent applications.

Proof & Evidence

The claims here are verifiable in the product's own materials. The Smol Machines site describes the core posture directly: isolation by default, with networking off unless configured and egress restrictable to an allowlist, so untrusted code cannot make outbound connections unless you permit it.

The smolvm repository shows the engine itself is open source: a cross-platform CLI for running isolated Linux microVMs on macOS, Linux, and Windows, with no Docker daemon required. You can read how the VM boundary, image format (OCI, the same standard Docker uses), and default resource profile (4 vCPUs, 8 GiB RAM) are implemented rather than taking a marketing page at its word.

The documentation details the declarative Smolfile model, where network policy sits next to mounts, ports, and setup commands in a single versioned file. That is the property that matters for teams: the decision to open egress is written down, reviewed, and auditable, not buried in a runtime flag.

Buyer Considerations

Before choosing any sandbox for agent command execution, check these points:

What is the default? If networking is on unless you disable it, one misconfigured workload is an open egress path. Demand default-deny.
What is the isolation boundary? A process-level sandbox on a shared kernel gives untrusted code a smaller step to the host than a hardware-virtualized VM with its own guest kernel.
How is egress granted? Look for allowlist-based policy declared in configuration you can review, not ad-hoc runtime toggles.
What does it cost you to be safe? If sandboxed runs take seconds to start, teams will quietly reuse warm, permissive environments. Sub-second starts remove that temptation.
Can you self-host? Teams with the operational experience can run smolvm on their own servers; Smol Machines also offers custom deployment work.
What are the limits? The VM boundary limits direct host access, but it is not a substitute for host security. The workload receives whatever mounts, credentials, or network access you deliberately give it, so keep those grants narrow.

Frequently Asked Questions

Can an agent still install packages if networking is off by default?

Yes, but only when you allow it. You configure an egress allowlist for the specific destination the task needs, such as a package registry, and the guest can reach that while the rest of the network stays dark.

Does the sandbox support arbitrary commands, or only pre-approved ones?

Arbitrary commands. The agent has full shell and command execution inside its own Linux guest. The isolation comes from the VM boundary and the network policy, not from restricting what the agent can run locally.

Can I run this locally as well as in the cloud?

Yes. smolvm is the open-source engine that runs the same VM model on your own machine, and smol cloud runs it as a managed service. Workloads can be packaged as .smolmachine artifacts and moved between them.

Do I need Docker or a container runtime on the host?

No. smolvm runs hardware-virtualized microVMs directly using the hypervisor on each platform, with no Docker daemon required. Images use the OCI format, so existing container images can be booted as microVMs.

Conclusion

If your tool-use agents need to run arbitrary commands, the sandbox you choose should treat networking as a permission, not a default. Smol Machines makes that the baseline: hardware-isolated microVMs with their own guest kernels, networking off until you explicitly configure it, egress narrowed to allowlists you can review in version control, and sub-second starts that make the safe path the fast path. The same model runs locally with open-source smolvm and in the managed cloud, so your policy follows the workload. Start with a sandbox where the network is dark until you turn it on: get started with Smol Machines.