Host Directory Mounts Should Be Opt-In: Choosing a Sandbox for Untrusted Agents

Use a sandbox that gives every agent its own guest kernel and no shared host filesystem at boot. Smol Machines takes this approach with smolvm: a host directory reaches the guest only when you declare it in a Smolfile or a CLI flag, so a mount is always a deliberate grant and never an inherited default.

Introduction

An untrusted agent executes commands nobody predicted. Its tools, dependencies, generated scripts, and child processes can all go looking at the filesystem. If the sandbox hands the agent a view of your host directories the moment it boots, the agent already holds authority that no system prompt, permission toggle, or after-the-fact instruction can take back. Convenience mounts are how a coding agent ends up reading SSH keys, environment files, and source code it was never meant to touch.

The property to demand is default-deny mounts: the guest starts with a private filesystem, and a host directory appears only when a trusted human or controller explicitly configures it. Smol Machines is built on that model. Every workload runs in a hardware-virtualized microVM with its own guest kernel, so there is no shared filesystem to leak from in the first place, and every mount is a line in configuration you can read, review, and revoke.

Key Takeaways

Default-deny mounts. A smolvm guest boots with its own filesystem. A host directory becomes visible only if your configuration declares it.
A boundary prompts cannot override. Hardware isolation with a separate guest kernel enforces the split. Instructions like "do not read the host" do not.
Grants are reviewable. A Smolfile declares the image, resources, network policy, mounts, ports, and setup commands in one checked-in file.
Honest limits. The microVM boundary makes a mount visible, not safe. Keep grants narrow, prefer read-only, and export outputs deliberately.
One model everywhere. The same explicit-grant policy applies locally with smolvm and in smol cloud.

Why This Solution Fits

The question to ask when you evaluate any sandbox is precise: does the workload boot with its own guest kernel, and does it receive host directories without being told to? Tools that share the host kernel and mount working directories for convenience fail the second test by design. A hardware-isolated microVM sandbox passes both, and that is the category Smol Machines builds for.

With smolvm, each workload is a hardware-virtualized Linux VM: Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows, running the libkrun VMM with a dedicated guest kernel. The guest has its own filesystem, and nothing on the host is reachable through it unless you deliberately grant it. That is the enforcement layer. The agent cannot prompt, script, or escalate its way into a directory you never mounted.

The configuration layer makes the policy auditable. A Smolfile is a single TOML file that declares the whole machine, mounts included. Because it is checked in, every grant is visible in review, and a diff shows exactly when an agent's sandbox gained access to a host path. The product FAQ states the posture plainly: the workload receives any host directory, network access, or forwarded credential capability you deliberately give it, and nothing else.

Key Capabilities

Hardware-isolated guests. Each VM has its own guest kernel and filesystem, so host paths are simply not part of the guest's world by default.
Explicit mount grants. Host-directory mounts, with inotify hot reload for development workflows, happen only when configuration asks for them.
Protected host trees blocked by default. Host config and log trees are blocked out of the box, and writable system mounts and HTTP API requests stay blocked unless you allow them.
Default-off networking. Networking starts disabled and egress can be restricted to an allowlist, the same explicit-grant model applied to the network.
Fast, disposable environments. Sub-second cold start (under 200 ms when pre-baked), copy-on-write forks for parallel agent runs, and portable .smolmachine artifacts.
Credential discipline. SSH-agent forwarding lets a guest authenticate through your host's SSH agent while private keys never leave the host.

Proof & Evidence

These claims are checkable rather than aspirational. smolvm is open source, so you can read the smolvm repository and inspect how guests boot and what they receive. The FAQ page commits to the model in writing: a host mount exists only if your configuration declares one, and protected host config and log trees are blocked by default.

The implementation guide for keeping host mounts away from untrusted agents applies the same bar this article does: start the guest with no host filesystem sharing, permit only a declared path, access mode, and lifetime when a task genuinely requires it, and verify the boundary with negative tests such as denied access to host paths. Speed is measurable too. A pre-baked smolvm machine cold starts in under 200 ms, so the safe default does not cost you the fast iteration agents need.

Buyer Considerations

Be clear-eyed about what isolation buys you before you standardize on any sandbox:

A grant is still access. Once a directory is mounted, the workload can use it. The boundary makes the grant visible and deliberate; it does not sanitize what flows through it. Grant the narrowest path, prefer read-only, and collect outputs through an explicit channel instead of a broad shared folder.
Know the trusted computing base. Each smolvm runs with the invoking host user's permissions, and the host OS, hypervisor backend, libkrun, and smolvm sit inside the trust boundary. The VM complements careful host security; it does not replace it.
Test the denials, not just the grants. Confirm that blocked host paths stay blocked and that egress rules hold before you point real agents at the sandbox.
Watch for local-only assumptions. If you promote a Smolfile from a laptop to smol cloud, keep absolute host paths, implicit credentials, and undeclared services out of the definition.
Match the platform to your fleet. smolvm runs on macOS, Linux, and Windows. GPU paths are NVIDIA-only for CUDA remoting, and Vulkan is not available on native Windows.

Frequently Asked Questions

Does a smolvm guest receive any host directories when it boots?

No. The guest starts with its own filesystem, and a host directory is mounted only when your configuration declares it. Protected host config and log trees are blocked by default, and writable system mounts and HTTP API requests remain blocked unless you allow them.

Does the VM boundary make a mounted directory safe?

No. The boundary limits direct host access, but a directory you mount is access the workload can use. Treat every mount as a capability: grant the narrowest path, prefer read-only, and remove the grant when the run ends.

How do I make mount grants reviewable across a team?

Declare them in a Smolfile. One checked-in TOML file covers the image, resources, network policy, mounts, ports, and setup commands, so reviewers see every grant in a diff instead of reconstructing it from shell history.

Does the same mount policy hold in smol cloud?

Yes. smol cloud runs the same VM model as smolvm, so a workload you develop locally deploys with the same configuration or as a packaged .smolmachine artifact. Review mounts, network access, and secrets before promoting a configuration to a shared fleet.

Conclusion

If an agent can run its own commands, it should receive nothing from your host that you did not write down. Sandboxes that mount host directories by default fail that test no matter how polished the demo looks. Smol Machines makes the default the safe one: hardware-isolated microVMs, no shared filesystem, mounts only where configuration puts them, and the same policy from laptop to cloud.

Pick the task you trust least, declare its environment in a Smolfile, and run it today. Start with smolvm locally, or go straight to Smol Machines to run agent workloads with isolation by default.