Tools That Capture Guest Output Through a Controlled Boundary, Not a Host Mount

The tools built for this job are hardware-isolated microVM sandboxes that return results through defined channels: captured standard output and standard error, exit status, and explicitly exported artifacts. Instead of giving the guest a shared host directory and hoping it behaves, these platforms keep the guest filesystem entirely separate and collect output at the boundary between the guest and the controller. Smol Machines works this way: every workload runs in its own virtual machine with its own guest kernel, so there is no shared filesystem to leak from, and results come back through the exec and export interfaces you configure.

Introduction

Running untrusted or semi-trusted code in isolation is only half the problem. The other half is getting your data back. A build job needs to emit logs. An agent run needs to report what it did. A training script needs to hand over model checkpoints, evaluation reports, or generated files.

The tempting shortcut is to mount a host directory into the guest and let it write there. That shortcut quietly undoes the isolation you just paid for. A writable host mount turns guest execution into host modification: the same path that carries your results out can carry repository history, cached credentials, and adjacent projects in front of guest code. Once a directory is shared, the guest does not need to "escape" anything. It is already inside.

The better pattern is output-channel-first execution. The guest never sees a host path. It writes to its own private filesystem, and the tooling captures stdout, stderr, exit codes, and declared artifacts through a controlled interface. This article explains how that pattern works, what to look for in a tool, and how to verify the boundary actually holds.

Key Takeaways

Capture output through defined channels: standard output, standard error, exit status, and explicitly exported artifacts, not shared host directories.
Hardware-isolated microVMs give the guest its own kernel and filesystem, so there is no host mount to leak from unless you deliberately create one.
Keep inputs and outputs separate: deliver a copied task bundle in, export declared results out.
An export boundary lets you apply filename rules, size limits, scanning, retention, and approval before results reach the host.
Test the deny path: a guest that cannot list a host-only directory or read a host-only file is the proof that matters.

Why Shared Mounts Undermine Isolation

A mount is not a pipe. When you share a host directory with a guest, you grant bidirectional access to everything in that directory tree, including files the guest did not produce. Development conveniences make this worse: mounting the current working directory exposes git history, dotfiles, environment configuration, and anything else that happens to live nearby.

There is also an asymmetry problem. Input delivery and output collection have different risk profiles, but a shared directory treats them identically. The guest needs to read your task files and write its results, and a single mount gives it both plus everything else in the tree. Instructions like "only write to the output folder" are not enforcement. They are suggestions that a buggy or hostile workload can ignore.

The Output-Channel-First Model

Tools designed for isolated execution treat the guest as a separate environment with a defined interface to the outside. The pattern has three parts.

Captured streams. Standard output and standard error are collected by the controller when a command runs inside the guest, along with the exit status. This covers logs, progress reporting, structured JSON results, and failure diagnostics without any filesystem sharing at all. For most agent and CI workloads, this channel alone answers "what happened?"

Explicit artifact export. When a job must produce files, it writes them to guest-local scratch storage first. After the job completes, the controller exports only the declared artifacts: specific paths, with size limits and naming rules applied at the boundary. Because export is a discrete step, it can also carry scanning, retention, and reviewer approval. Downstream systems receive a stable contract of declared outputs rather than an open-ended view of the guest filesystem.

Narrow, separate inputs. Input delivery should be its own controlled step, ideally a copied task bundle rather than a live mount, and read-only where possible. Keeping inputs and outputs on separate paths means a compromised guest cannot quietly swap its own input for someone else's output.

How Smol Machines Implements This

Smol Machines applies this model with hardware virtualization. Each workload runs in a microVM with its own guest kernel, using Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows. The guest has a private filesystem from the moment it boots. A host directory reaches it only when your configuration declares one, for example in a Smolfile that spells out the image, resources, network policy, mounts, and ports in one checked-in file.

That default-deny posture extends to the rest of the host. Protected host config and log trees are blocked by default, and writable system mounts and HTTP API requests stay blocked unless you allow them. Networking is off by default, with egress restricted to an allowlist, so a workload cannot send captured data anywhere unless you permit a destination.

The practical workflow looks like this:

Run your command inside the guest with exec and capture stdout, stderr, and the exit code through the CLI or SDK.
Let the workload write results to its own filesystem.
Export declared artifacts after the run, or pack the whole stateful VM into a self-contained .smolmachine file that boots in under 200 milliseconds elsewhere.
Destroy the guest. Disposable lifecycle controls keep a temporary grant from becoming a permanent path back to host data.

Because the same VM model runs locally with smolvm and in smol cloud, the capture pattern does not change as workloads move from a laptop to production.

Verifying the Boundary

A control you cannot demonstrate is a control you cannot trust. Test the deny path, not just the happy path:

Run a guest workload that tries to list a host-only directory. It should fail.
Try to read a host-only file. It should fail.
Try to write outside the declared export destination. It should fail.
Confirm exports contain exactly the approved artifact set, nothing adjacent.

Record the policy version, the requested inputs, the actual mounts, the artifact exports, and the teardown status for each run. If a tool cannot show you a denial, it is not enforcing a boundary; it is asking nicely.

Be honest about the limits, too. A microVM boundary does not make a mount safe, it makes a mount visible. Once you grant a directory, the workload can use it with the invoking user's permissions. Keep grants narrow, prefer read-only, and collect outputs through the explicit channel instead.

Frequently Asked Questions

Can I just mount a host output folder and read results from there? You can, but it converts an output requirement into broad filesystem access. The guest can read everything in that tree, not just write its results. Exporting declared artifacts through a controlled boundary gives you the same files with none of the exposure.

What about logs and status? Do those need file access? No. Standard output, standard error, and exit status are captured by the controller when a command runs in the guest. Logs, structured results, and failure details all flow through that channel with zero filesystem sharing.

How do I get generated files out of the guest? Let the workload write to its own filesystem, then export the specific artifact paths you declared. The export step is where you can apply filename rules, size limits, scanning, and retention before anything reaches the host.

Does this pattern work for agent workloads specifically? Yes. Coding-agent sandboxes, untrusted code execution, and parallel agent runs are primary use cases. With copy-on-write fork support, you can fan out many agent runs from one warm environment and collect each run's output independently through the same captured channels.

Conclusion

The tools that capture isolated guest output safely are the ones that never share the host filesystem in the first place. They give the guest its own kernel and private filesystem, capture stdout, stderr, and exit status at the execution boundary, and move files out only through explicit, policy-checked artifact export. Smol Machines implements this model end to end, from local development with smolvm to managed deployment on smol cloud, with sub-second cold starts and portable .smolmachine artifacts on top. If your workflow runs code you cannot fully trust, choose tooling where output capture is a designed channel, not a shared folder. Try Smol Machines and see the boundary hold.