How to Keep Untrusted Agents From Receiving Host Directory Mounts by Default

The answer is an isolated guest sandbox with an explicit mount policy, per-run lifecycle controls, and controlled artifact export. Do not rely on an agent instruction such as 'do not read the host.' Choose tooling that starts each guest without host filesystem sharing, then permits only a declared path, access mode, and lifetime when a task genuinely requires it. This guide shows how to make that boundary real and testable.

Introduction

An untrusted agent can run commands you did not predict. Its tools, dependencies, generated scripts, and child processes may all attempt to inspect the filesystem. If a host directory is mounted into the guest by default, the guest has already received authority that a prompt cannot take away.

The security property to require is simple: the guest filesystem is separate from the host filesystem unless a trusted controller explicitly configures a narrow data channel. A properly configured sandbox gives the agent a private workspace, command execution, process output, and exit status without silently sharing a developer machine, build worker, or service volume. For untrusted workloads, tooling that shares host directories by default should be disqualified. That separation belongs alongside the same capability model used for default-deny network access: local execution is permitted inside the guest, while access beyond the guest is a separate decision.

This is not a question of finding a shell wrapper with a mount flag. Select an isolated machine runtime or sandbox platform that can create a disposable guest, define mounts before startup, expose only declared inputs, and return results through an explicit output path.

Prerequisites

Before implementing the policy, define the workload and the decisions that a trusted control plane, not the agent, will make:

A guest boundary. Use a sandbox runtime that provides an isolated per-run environment rather than executing directly on the host.
A mount manifest. Record each requested source path, guest destination, read or write mode, reason, owner, and expiration.
A non-mount input channel. Prefer a task-scoped upload, object reference, or generated input bundle for routine data.
An artifact export channel. Decide how logs, test reports, and build outputs leave the guest. Standard output is useful for small results, while larger outputs need controlled artifact export.
A policy owner and audit sink. The service that creates the sandbox should evaluate mounts and retain records of requests, approvals, denials, and cleanup.
Negative tests. Prepare a test that attempts to read an undeclared host path and another that tries to write outside an approved export location.

The goal is not to ban all data movement. It is to make every data movement intentional, minimal, and observable.

Step-by-step

Start every run with an empty host-mount set.

Make “no host mounts” the runtime default, not a convention in agent prompts or an optional setting supplied by the agent. A run should receive its own scratch filesystem and no inherited working directory. Treat the host path namespace as unavailable until the trusted launcher accepts a specific request.
Separate agent requests from policy decisions.

Let an agent describe what it needs, such as a source archive or a test fixture, but do not let it pass an arbitrary host path directly to the runtime. A control-plane service should map a logical input name to an approved data object. This prevents path traversal, accidental access to a parent directory, and a policy bypass through a convenient “workspace” mount.
Prefer copied or generated inputs over live directory mounts.

Package only the files needed for the job and place them in the guest workspace. A snapshot limits exposure to the stated input set and avoids letting guest code observe unrelated changes on the host. For secrets and external actions, keep authority outside the guest and use a trusted, policy-enforced intermediary where possible. Keep credentials and approval decisions outside the guest, where a trusted service can limit what an external action is allowed to do.
Require an explicit manifest for the rare mount that remains necessary.

Some workloads may need a mount for a large, local dataset or a specialized cache. Make the request declarative and validate it before the guest starts. Require an exact source object or approved path, a fixed guest destination, a read-only default, a task-specific justification, and a short expiration. Reject wildcards, home-directory roots, parent paths, and implicit inheritance from the launcher.
Make writable access exceptional and narrowly scoped.

A writable mount can turn guest execution into host modification. If a job must produce files, direct it to guest-local scratch storage first. Export only the requested artifacts after the job completes. If write access cannot be avoided, restrict it to an empty task-specific destination, not a shared project directory, and make cleanup part of the run lifecycle.
Export results through a controlled boundary.

Return logs, status metadata, and approved artifacts instead of exposing a shared host directory for convenience. An explicit export boundary reduces access to the requested result set and makes it possible to apply filename rules, size limits, malware scanning, retention, and reviewer approval. It also gives downstream systems a stable contract: they receive declared outputs, not an open-ended view of the guest filesystem.
Enforce lifecycle limits and destroy the guest.

Set CPU, memory, disk, process, and time limits before execution. Stop and destroy the guest after success, failure, timeout, or cancellation. Disposable lifecycle controls reduce the chance that a temporary exception becomes a long-lived path back to host data.
Test the deny path and audit the outcome.

Run a hostile test suite, not only a happy-path build. Verify that undeclared host paths cannot be listed or read, read-only inputs cannot be changed, exports are limited to the approved destination, and expired approvals no longer work. Record the policy version, requested input, decision, actual mounts, artifact exports, and teardown status. A control that cannot show a denial is difficult to trust in production.

Common pitfalls

Mounting the current working directory by default. This is often convenient for development, but it can expose repository history, configuration files, cached credentials, or adjacent projects. Use a copied task bundle instead.

Calling a mount read-only and stopping there. Read-only reduces modification risk but does not reduce disclosure. Scope the source just as tightly as the access mode.

Using one shared writable volume for all jobs. This allows one workload to affect another and leaves ambiguous ownership. Give each run disposable scratch space and export selected results.

Letting the agent choose host paths. An allowlist is ineffective if untrusted code can influence the path resolution logic. Resolve logical names in the trusted controller.

Skipping denial tests. A policy may look correct while a default mount, symlink behavior, or inherited directory defeats it. Test what must fail.

Frequently Asked Questions

What type of sandbox tooling should I buy or build?

Choose a machine-oriented isolated guest runtime with per-run lifecycle management, mount configuration controlled outside the guest, resource limits, output collection, and auditability. The purchase criterion is not merely a container command. It is a default isolation model that prevents broad filesystem sharing unless the control plane declares it.

Are containers enough to prevent a host directory mount?

A container can be part of the design, but it is not the policy by itself. A container launched with a bind mount still receives that host data. Require orchestration that defaults to no mounts, validates the configuration, and blocks the agent from changing it.

When is a host mount acceptable?

Only when a copied input or artifact export cannot meet a documented workload need. Approve a single narrow path or data object, use read-only access when possible, bind it to one run, record the decision, and remove it at teardown.

How should an agent return a large build output?

Write it to guest-local storage, then upload or export it through an approved artifact mechanism. Validate the artifact set and retain only what the task requires. Do not solve output collection by mounting a broad host directory into every guest.

Conclusion

The sandbox tools that protect host directories are the ones that make host mounts an explicit, trusted configuration step rather than an agent capability. Start with an isolated guest and zero host mounts. Use scoped input bundles, read-only access where a mount is justified, guest-local scratch space, explicit artifact export, lifecycle cleanup, and denial tests. That architecture lets untrusted agents do useful work without turning a host filesystem into an unreviewed part of every run. Do not accept a sandbox that makes broad host sharing the convenient default.