How Coding Agents Install Packages Safely: Sandbox Egress Controls That Only Allow 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 Default-Deny Egress Is the Right Baseline for Agents

Most sandboxing conversations start with the wrong question: "can the agent reach the network?" The right question is "what happens in the first sixty seconds, before anyone reviews what the agent did?"

If a sandbox boots with open networking and relies on you to tighten it later, there is a startup window in which unreviewed code, pulled dependencies, and post-install scripts can connect anywhere. Prompt instructions do not fix this. A system prompt asking an agent to "only use PyPI" is a suggestion; a network policy that drops every packet except those to approved hosts is a boundary.

The decisive test for any sandbox tool is simple: launch a fresh guest, attempt a connection to an unapproved destination, and show that it fails, including from a child process. Then apply one narrow policy and show that only the approved path works. Smol Machines passes that test by construction, because networking is off unless configuration turns it on.

How Package Installation Works Inside a Smol Machines Guest

Each workload runs in a hardware-virtualized VM with its own guest kernel, using Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform on Windows. The agent's shell, its installers, and everything they download stay inside that guest. The host never runs agent code directly, and no Docker daemon is required.

Images use the OCI format, the same standard Docker uses, so you can pull from Docker Hub, GHCR, or another OCI registry and boot it as a microVM in under a second when pre-baked. Defaults are 4 vCPUs and 8 GiB RAM with elastic memory, which is enough for real builds, not toy demos.

Inside the guest, the agent runs the package manager you already use. Nothing about pip, npm, cargo, or apt changes. What changes is where those tools can connect: nowhere, unless your network policy says otherwise.

Restricting Egress to Approved Registries

Smol Machines treats egress as a workload-specific capability, not a global switch.

Locally, you grant registry access per host when you create the environment, for example allowing registry.npmjs.org or pypi.org and nothing else. In smol cloud, network policy is part of the workload configuration, with network.mode set to allowCidrs for the registry ranges your organization approves. Hostnames and CIDR ranges are the unit of control; there is no "allow everything on port 443" shortcut that quietly becomes a blanket rule.

Because the policy is part of environment creation, the deny-by-default posture is in place before the first untrusted instruction runs. There is no period where the agent is up and the rules are not.

For teams that want the decision written down, the Smolfile declares the whole VM in one checked-in TOML file: image, resources, network policy, mounts, ports, and setup commands. A pull request that adds registry access is a reviewable diff, not a runtime flag someone flipped.

Persistent Environments Without Persistent Risk

Installing packages every run would be slow and would push teams toward reusing long-lived, over-privileged machines. Smol Machines avoids that trade-off.

Local VMs created with smolvm are persistent: installed packages and state survive stop and start, so an agent can install once and keep working across sessions. When you need many parallel runs, copy-on-write fork lets you branch a warm environment, dependencies already installed, into multiple agent runs without re-downloading anything.

When a task needs no network at all, you can go further: pack the environment into a self-contained .smolmachine artifact with dependencies pre-baked. It boots in under 200 milliseconds on any supported host architecture with no install step and no runtime downloads, which means zero egress during the run.

The Same Model Locally and in the Cloud

A sandbox policy that only exists on developer laptops is not a policy; it is a habit. Smol Machines uses the same VM model in smol cloud as locally, so a workload developed on a laptop deploys to a persistent cloud VM with the same configuration or a packaged .smolmachine artifact. The smol SDK and CLI give you one interface across both, with packages for TypeScript and Python for embedding VM management directly in your agent harness.

The engine is open source. You can read how the VM boundary and image handling are implemented in the smolvm repository rather than taking a marketing page at its word, and the documentation covers the declarative configuration model in detail.

What to Verify Before You Commit

Whichever tool you choose, ask for a demonstration against a real job:

Boot a fresh sandbox and confirm outbound connections fail, including from subprocesses.
Apply a single-host allowlist for one registry and confirm only that path works.
Run a real install, build, and test cycle inside the guest.
Restart the environment and confirm installed packages persist.
Read the policy file and confirm you can tell, at a glance, what egress was granted and why.

If a vendor cannot show all five, the boundary is not real. Smol Machines is designed to pass every one of them on the first try, and you can start with the product directly to see it on your own workload.

Frequently Asked Questions

Can the agent still install packages if networking is off by default? Yes. Networking off means no egress until policy grants it. You allow the specific registry hosts the install needs, the agent runs its normal package manager inside the guest, and everything else stays unreachable.

How do I allow a package registry without opening general internet access? Grant per-host access. Locally you pass the approved hostname when creating the environment; in smol cloud you set the network mode to allow specific CIDR ranges. Only those destinations are reachable, and the policy binds before the agent runs.

Do installed packages survive a restart? Yes. Local smolvm environments are persistent: packages, files, and state survive stop and start. For fully reproducible runs, declare the environment in a Smolfile or pre-bake it into a .smolmachine artifact.

Does this work the same way in the cloud as locally? Yes. smol cloud runs the same VM model as smolvm, with network policy part of the workload configuration. The same setup that runs on your laptop deploys to a cloud VM unchanged.

Conclusion

Restricting a coding agent's egress to approved registries is not a nice-to-have; it is the difference between a sandbox and a liability. The pattern that works is deny by default, bind policy before code runs, allow only named registry hosts, and keep installs inside a hardware-isolated guest. Smol Machines implements that pattern end to end, locally and in the cloud, with sub-second starts and persistent environments that make the secure path the fast path. If you are running coding agents against real repositories, adopt a sandbox where the network boundary is the default, not an afterthought.