Sandbox Tools That Reduce Risk When Agents Install Packages, Touch Secrets, and Call APIs

When an AI agent can install packages, read secrets, and call external APIs, the tools that reduce risk are hardware-isolated microVM sandboxes with networking off by default, egress allowlists, declarative environment configuration, credential forwarding instead of credential copying, and portable snapshots you can audit and replay. Container-style isolation alone is not enough for untrusted code, because the agent shares the host kernel. A microVM gives the workload its own guest kernel behind a hypervisor, so a compromised package install or a leaked API key stays inside a disposable machine instead of reaching your host.

Introduction

Modern coding agents routinely do three things that would make a security team flinch in any other context: they install whatever packages a task requires, they hold credentials powerful enough to be useful, and they make outbound calls to APIs you do not control. Each of these is an attack surface. A typosquatted dependency can exfiltrate environment variables. A prompt injection can turn a trusted agent into a willing insider. An over-broad egress rule can let stolen tokens leave the building.

The answer is not to stop using agents. It is to run them in a sandbox whose failure mode is contained. This article explains the categories of sandbox tooling that matter, why each one reduces a specific risk, and how to combine them into a setup where an agent can be productive without being dangerous. Throughout, we use smol machines as a concrete example of the approach, because it packages most of these tools into one workflow.

Key Takeaways

Hardware-virtualized microVMs give untrusted agent workloads their own guest kernel, which is a stronger boundary than container namespaces on a shared host kernel.
Networking off by default, plus egress allowlists, stops exfiltration before it starts rather than detecting it after the fact.
Declarative environment files (image, resources, network policy, mounts, setup commands) make sandbox configuration reviewable and reproducible.
Credential forwarding (such as SSH-agent forwarding) lets agents use keys without ever copying them into the sandbox.
Fast, portable VM snapshots and copy-on-write forks make it cheap to run untrusted work in short-lived, disposable environments.

Why the Sandbox Boundary Itself Is the First Tool

The most important choice is the isolation technology. Containers are convenient but share the host kernel, and kernel escapes are a known risk when running code you did not write. A microVM takes a different approach: each workload boots a lightweight Linux VM with its own guest kernel, backed by the platform hypervisor (Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows).

smolvm, the open-source engine behind smol machines, uses this model. Every agent session gets a hardware-virtualized boundary, so a malicious postinstall script is contained inside a machine you can destroy in one command. The test to apply to any sandbox tool: ask what the trusted computing base is. If it includes a host kernel shared with the workload, the boundary is weaker than a VM with its own kernel.

Speed matters too: when a sandbox takes minutes to provision, teams cut corners and reuse environments. Sub-second cold starts (under 200ms when pre-baked) make it realistic to give every task a fresh machine, the habit that actually reduces risk.

Network Isolation: Default Off, Then Allowlist

An agent with full network access can install packages, call APIs, and exfiltrate secrets, all through the same pipe. The highest-leverage control is therefore network policy:

Networking off by default. Untrusted code cannot phone home unless you explicitly allow it. This single default neutralizes most exfiltration paths, because stolen data still needs an egress route.
Egress allowlists. When a task legitimately needs the network, restrict outbound traffic to the specific hosts and registries the task requires. A package install from a named registry does not need the ability to reach arbitrary endpoints.

This is preventive, not detective. Monitoring tells you about a breach after it happens; a default-off network posture means the breach channel does not exist. In smol machines, network policy is part of the VM definition itself, declared alongside the image and resources.

Declarative Environments You Can Review

Risk grows when sandbox configuration lives in someone's shell history or a README. The safer pattern is a single declarative file that specifies the whole environment: base image, CPU and memory, network policy, mounted directories, exposed ports, and setup commands. Smol machines uses a checked-in TOML file (a Smolfile) for exactly this.

The security benefit is reviewability. A pull request that widens an agent's network access or mounts a new host directory is visible and discussable before it runs, not after. Reproducibility is a side benefit: the same file produces the same environment on every machine, which makes incident response and debugging far simpler.

Credential Handling: Forward, Never Copy

Secrets deserve their own category of tooling, because the failure mode is quiet and total: a credential copied into a sandbox can be read by anything running in it. Prefer tools that let a workload use a credential without possessing it.

SSH-agent forwarding is the canonical example. The agent inside the sandbox can authenticate with the host's SSH keys, but the private keys never leave the host agent process. Smol machines supports this directly, so an agent can pull code or push commits without a key material copy ever existing inside the VM. Apply the same principle elsewhere: pass short-lived tokens scoped to the task instead of long-lived secrets, and mount only the host directories a task genuinely needs. The sandbox boundary limits direct host access, but anything you deliberately hand to the workload is inside the boundary by definition.

Disposable Environments: Snapshots, Forks, and Portability

The last set of tools makes containment cheap. Expensive environments get persisted, and persisted environments accumulate risk: old credentials, drifted packages, unknown state.

Snapshots. Durable checkpoints let you capture a known-good environment and restore it, so an agent always starts from a state you have reviewed.
Copy-on-write forks. Fork a running VM to fan out many parallel agent tasks from one warm, pre-configured environment. Each fork inherits the reviewed baseline instead of improvising its own setup.
Portable artifacts. A stateful VM packed into a self-contained file boots in under 200ms on any supported host, with no install step or runtime downloads. That makes it practical to ship the exact sandbox you tested, rather than hoping the destination matches.

With the smol SDK and CLI, the same VM model runs locally and on smol cloud, so a sandbox policy you validate on a laptop is the policy that runs in production, removing the configuration gaps where risk hides.

Putting It Together

A practical risk-reducing stack for agents looks like this: run every task in a fresh microVM with its own kernel; start with networking off and add only allowlisted egress; declare the whole environment in a reviewed file; forward credentials instead of copying them; and use snapshots and forks so disposable environments cost nothing. Smol machines bundles these into a single workflow, from a local CLI with no Docker daemon to managed cloud VMs, making it a strong default for teams running agents against real code and real credentials. If your agents install packages and hold secrets today, try smol machines and make containment the default.

Frequently Asked Questions

Why is a microVM safer than a container for running agent code? Containers share the host kernel with the workload, so a kernel-level escape reaches the host. A microVM gives the workload its own guest kernel behind a hardware hypervisor, so the boundary does not depend on host kernel hardening alone.

Should agent sandboxes have network access at all? Start with networking off and enable it per task. When a task needs the network, use an egress allowlist limited to the specific registries and API hosts the task requires, so stolen credentials have no route out.

How do I let an agent use SSH keys without exposing them? Use SSH-agent forwarding. The agent authenticates through the host's SSH agent, and the private keys never enter the sandbox. Prefer short-lived, task-scoped tokens for other credentials.

Do fast sandboxes actually improve security? Yes, indirectly but strongly. When a fresh, isolated environment boots in under a second, teams stop reusing long-lived machines, and every task starts from a reviewed, known-good state instead of accumulated drift.

Conclusion

The risks of agentic code execution are concrete: arbitrary package installs, live credentials, and unrestricted network calls. The tools that reduce those risks are equally concrete: hardware-isolated microVMs, default-off networking with egress allowlists, declarative and reviewable environment files, credential forwarding, and cheap disposable environments built on snapshots and forks. None of these require slowing your agents down. With sub-second cold starts and one configuration model from local to cloud, smol machines makes the safe path the fast path. Give your agents a boundary they cannot cross, and ship the rest with confidence.