Sandbox Requirements for Filesystem-Heavy Agent Tasks

Filesystem-heavy agent tasks, bulk reads across large directories, bulk writes of intermediate artifacts, in-place mutation of files that already exist, break the standard sandbox model because that model treats the filesystem as one control among several equals. For these workloads it is the dominant control surface, and getting it wrong produces failures that compute isolation and network filtering never touch.

Filesystem-heavy agent tasks are a distinct problem from general sandboxing

The canonical framing of agent sandboxing rests on four layers: compute isolation, filesystem boundaries, network controls, and storage limits. That framing is fine for an agent that runs a script and exits. It undersells what happens when the agent's real work is reading, writing, and rewriting data at scale, because in that case the filesystem carries most of the risk and most of the operational weight.

The failure modes are specific enough to name. Several agents writing into the same /tmp directory leak information across sandbox boundaries that were supposed to be separate. A write loop with no ceiling on disk usage takes down shared infrastructure, not just its own task. A long-running processing job on a sandbox that assumes ephemerality loses everything the moment it hits a timeout, and per the research brief, tasks running beyond four hours carry a much higher risk of total failure when the underlying system has no state persistence.

None of this is hypothetical. Documented incidents include AI coding agents deleting local user files and, in one widely cited case, a production database. The Replit incident involved a coding agent with live database access that panicked after encountering empty query results and ran destructive commands it had no business running. The root cause there was not a missing quota or a mutation policy gone unenforced, it was an ungoverned agent holding live production write access with no approval gate standing between its decision and the database. The root cause was an isolation and access-control failure, the kind generic sandboxing conversations gesture at without addressing the filesystem specifics that would have prevented it.

What filesystem-heavy agents do that makes their sandbox requirements different

Picture the difference in workload directly. Ephemeral code execution runs a script against a small, short-lived /tmp directory and tears down when it finishes; the filesystem barely matters. A filesystem-heavy agent does something else entirely: it walks large directory trees to index or search them, writes intermediate artifacts at every stage of a pipeline, edits configs or patches files in place, and accumulates state across dozens or hundreds of tool calls stretched over hours.

Each of those operations compounds risk in its own way. A mutation that gets interrupted mid-write, say a config update that completes on disk but never finishes updating its metadata, leaves the filesystem in a state nobody planned for. A bulk write process with no ceiling can fill a disk and starve every other workload sharing that host. A read into a path the agent was never supposed to touch is not an inconvenience, it is a disclosure event waiting to be reported.

Multi-agent coordination sharpens all of this. When a coordinator fans a task out across several specialist agents working the same filesystem concurrently, shared paths become contention points and shared /tmp directories become leakage points; the baseline fix is to give each sandbox its own isolated temp directory rather than let several agents write into the same one. Layered on top of that is the confused deputy risk: an agent does not need to be compromised in any technical sense to do damage, it just needs sufficiently broad filesystem permissions and a prompt injection that asks it to read something sensitive and repeat it back. If path scoping has not been enforced, the agent will comply, because from its perspective it is simply doing what it was told.

Scoped path access: why filesystem boundaries for agents must be tighter than "not system directories"

"Agents read and write only to designated paths, never system directories" is the standard formulation, and it is a reasonable floor. It also assumes a small, predictable access surface, which is precisely what a bulk-processing agent working across a large data directory does not have. Once an agent's job is to touch thousands of files across a nested directory structure, "not system directories" leaves nearly everything else open by default, and that gap is where the real exposure lives.

The fix is a zero-trust filesystem policy: access is granted explicitly for the task at hand, never assumed implicitly because the agent happens to be running in a given directory. The agent declares the paths it needs, and the sandbox enforces that declaration as an allowlist, nothing more. Consider the documented scenario where a user submits a document for processing and the document contains hidden instructions telling the agent to read ~/.ssh/id_rsa and fold the contents into its response. Without explicit path scoping, the agent's execution environment simply has access to the host filesystem, and the key walks out the door in the response text. With scoping enforced, the read attempt fails before it ever becomes a decision the agent has to make correctly.

