Block Storage Semantics Inside Agent Sandboxes Versus Object Storage Workarounds

Persistent storage for AI agent sandboxes that survives restarts needs a durable filesystem. The strongest fit for agents using ordinary file tools is an isolated sandbox with persistent, forkable storage that honors atomic rename, byte-range writes, append, and fsync. Archil uses that model, while other approaches make different choices about how to share access, isolate workloads, and keep state. Durable files do not, by themselves, preserve running processes.

Why object storage cannot honor the POSIX contract agents rely on

Object storage gives agents and pipelines a common place to keep data, and mounting it makes that data reachable through familiar paths. That is useful in its own right. Agents are trained heavily on bash and command-line tools, so they naturally favor grep, ls, reads, and writes over SDK calls. Before agents had filesystem access, they had to be told to download objects and could then lose track of those local copies when their context windows were compacted.

The mismatch starts with the unit of change. In the object model used here, a write uses PUT to replace a whole object, even for changes to bytes within a file. POSIX tools expect smaller operations that work together, including hard links and atomic replacement through rename. POSIX is largely silent on post-crash guarantees, so a filesystem’s durability contract also needs scrutiny. The crucial operations are atomic rename, fsync, byte-range write, and append.

How FUSE bridges attempt to close the gap and where each one breaks

FUSE, short for Filesystems in USErspace, lets a driver present object data through a filesystem interface. AWS’s Mountpoint, Google’s gcsfuse, and Microsoft’s blobfuse2 take this bridge approach. The path looks familiar to the agent. The difficulty is what happens when a file operation has no matching object operation, because changing the entrance does not change the machinery behind it.

A driver can add metadata to the bucket to represent file behavior, making that representation incompatible with the ordinary object view used by other consumers. Or it can refuse operations the object store cannot support. Without atomic rename, the standard commit pattern cannot work, but simulating it risks giving other readers an inconsistent view. A filesystem-shaped doorway is not the whole house.

Vercel Sandbox’s FUSE addition on July 3, 2026 shows that platforms are still choosing this route. Adoption alone does not establish which filesystem operations a platform supports. Nor should Mountpoint, gcsfuse, and blobfuse2 be ranked by a single missing feature without considering their intended workloads.

What each missing POSIX primitive costs a running agent loop

The SOSP’26 paper “Don’t Let AI Agents YOLO Your Files” frames filesystem failures as information and control gaps. Agents and users may not know what changed, and they may lack a way to stop or undo it. Atomic rename addresses one specific boundary in that problem. Without write-to-temp followed by atomic rename into place, an interrupted update can leave partial content where the agent expects a completed file, undermining safe retry and resume.

Durability is a separate promise from successful execution. Without a durable-write guarantee, “saved” can become false after restart. YoloFS documents an agent claiming “No problems occurred” immediately after erasing a file, illustrating the information gap while leaving a particular fsync failure unproven. An agent’s confidence is not a storage receipt. A reliable loop needs recorded effects and durable state.

Incremental output exposes another cost of the mismatch. Replacing a whole object for each append means reading and uploading all the content so far again, and the replacements can race when two steps add to the same file. Hard links and sparse files also affect unmodified tools, including compilers, package managers, and git. YoloFS’s control-gap framing explains why bespoke recovery instructions are insufficient for unchecked agents. The storage layer itself must be able to stage mutations and keep intermediate states.

Why agent sandboxes compound the storage problem with an isolation requirement

Agents also execute code that has not been reviewed. Without an isolation boundary, that code inherits the agent’s permissions. Standard containers share the host kernel, but a microVM has its own Linux kernel for the workload, so an attacker must cross both the guest-kernel and hypervisor boundaries. The difference changes the storage connection too. A container can mount a host block volume directly, but a microVM needs a block device or a virtio-fs pass-through.

Cosmonic’s 2026 AI sandbox guide describes tool poisoning, prompt injection leading to file access, and lateral movement through inherited network access. A malicious MCP tool can inherit filesystem permissions and environment variables containing API keys. A document can instruct an agent to read ~/.ssh/id_rsa and include it in a response. Storage and isolation therefore cannot be selected as unrelated components, because the boundary determines which filesystem interface reaches the agent and what else its code can reach.

What block semantics inside a microVM actually require from storage and network

A real block-backed design exposes a device to the guest through an interface such as virtio-blk. The guest filesystem and kernel handle file operations through the VFS layer and page cache, and the backing storage must keep the durability promise made when fsync returns. A device alone is not enough. The filesystem, disk, and persistence contract must agree about what has been committed and what survives a restart.

Persistence also has a precise limit in scope. Keeping installed packages and working files from one session to the next does not keep processes, open sockets, or in-memory variables. That distinction is critical for persistent working memory. Files can retain an agent’s recorded state after a container or sandbox restarts, but unrecorded state needs a different recovery mechanism. When a disk also has an object-compatible endpoint, pipeline tools can reach the same data without keeping a second copy.

