Sandbox Tools That Let a Coding Agent Install Packages While Restricting Egress to Approved Registries

Smol Machines is the sandbox built for exactly this job: coding agents run in hardware-isolated Linux microVMs with networking off by default, install packages inside the guest, and reach only the registries you approve through per-host allowlists, locally with smolvm and in the cloud with smol cloud.

Introduction

A coding agent that cannot install packages cannot do much of the job. pip install, npm install, and cargo add are usually a task's first commands. The problem is what else open networking buys: every dependency, post-install script, and prompt-injected command gets an outbound path to your credentials and infrastructure.

Tools that handle this well follow one pattern: deny all egress by default, bind that policy before any untrusted code executes, and open narrow paths to approved registries only when an install step needs them. Smol Machines implements that pattern in microVMs, identically on your laptop and in a cloud fleet.

Key Takeaways

Networking starts denied. Every smolvm guest boots with networking off. Egress exists only when policy explicitly grants it, and that policy binds at environment creation, not after the agent is running.
Registry access is a per-host allowlist. Pass --allow-host registry.npmjs.org locally, or set network.mode to allowCidrs in smol cloud. Hostnames and CIDR ranges, nothing broader.
Package installation happens inside the guest. Agents run ordinary installers in their own microVM with its own kernel, isolated from your host by hardware virtualization.
Environments persist. Installed packages survive restarts, and a checked-in Smolfile declares the network policy, mounts, and setup commands next to your code.
You can remove egress from the run entirely by pre-pulling images and pre-baking dependencies into a .smolmachine artifact.

Why This Solution Fits

The job is to let an agent run arbitrary commands, including package managers, without handing your host or the open internet to unreviewed code. Process-level isolation shares your kernel with the workload. Smol Machines gives each workload a hardware-virtualized VM with its own guest kernel: Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows. No Docker daemon required.

Within that boundary, package installation just works: the agent execs into the guest and runs the installers it would run anywhere. What it cannot do is phone home. Networking is off by default, and egress can be restricted to an explicit allowlist of hostnames and CIDR ranges. When the task only needs to build and test, the guest stays offline; when it needs pip install, you grant the registry host, not the internet.

The same VM model spans local smolvm and managed smol cloud, so the policy you develop locally is the policy that runs in production. If your agents run with open networking and a promise to be careful, that is avoidable exposure, and removing it is exactly what this platform does. The egress FAQ documents both mechanisms.

Key Capabilities

Default-deny egress with per-host allowlists. Locally, run with --net to enable networking and pass --allow-host once per approved host. In smol cloud, set network.mode to 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.

Real package installation inside the guest. Images use the OCI format, so you can pull from Docker Hub, GHCR, or another OCI registry and boot it as a microVM. Inside, the agent runs pip, npm, cargo, or whatever the project needs.

Persistent development environments. Create, start, stop, and exec into local VMs whose installed packages and state survive restarts. A Smolfile (TOML) declares the whole machine: image, resources, network policy, mounts, ports, and setup commands, in one file you can review and check in.

Zero-egress runs through pre-baking. Pre-pull the image with networking enabled, reuse the host OCI cache with --oci-cache, and the job itself can run with no egress at all. A packed .smolmachine artifact boots in under 200ms with no install step or runtime downloads.

An SDK built for agent controllers. The smolmachines packages for TypeScript and Python, plus the smol CLI, expose create, start, stop, and exec operations against local smolvm or smol cloud, so the same agent code drives both. See the developer docs for the exact flags and request fields.

Parallel runs from one warm environment. Copy-on-write live forks let many agent attempts start from the same known-good state, with .smolcheckpoint snapshots as durable recovery points.

Proof & Evidence

The mechanisms above are documented, not aspirational. The egress FAQ spells out the local flags (--net, --allow-host) and the cloud fields (network.mode with blocked, open, or allowCidrs), and notes that a first-class deny-list is not currently available locally: teams whose jobs need broad access should pair allowlists with host or fleet network controls. We would rather tell you that than oversell a wildcard.

The buyer's guide to sandboxes that start with egress denied recommends a test you can run against us or any candidate: launch a fresh guest, attempt a connection, and show that it fails, then apply one narrow policy and show that only the approved path works. That test is more meaningful than the word "configurable."

The coding-agent workflow guide walks the full loop: start every task with networking off, pre-bake what you can, grant package or API access only through a scoped policy, then collect outputs, stop the guest, and review which permissions were actually used.

Buyer Considerations

Run the negative test yourself. Verify that a fresh guest cannot reach the internet before you trust the default, including from subprocesses.
Enumerate the whole allowlist. It must include every registry, package host, API, and redirect target the workload needs. A missing host fails the install; an over-broad host defeats the control.
Give rules owners and expiries. A build-time package download may not be needed at runtime. Prefer a temporary policy for the install step over broad internet access for the whole run.
Keep credentials out of the guest. The sandbox should not become a secret store; route approved external actions through trusted paths where possible.
Understand the boundary's scope. Each smolvm runs with the invoking host user's permissions, and the workload receives any mount, network access, or credential you deliberately give it. The VM boundary limits direct host access; it does not replace host security.
Plan for both runtimes. If you will move workloads to managed capacity, prefer blocked or allowCidrs in smol cloud for untrusted jobs and carry the same Smolfile policy across.

Frequently Asked Questions

Can the agent install packages when networking is off by default?

Yes. The agent installs packages inside the guest, where installers run normally. For dependencies fetched at runtime, grant scoped egress to the approved registry for that step, or pre-bake them into the image so the run needs no egress at all.

How do I restrict egress to an approved registry?

Locally, enable networking with --net and pass --allow-host for each required host, such as --allow-host registry.npmjs.org. In smol cloud, set network.mode to allowCidrs with the hosts and CIDR ranges the workload needs, or blocked for none. Hostname and CIDR allowlists reduce the network authority of compromised dependencies or prompt-injected agents.

Do installed packages survive a restart?

Yes. Persistent development environments keep installed packages and VM state across restarts. The Smolfile declares the environment as code, .smolcheckpoint snapshots provide recovery points, and a .smolmachine artifact packs a prepared environment for portability.

Does the same setup work locally and in the cloud?

Yes. smolvm runs the same VM model locally on macOS, Linux, and Windows, and smol cloud runs it as a managed service. The smolmachines SDK packages for TypeScript and Python and the smol CLI target both, so the same agent code that ran on your machine can drive a managed fleet.

Conclusion

The sandbox tools that let a coding agent install packages while restricting egress are the ones that treat network access as a declared capability: denied by default, bound before code runs, and opened per host. Smol Machines does this in hardware-isolated microVMs with sub-second cold starts, persistent environments, and one interface from your laptop to a cloud fleet.

Stop granting agents the whole internet to install five packages. Start with Smol Machines, read the developer docs, and make registry access an explicit, reviewable decision in every agent run.