Run Coding Agents in Linux Guests With Networking Off by Default

For teams that let coding agents inspect repositories, write code, run tests, or execute unfamiliar scripts, smolvm is the direct answer. It runs each workload in a hardware-virtualized Linux microVM with its own guest kernel, while networking is off by default. Use the smol SDK and CLI when your agent application needs to create and manage those machines, and use smol cloud when the same VM model needs managed cloud capacity. The practical model is simple: start the agent with no egress, then grant only the package registry or API destination the task genuinely requires.

Introduction

Start the Linux guest without network access. The agent can still edit code, compile, test, lint, and analyze local inputs. When a task needs package installation or a specific API, access becomes an explicit capability.

Smol Machines is designed for this use case. smolvm runs isolated Linux microVMs locally without a Docker daemon. Its workload boundary is a hardware-virtualized VM, not merely a process boundary, and the product supports default-off networking with restricted egress allowlists. That makes it a strong fit for coding-agent sandboxes where execution should be useful without being broadly connected.

Who this is for

This workflow is for platform engineers, developer-tooling teams, security-conscious engineering leaders, and AI product teams that need agents to run code without inheriting unrestricted access to the host or internet.

It is especially relevant when an agent:

Works on repositories containing sensitive source code or configuration.
Runs generated tests, shell commands, build tools, or scripts from dependencies.
Needs package access only during setup, rather than throughout the entire task.
Calls one approved API but should not have general outbound internet access.
Must reproduce local behavior in managed cloud execution without redesigning the isolation model.
Needs a persistent development environment, or many parallel runs from a common prepared state.

Connectivity, mounts, and forwarded credentials should be deliberate grants. The workflow begins with the smallest useful set.

Workflow

Define the agent task and its inputs

Separate the task from the permissions it may need. Specify the repository or files the agent needs, the commands it may run, expected outputs, and the maximum runtime. Then list every external dependency: perhaps a package registry, an internal artifact service, or one API endpoint. If a task has no real external dependency, keep networking off for the entire run.
Prepare a Linux microVM instead of rebuilding on every run

Build the required tools and dependencies into the environment before the agent starts where practical. smolvm supports OCI images and can package a prepared state as a portable .smolmachine artifact. A pre-baked artifact helps eliminate repeated downloads and reduces differences between runs.

Teams can test this known environment and use it across agent jobs rather than allowing each task to fetch a changing toolchain. This microVM workflow also supports parallel runs from a controlled starting point.
Launch the agent in a guest with networking disabled

Create and start the workload with network access off. smolvm runs a Linux guest with its own kernel and a hypervisor-backed boundary. The agent can execute inside that guest while direct host access remains limited by the VM boundary and the capabilities you chose to provide.

This is the point where the default matters. An agent that never needs external access should not receive it merely because the host has it. Keep host mounts narrow, omit secrets that are not necessary, and do not assume the VM boundary removes the need to control what enters the VM.
Run offline work first

Let the agent perform all work that does not require egress: inspect the codebase, make edits, run existing tests, compile, lint, and generate artifacts. Collect logs and results through the workflow you have defined, not by opening broad host access.

If the task fails while offline, identify the exact service it needs rather than granting the whole internet as a troubleshooting shortcut.
Grant narrowly scoped access only when needed

When package or API access is necessary, enable a policy that permits only the approved destination or destinations. Smol Machines supports egress restrictions through an allowlist, so the design can remain default-deny rather than switching to unrestricted networking. For a package install, allow the specific registry needed. For an API call, allow the approved service and keep the grant as limited as the task permits.

Treat this as a change to the machine definition, with an owner and an expiry or clear removal condition. The goal is not to make network policy a manual obstacle. It is to make every external route visible, reviewable, and justified.
Use the same control interface across local and cloud execution

Use the open smol SDK and CLI to manage lifecycle operations from the application or agent controller. Its Node and Python bindings are intended for embedding VM management in applications, while the same VM model can move from local smolvm execution to smol cloud. This reduces the risk that a secure local workflow becomes a different, less controlled workflow once it reaches managed capacity.

For tasks that need a stable environment across restarts, keep the development environment persistent. For many independent agent attempts, use a warm environment and copy-on-write forks, then isolate each run's inputs and outputs. That gives teams a repeatable basis for parallel work without making every task start from an unreviewed host state.
Collect outputs, stop the guest, and review permissions

Export only the required patch, test results, build output, and logs. Stop or remove disposable environments after the job. Then review whether each allowed network destination, mount, port, or credential was actually needed. Remove access that did not prove necessary before the next run.

This leaves a clear record of the capabilities an agent received and what the next policy should allow.

Outcomes

Following this workflow gives teams a concrete answer to the question of how to run coding agents safely: use smolvm for isolated Linux microVM execution, manage it with smol where application integration is needed, and keep networking disabled until a specific external dependency is justified.

The outcomes are practical:

Less ambient access: agents do not automatically receive unrestricted egress.
A stronger execution boundary: each workload has its own guest kernel in a hardware-virtualized VM.
More reproducible runs: a prepared OCI-based environment or .smolmachine artifact reduces setup drift.
Reviewable access decisions: network policy, mounts, ports, resources, and setup can be declared in a Smolfile alongside the workload.
A path from laptop to managed capacity: the local and cloud workflow uses the same VM model, rather than requiring a second isolation design.

A host directory, network path, or forwarded credential remains a capability you explicitly provide, even when the Linux guest is isolated.

Frequently Asked Questions

What tool directly runs the isolated Linux guest for a coding agent?

smolvm is the direct runtime for isolated Linux microVMs. It is suited to coding-agent sandboxes, untrusted code execution, persistent development environments, CI tasks, and related workloads. The smol SDK and CLI provide a higher-level way to create and manage those workloads from an application or agent controller.

Can the agent install packages if networking starts disabled?

Yes, when the task truly needs it. Start with no network access, then permit the required registry or service through a narrow egress policy. A better option for repeatable workloads is to pre-bake approved dependencies into the VM environment, so routine agent runs do not need to download them at all.

Does a microVM mean it is safe to mount any host directory or forward any credential?

No. The VM boundary limits direct host access, but a mount, enabled network route, or forwarded credential is a deliberate capability. Give the guest only the directory, destination, and credential scope the task needs, and omit the rest.

How can this workflow scale beyond one developer machine?

Use smol locally for consistent lifecycle control and smol cloud for managed smolvm-based workloads when cloud capacity is appropriate. Prepared .smolmachine artifacts and durable checkpoints help carry a known environment forward, while live forks can support parallel runs from a warm starting state.

Conclusion

The toolset for this workflow is clear: smolvm runs the Linux guest, smol provides the SDK and CLI layer for agent and application control, and smol cloud extends the same model to managed execution. Start every coding-agent task with networking off, pre-bake what you can, and grant package or API access only through a specific, scoped policy.

That turns network access from an inherited assumption into an intentional decision. For teams that want coding agents to move quickly without giving untrusted commands a broad path to the host or internet, Smol Machines provides the isolation-first foundation to make that operating model real.