One Mount Command for S3 GCS R2 and Azure Blob With No Data in Transit

An existing S3, GCS, R2, or Azure Blob bucket can become a mounted directory through a unified POSIX interface, without first migrating its objects or building an ETL pipeline. Agents and legacy tools can then use file calls to access each provider. “No data in transit” means no separate migration copy, while reads still cross a network. That mount needs to work with the right egress pricing, sandbox isolation, and durable storage.

Why AI agents reach for file paths instead of object storage APIs

An agent given a CSV is likely to reach for pandas.read_csv("/mnt/..."). The same preference is visible when it calls open(), shells out to rsync, or runs git. These are familiar tools from its training. Models have learned disproportionately from bash and command-line workflows, so a file path gives them an interface they already understand.

Object stores speak a different language by design. Their data sits behind HTTP APIs rather than a native POSIX interface, leaving a structural gap between where information lives and how agents expect to use it. Handing the agent an SDK fills that gap with another tool, more instructions, and more context to manage. Each provider-specific workaround adds to the burden and accelerates context rot. A mounted directory removes that extra translation work from the agent’s reasoning, rather than asking it to become a part-time storage administrator.

How FUSE bridged the gap — and where it still does

Filesystem in Userspace, or FUSE, lets a custom filesystem run in userspace without changing the underlying storage. That makes it possible to present an object store as a directory. The approach remains useful for a single-provider setup. Mountpoint for Amazon S3, Google’s gcsfuse, and Microsoft’s blobfuse2 each serve their own store, while geesefs and s3fs-fuse handle S3-compatible endpoints, including R2.

Those drivers do not behave as interchangeable parts. In the same-VM, same-bucket, same-workload comparison described in the brief, geesefs delivers much higher small-file warm-read throughput by pipelining requests and using the page cache, while s3fs serializes per-file work. With four stores, a team can end up keeping four installations running, each with its own mount commands and behavior profiles. The directory looks ordinary. The plumbing does not.

Sandbox restrictions add another wrinkle to that plumbing. Drivers such as blobfuse2 and gcsfuse require --cap-add SYS_ADMIN and access to /dev/fuse, which many hardened microVM configurations deny by default. A Firecracker-backed environment needs FUSE passthrough to be set up so that mounting can work. Both command syntax and whether the compute boundary permits the driver at all matter.

What a single mount interface actually does differently

A storage-agnostic mount layer handles the translation for each provider behind one command and one filesystem interface. Archil presents S3, GCS, R2, and Azure Blob buckets as mounted POSIX filesystems, so agents can use open(), read(), write(), and shell commands without learning each API. The agent sees a directory either way. Its documented surface also includes fsync(), atomic rename, hard links, symlinks, and sparse files, allowing existing tools to use their normal file operations.

The bucket remains the source of truth, rather than becoming an input to a separate migration job. Reads fetch objects as they are needed, and synchronization sends writes to the bucket. The durability distinction is important here. Writes are durable when fsync() returns, while background synchronization to the bucket follows, so durability must not be confused with completed bucket upload. Revoking the mount’s access leaves the customer’s data in the customer’s account.

R2 supports the S3 API closely, GCS offers interoperability mode, and Azure Blob has a different REST API and SDK. With a unified layer such as Archil’s cloud file system, that translation stays internal, while an S3-compatible API also lets other applications access the disk without adopting the mount interface. None of this establishes cross-client locking or instant visibility. Those are separate coordination promises.

Why the provider you mount from determines your egress bill

An on-demand read still moves bytes from storage to compute. Avoiding a migration copy does not erase the network bill, because the provider prices that journey independently of the interface used to request it. A mount changes access while leaving storage and compute in their existing locations. An agent outside AWS reading an S3 bucket can therefore incur outbound transfer charges even though nobody copied the bucket in advance.

Cloudflare’s official pricing page states that R2 charges no egress fees at any volume as a permanent policy. The hyperscalers generally offer free transfer for relevant in-network paths, including S3 to EC2 in the same region and GCS to a Compute Engine VM in the same region. Traffic leaving those networks incurs egress charges that can exceed storage costs at scale. R2 can consequently serve as an interchange layer for agents spread across clouds without charging R2 egress on their reads.

Compute location and storage should be chosen together. Workloads near their storage can use in-region transfer, while readers in other clouds have a reason to choose zero-egress storage. With Archil’s storage-agnostic interface, agent code can use the same file operations when the backend changes. Accessing an existing bucket needs no migration, but relocating its contents remains a separate decision.

Isolation requirements that a mount-capable sandbox must also satisfy

A mount makes it easy for agent-written code to get at data. That code can also exfiltrate files, make arbitrary writes, or expose credentials if the surrounding environment permits it. Storage access expands the security stakes immediately. Standard containers share the host kernel, making that boundary insufficient on its own for untrusted agent-generated code.

MicroVMs provide a hardware boundary and their own guest kernel, while gVisor uses a userspace kernel with different compatibility tradeoffs. Fly.io Sprites reached general availability on January 9, 2026, using persistent Firecracker microVMs. Northflank uses Kata Containers with Cloud Hypervisor for CPU sandboxes and gVisor for GPU sandboxes. These production approaches have different compatibility tradeoffs. gVisor’s documentation notes unsupported and partially implemented syscalls, which can affect Linux software, including filesystem drivers.