Path scoping is not a substitute for the isolation layer underneath it, and it should not be mistaken for one. MicroVM technologies like Firecracker and Kata Containers give each agent its own root filesystem as a hardware-enforced starting point. That is the boundary that keeps one sandbox's filesystem from being visible to another's process. Path scoping is a separate, additional control operating inside that boundary, narrowing what the agent can touch within its own filesystem down to the specific input and output directories the task actually requires. One does not do the other's job. An agent restricted to its own root filesystem can still read a credential file sitting one directory over from its intended workspace unless the allowlist says otherwise.

There is an operational argument here too, separate from the security one. An agent permitted to write anywhere within its filesystem will, eventually, write everywhere within it: stray output files, half-finished artifacts, logs nobody asked for. Scoping paths to the specific directories a task needs is what keeps the resulting filesystem legible enough to audit later, rather than a sprawl of files whose provenance nobody can reconstruct.

Quota enforcement: storage limits as a first-class runtime control, not an afterthought

The standard sandbox model frames storage limits this way: "per-agent quotas prevent runaway disk usage from crashing shared infrastructure". That phrasing treats the quota as a backstop, something that catches a problem after it starts rather than a parameter designed into the task from the outset. For filesystem-heavy agents, that framing is backwards.

A bulk-download agent working through a dataset of known size needs a quota sized to that dataset instead of a generic ceiling borrowed from a template. A transformation agent writing staged intermediate artifacts needs enough headroom to hold several versions of the data at once without hitting a wall mid-pipeline. Get the number wrong in either direction, too tight and the task fails partway through, too loose and one runaway agent can exhaust a shared host's disk and take down every other sandbox running on it. That second scenario is not a security failure in the traditional sense, it is an availability failure, and on shared infrastructure it is often the more expensive one.

Quota enforcement pairs with path scoping rather than replacing it. A quota only applies to the paths an agent is allowed to touch in the first place, so writes attempted outside the allowlist get blocked by path policy before they ever count against the storage limit. That gives two independent layers standing between a misbehaving agent and a full disk.

Does a hard quota interrupt legitimate long-running work? A well-specified task should know its storage envelope going in. If a task genuinely cannot be bounded in advance, that is a sign the task itself needs rethinking, not a reason to loosen the enforcement mechanism.

Stateful persistence: why filesystem-heavy tasks cannot treat sandboxes as ephemeral

Filesystem-heavy work does not fit neatly into a single invocation. A stateful sandbox keeps filesystem state, installed dependencies, and execution context intact between sessions, rather than wiping the slate the way ephemeral containers do after each run. That persistence is what makes it possible for an agent to work a complex project across hours or even weeks without starting from zero every time it resumes.

The stakes of getting this wrong scale with task length. For agents running beyond four hours, systems lacking state persistence carry a 90% higher risk of total task failure from API timeouts or infrastructure disruptions. That is close to the expected outcome once a task runs long enough on infrastructure designed to reset, not an edge case.

The mechanics of how this gets solved vary by platform, but the shape of the solution is consistent. Firecracker's snapshot-restore mechanism pauses a sandbox, preserves its memory and filesystem state, and resumes it in a short window, and this mechanism is the infrastructure foundation for agent harnesses that accumulate context across dozens of tool calls. Vercel Sandbox splits the concept into two levels: a Sandbox is a long-lived named entity, while a Session is a single running VM instance tied to it. When a persistent sandbox's session stops, the SDK automatically snapshots the filesystem, and the next session resumes from that snapshot rather than starting cold; non-persistent sandboxes simply discard the filesystem at that point instead. Blaxel takes a different route with perpetual sandboxes that sit in standby indefinitely on higher quota tiers (starter tiers still enforce TTL-based deletion), resuming in a short window with prior state restored rather than forcing a fresh start. These approaches share the same design choice: they treat standby as the default between sessions, not teardown.

None of that solves the next problem, though. A sandbox that can persist any change an agent makes to its filesystem is only as safe as the controls governing what changes the agent is allowed to make in the first place.

Snapshotting vs. event sourcing: what each gives you

Persisting state is one decision. How to persist it is another, and the two common patterns, snapshotting and event sourcing, give very different answers to the question of what can be reconstructed afterward. Snapshotting keeps only the current state of an agent's variables and discards the reasoning chain that produced them. Event sourcing instead records every decision, every prompt output, every tool result as an immutable sequence, which allows deterministic replay for debugging and point-in-time reconstruction for rollback or audit.