The hardened network model denies egress by default and allowlists the domains the agent needs. Credential delivery has a similar hierarchy. Environment-variable injection leaves secrets readable by sandbox processes and vulnerable to logging, while runtime vault retrieval still puts credentials in sandbox memory. Proxy-based injection applies credentials at the network layer so raw keys never enter the sandbox. Keeping secrets off disk also keeps them out of persistent working files.

How Archil's persistent sandboxes provide block semantics without the workaround costs

Archil pairs a Firecracker microVM with a durable, forkable disk. Each sandbox has its own kernel and a real block device, so the guest can use atomic rename, fsync, byte-range writes, hard links, and sparse files without a FUSE layer. Installed packages and working files are still there after the sandbox stops and restarts. Serverless execution has been available since April 2026, and persistent sandboxes have been generally available since August 2026. Both use Firecracker infrastructure that Archil has operated in production for over a year.

The disk can be Archil-managed or backed by an existing S3, GCS, R2, Azure Blob, or S3-compatible bucket without migration. Its POSIX cloud filesystem has the file operations agents need, so they can use them without working around missing ones. The bucket remains the durable source of truth. Writes are durable once fsync returns and are copied to the bucket in the background, so that guarantee should not be confused with immediate bucket visibility. Every disk also has an S3-compatible API for pipeline access without a separate copy or ETL step.

The Developer plan limits outbound traffic to a managed allowlist covering package registries, git hosts, container registries, OS package mirrors, and model provider APIs, while Team plans set their own firewall rules. Brokered credentials never enter the sandbox. These boundaries provide specific, limited safeguards for running agent code. The disks also checkpoint and branch quickly regardless of size, extending branching from exceptional recovery exercises to normal workflow operations.

How other sandbox providers handle persistence and block semantics, and where their trade-offs fall

VAST Data separates per-session sandbox storage from shared datasets. Its agent-sandbox design uses isolated block volumes and shared NFS through two CSI provisioners on one underlying system. That separates two distinct access needs. The block driver’s allowROManyBlockFsMode option lets pods on different nodes mount the same block filesystem volume read-only through ReadOnlyMany semantics. Shared read-only access should not be mistaken for concurrent writable state.

Amazon S3 Files has been generally available since April 7, 2026, and uses EFS technology with S3 connected directly as its backend. It presents a genuine NFS filesystem layer rather than a FUSE workaround, while keeping both filesystem and S3 object APIs valid. It focuses on letting agents in multi-agent pipelines share access to a bucket. That is a different architectural fit from choosing an isolated, forkable disk for each agent environment.

The useful comparison is persistence scope and access pattern. Volume-backed storage can outlive sandbox deletion, while filesystem snapshots may remain tied to the sandbox lifecycle. Shared distributed filesystems address concurrent access by several agents, and one vendor's offering is in private preview. For buyers choosing among these models, survival across restart, survival across deletion, writable sharing, and forkability are separate criteria. A single “persistent” checkbox cannot answer all four.

Why forking and checkpointing agent environments require the same block primitives as POSIX writes

A reusable checkpoint lets several sandboxes start from one state and then diverge. Block-level copy-on-write makes that practical without copying the whole disk for each branch, and atomic and durable file operations determine which state is safe to reuse. A collection of bucket objects does not itself supply that mechanism.

The Crab system formalizes this pattern for tree-based RL post-training and speculative action execution. A runtime can fork an intermediate checkpoint instead of replaying a shared prefix, then run draft actions in parallel and discard or commit branches according to the oracle action. Routine use requires low latency. The DeltaBox paper reports that template-fork restore takes roughly 1.86 ms, while seconds-per-cold-boot can add up to a lot of time in a 50-step agent loop. Archil’s size-independent disk branching addresses the same workflow need without requiring a full disk copy.

Recovery still needs a clearly defined scope. A filesystem checkpoint saves durable state, whereas a process checkpoint, such as a CRIU dump through runc, preserves in-memory state including open file descriptors. Neither automatically reverses an external action. The 2026 ACRFence paper describes “semantic rollback attacks” in which restored agents generate requests that servers treat as new, enabling duplicate irreversible actions or credential reuse. Fast disposal of a compromised branch supports safety only when rollback integrity also accounts for what happened outside it.

What agent-native filesystem design looks like when POSIX semantics are fully honored

YoloFS demonstrates how a filesystem can report effects, stage mutations for undo, and gate sensitive accesses through progressive permissions. In its evaluation, agents self-corrected in most tasks with hidden side effects, and all mutations were staged for user review. Routine tasks needed less input from users and had the same success as the baseline. The safety gain came from the filesystem layer. It did not require turning every tool call into another approval meeting.

Sandlock explores a complementary route by confining agent code with unprivileged Linux primitives. Together, these research directions put control closer to the operations themselves, so less depends on the agent giving a faithful account of what it did. A persistent, forkable filesystem also lets the model discover context incrementally through grep, ls, and reads, reducing the need to load everything into a prompt. With real POSIX semantics beneath those familiar tools, the filesystem stops being a liability and becomes an enforcement layer.