To assess those boundaries, teams should ask how the sandbox supports mounts without silently weakening its restrictions. Any required FUSE passthrough should be documented, as should the hypervisor, default outbound-network policy, and location of secrets. Outbound access should stay off until it is explicitly allowed, and credentials should be injected at the network boundary to keep them out of agent code. “Secure sandbox” is a pleasant phrase. Checking its architecture requires those details.

Persistence and shared access across agent sessions and machines

Isolation protects a running session, but persistence makes its work useful after that session ends. Rebuilding on every restart means reinstalling packages and losing accumulated local context. An isolated environment can still be forgetful. For multi-session work, installed packages and files need to survive stops and restarts.

Sprites demonstrates that pattern with persistent microVMs that hibernate when idle and wake on demand. Its filesystem-state checkpoints can save state without interrupting the running environment, but they do not include process memory. A saved filesystem and a saved running process are different forms of persistence, even when both get called a checkpoint.

FUSE clients can maintain separate local views, so simultaneous writers may diverge. Advisory locks coordinate processes within a single machine. Multi-agent writers need clear ownership or stronger documented backend coordination because they cannot count on instant cross-client visibility. Storage should also be elastic and metered on active use, since a minimal session and a long research task can differ by several orders of magnitude in disk consumption.

Branching and checkpointing agent environments in milliseconds

A durable workspace becomes more useful when an agent can branch it for parallel attempts and return to an earlier state after a failed one. Full-state duplication makes that pattern expensive. Millisecond branching, independent of disk size, turns rollback from emergency cleanup into an ordinary part of execution. It also keeps parallel exploration from multiplying the cost of the entire workspace.

The DeltaBox paper from Shanghai Jiao Tong University, submitted in May 2026 as arXiv identifier 2605.22781, targets the repeated work in checkpointing highly similar states. DeltaFS organizes file states into layers, freezes the writable layer during a checkpoint, and uses copy-on-write updates, with rollback handled by a layer switch. DeltaCR handles process state incrementally and rolls back by forking from a frozen template process. The paper reports checkpoint completion in 14 ms and rollback in 5 ms in evaluations on a software engineering benchmark and RL micro-benchmarks. Those are two distinct operations.

A claim that a disk branches in milliseconds regardless of size is separate from those research results. Filesystem branching also does not, by itself, orchestrate parallel candidate actions and select the best result. Billing on active data rather than allocated capacity can make the storage side viable, because each branch need not be charged as another full disk.

Per-tenant storage isolation when agents run for thousands of customers

Agent multi-tenancy involves more than separating database rows. Agents hold live API keys, retain memory across requests, and execute authenticated tool calls, all of which need tenant boundaries. A shared deployment is not a sufficient partition. Raw uploads, parsed text, and chunk stores need tenant-scoped prefixes or buckets, and storage policies must tie those places to tenant context as well as checking access in the application.

AWS Prescriptive Guidance describes siloed, pooled, and hybrid models for agentic AI multi-tenancy. Siloed tenants receive dedicated infrastructure, including containers, credential vaults, databases, and LLM API keys, at the highest cost and isolation level. Pooled tenants share infrastructure and rely on application-layer filtering, which gives them the lowest cost and the weakest isolation. Hybrid deployments share compute and use per-tenant credentials at the control plane to enforce boundaries. The guidance for databases calls that middle ground Bridge.

At the storage layer, per-tenant encryption can use envelope encryption with keys held in AWS KMS, Azure Key Vault, or Cloud KMS. Credentials should be proxy-injected, scoped to the tenant’s sandbox, and logged per request, because a shared API key obscures tenant-specific audit records. A bucket mounted for each tenant lets storage enforce its own boundary, so application code is no longer alone in handling prefix filtering. Revoking that tenant’s mount removes its access while leaving its data in its own account. Persistence must keep the tenant boundary in place along with the files.

How to choose a provider and mount strategy given these constraints together

Provider selection starts with where compute runs relative to the data. For AWS-native workloads, S3 with a storage-agnostic mount layer combines in-region transfer with features such as Access Points and event notifications. GCS fits pipelines already using BigQuery, Dataflow, or Vertex AI against the same data, especially when compute remains in-region. Azure Blob fits Microsoft-centric environments, while ADLS Gen2’s hierarchical namespace supplies directory operations such as atomic rename and move for Spark and Databricks workloads. R2’s zero-egress policy changes the cost for readers in different clouds.

The next decision is whether one provider-specific driver is enough or the workload needs a common interface across stores. A single-provider FUSE setup remains an option, subject to its behavior and sandbox permissions. A unified mount cuts down on code for each provider, though the backends still differ. Teams should check whether the documented POSIX operations, synchronization behavior, and cross-machine coordination work with the tools they run. They should also examine how long the underlying filesystem has operated in production, rather than treating a product announcement as an infrastructure track record.

Those choices must then hold within each tenant’s security boundary and across restarts. Cheap reads do little good when untrusted code gets unrestricted credentials, and writers can still conflict even when a disk is durable. The constraints meet in one architecture. A sandbox that is its own microVM, with a persistent, forkable disk that mounts S3, GCS, R2, or Azure Blob against the tenant’s own bucket, brings isolation, continuity, and storage partitioning together. Its value is that the agent can keep using an ordinary directory while the system handles the harder boundaries underneath.