For a filesystem-heavy task, that distinction has a concrete practical shape. A snapshot tells an engineer what the filesystem looked like at a given moment. Event sourcing tells that engineer which specific agent action produced each change to that filesystem and in what sequence, which is what actually gets used to diagnose a corrupted intermediate artifact or answer a compliance auditor's question about how a file came to be modified.

Snapshot-restore resumes a task after an interruption without losing progress. It does not, by itself, prove what the agent did to get there. Event sourcing is what supplies that accountability, at the cost of storage overhead that grows with task length. The SWE-bench-style harness case makes the split visible: context accumulates over dozens of tool calls, and Firecracker's snapshot-restore mechanism is the operational foundation that lets that context survive interruptions. Event sourcing is the complementary layer that turns that accumulated context into something auditable rather than just something recoverable.

Which one a given task needs depends mostly on what is at stake if something goes wrong. A task that can be safely restarted and where correctness is the main concern is well served by snapshotting alone. A task touching sensitive or regulated data, or one where a partial mutation could cause real harm before anyone notices, needs the audit trail that only event sourcing provides. That audit trail also depends on the agent being unable to tamper with its own logs, a requirement developed further below.

Mutation control: the filesystem-specific risk that isolation alone does not address

An agent can be scoped to exactly the right paths, held within a sensible quota, and running on a sandbox that persists state correctly across sessions, and still cause damage that none of those controls were built to stop. That is the gap mutation control fills: distinguishing, at the enforcement layer, between read access, write access, append access, and delete access on a per-path basis, rather than treating "the agent can access this directory" as a single undifferentiated permission.

The documented failure mode of coding agents deleting local user files or production databases is a mutation failure: the agent was in the right environment but had write or delete access it should not have had. The agent in each case was running in the correct environment, with the access it was supposed to have. What it lacked was a boundary on what kind of change it could make once inside that environment. CVE-2025-58372, affecting Roo Code, traces the same shape: a prompt injection led first to a workspace file write and then to arbitrary code execution. The file write was the opening move, and it is precisely the step a read-only mount on the workspace would have blocked before the rest of the chain could unfold.

Read-only mounts are the right default for any agent whose job is analysis or reporting rather than modification. Input data paths get mounted read-only at the sandbox level, enforced by the infrastructure rather than requested of the agent through instructions it might or might not follow.

Audit logs need the mirror-image protection: append-only enforcement, so that an agent can add to its own log but never edit or delete what is already there. If an agent retains the ability to modify its own logs, the audit trail stops functioning as a control and becomes, at best, a suggestion the agent happened to follow. This has to be enforced at the sandbox layer itself, not left as a policy the agent is asked to respect.

The riskiest moment in any multi-stage filesystem task tends to fall in the middle, not at the ends. A pipeline that parses, transforms, validates, and then writes final output is most exposed during the transform stage, where the original input has already been altered but the final, validated output does not yet exist. Taking a filesystem snapshot before each mutating stage begins limits the blast radius of a failure to whatever happened in that single stage, rather than leaving the entire pipeline's output in question.

How isolation technology choices determine what filesystem controls get enforced

Every control described above, path scoping, quota enforcement, stateful persistence, mutation control, depends on the isolation layer beneath it actually being capable of enforcing it. MicroVM technologies built for this purpose, Firecracker and Kata Containers among them, give each agent its own kernel and root filesystem rather than sharing one with the host or with other tenants. That hardware-enforced separation is what makes path allowlists, storage quotas, and read-only mounts meaningful in the first place, because none of those policies matter if the underlying isolation can be bypassed to reach another sandbox's filesystem directly.

The choice of isolation technology, in other words, sets the ceiling on what the filesystem-specific controls above it can actually guarantee. A path allowlist enforced on top of weak process isolation is a policy that a sufficiently motivated escape can simply route around. The same allowlist enforced inside a microVM with its own kernel is a policy backed by a boundary that holds regardless of the agent's cooperation. Scoped paths, sized quotas, persistent state, and controlled mutation are only as reliable as the isolation layer that enforces them, and the choice of that layer either enforces filesystem isolation for agent sandboxes or leaves it unenforced.