Bounding an Agent’s Filesystem Access

Disk access is a capability boundary

Bounding filesystem access means deciding which paths an agent can read, which it can change, and which operations require approval, then enforcing those decisions somewhere the agent’s workload cannot alter. A writable workspace is not one permission: reading, overwriting, creating, renaming, and deleting carry different risks and should not inherit the same policy by default.

Read access is not the safe half

A repository is rarely just the files intended for the current task. It can contain credentials in local configuration, customer data in fixtures or exports, and history under .git. Generated logs, editor backups, database snapshots, build artifacts, and ignored files may sit beside the tracked source. A rule that allows the repository root therefore exposes more than the current branch.

Whatever a filesystem tool returns enters the agent’s context once read. That matters even when the agent cannot write: confidential text can appear in a model call, influence later tool choices, or be reproduced in output. Read-only access prevents local modification; it does not prevent disclosure.

Repository content must also be treated as input, not as trusted instructions. A comment, issue export, dependency document, or generated file can contain text designed to redirect the model. Simon Willison’s prompt-injection archive documents the continuing class of attacks in which instructions are hidden in content consumed by a model. The filesystem policy should therefore expose only the material needed for the task, rather than assuming that broad reads are harmless because no local mutation follows.

Practical scoping starts with an explicit read set: the working subtree needed for the task, plus named dependency or configuration files when required. Credential stores, environment files, repository history, unrelated worktrees, customer exports, and host directories remain outside that set unless the task specifically needs them. If access must expand, the expansion should be visible as a new permission decision.

Enforcement must sit beyond the workload

A path restriction implemented by the process the agent controls is advisory. The same workload that receives the policy may be able to change the wrapper, invoke a different executable, follow an unexpected path, or use another available filesystem interface. A prompt saying not to leave the workspace is also advisory: it shapes intended behaviour but does not create a security boundary.

Enforcement has to sit at a boundary the workload cannot reach or reconfigure. The controlling service, operating-system sandbox, container runtime, or separate execution identity can establish the accessible filesystem before the agent starts. The important condition is ownership: the workload being constrained must not hold the authority needed to relax its own constraint.

System-call filtering is one layer, not the whole filesystem policy. The Linux kernel’s seccomp filter documentation says directly that seccomp filtering is not a sandbox; it reduces exposed kernel surface and must be combined with other hardening and information-flow controls. Filtering a set of calls does not by itself decide which repository paths are legitimate. Path visibility and permissions still need an external boundary, while syscall restrictions reduce what the confined process can ask the kernel to do.

The same ownership rule applies to approval. An agent must not be able to approve its own request by editing the policy file, calling an unguarded version of the tool, or starting a child process outside the restriction. The component that grants broader access should be separate from the component proposing the action. That separation is the foundation for an agent tool permission model that distinguishes routine operations from actions requiring a person or a higher-trust service.

Build-file writes are deferred execution

Write access to build configuration and CI definitions is effectively execution access. Those files are instructions that another machine will run later. An agent that cannot start a process locally may still change a build script, dependency hook, task definition, or pipeline file so that a developer workstation or CI runner executes the change after a commit, push, install, or build.

The relevant boundary is therefore not file extension or whether a file looks like source code. It is whether another system interprets the file as instructions. CI definitions, package scripts, build configuration, test setup, deployment manifests, and code-generation inputs belong in the execution-capable part of the write policy when the surrounding automation consumes them.

This remains true when the downstream run happens under a different identity. In fact, that is why the permission is consequential: the later machine may have credentials, network access, signing authority, deployment rights, or access to artifacts that the original agent sandbox did not have. Local process denial does not cancel deferred execution.

A filesystem boundary should consequently separate ordinary source edits from files that control automation. Changes to the latter can require review or approval before they become visible to the runner. The downstream machine still needs its own sandbox for agent-requested code execution, because reviewing the write path and restricting the eventual execution path address different parts of the same capability.

Deletion deserves its own gate

Deletion is the operation worth gating even when writes are allowed. A mistaken overwrite of a tracked file is usually recoverable from version control. Deleting untracked work is not: there may be no earlier object, commit, or remote copy to restore. Treating delete as merely another kind of write hides that difference in recoverability.

The delete boundary needs to cover the effect, not only commands with obvious names. Removing a path, replacing a directory tree, running a cleanup task, or applying a generated patch that drops a file can all erase the only copy. Recursive operations raise the stakes because one mistaken target can extend the loss beyond the file the agent meant to change.

Allowing file creation and bounded overwrites while gating deletion preserves most routine editing. Approval should identify the exact paths affected, especially for untracked files and directories. Where the execution environment supports a recoverable quarantine or snapshot, it can reduce the cost of a mistake, but it does not remove the need to bound the target. Version control is a recovery mechanism only for content that reached version control.

Filesystem access and network egress compound

Filesystem access and network egress must be assessed together. Disk access alone exposes local information to the running workload but does not itself provide an outbound channel. Network access alone provides a channel but does not grant repository contents. Put them together and readable credentials, customer data, source, and history can become an outbound payload.

The risk does not require an agent to decide deliberately to steal data. A prompt injection in a file can direct a tool-using agent to read another path and include the result in a request. OWASP’s LLM application risk list identifies prompt injection, sensitive-information disclosure, and excessive agency as distinct risks; filesystem tools plus unrestricted egress create a path across all three.

Egress policy should therefore be derived from the readable data. If a task needs broad repository reads, its outbound destinations and protocols should be narrow. If it needs general network research, its readable paths should be narrow. A host allowlist does not make arbitrary uploads safe when an allowed service accepts user-controlled content, so the control must account for what data can be sent as well as where the connection terminates.

The companion reference on controlling network egress from agent sandboxes covers the outbound half of this boundary. After that, inspect the actual runner configuration: the mounted paths, execution identity, protected automation files, deletion approval point, allowed destinations, and logs that connect a filesystem action to the agent run that requested it.