Your S3 Objects Stay Put When You Add a POSIX Filesystem Layer

An existing S3 bucket can be mounted as a POSIX filesystem without migrating its objects. Amazon S3 Files and Archil add a file interface while keeping the bucket as the durable source of truth, rather than moving, copying, or shadowing its contents. Existing S3-native workflows keep working, but file-write visibility and S3-object visibility follow different timelines.

Why object storage and file storage have historically been separate interfaces

S3 addresses objects by key, while POSIX software expects paths, directories, file descriptors, and operations such as open(), read(), write(), and rename(). A program built to traverse directories cannot simply substitute an S3 key for a local path and expect its file operations to work.

That gap produced the familiar download-process-upload pattern. Code that needed file semantics first downloaded objects to local disk, worked on them, and uploaded the results. Each function needed its own copy, which used ephemeral storage and added extra API calls and work to coordinate the stages. Client-side tools reduced the ceremony. The FUSE adapter s3fs and streaming wrapper smart_open still made S3 API calls underneath, so the bucket stayed the system of record while the tools gave clients an abstraction.

How can you mount an existing S3 bucket without migrating objects?

The defining feature of an additive POSIX layer is where the canonical data lives. The layer presents files over the existing bucket, rather than making another store the primary home and treating S3 as a sync destination. The bucket remains the durable backing store for an additional interface.

Amazon S3 Files, which went GA on April 7, 2026, mounts an S3 bucket as a native NFS volume built on Amazon EFS infrastructure. AWS describes both the filesystem API and the object API as accessible against the same data. Its trust relationship uses elasticfilesystem.amazonaws.comIts trust relationship uses elasticfilesystem.amazonaws.com because EFS supplies the NFS engine. That distinction is an easy IAM tripwire. The infrastructure-as-code resource types also make the infrastructure explicit, including AWS::S3Files::FileSystem, AWS::S3Files::MountTarget, AWS::S3Files::AccessPoint, and AWS::S3Files::FileSystemPolicy.

The two interfaces do not expose writes simultaneously. S3 Files makes writes durable immediately on the filesystem side and provides close-to-open consistency, so other mounted clients see a file's changes immediately after close. The changes show up in the S3 object representation roughly a minute later. AWS describes a write-back design that coalesces and flushes changes within 60 seconds, batching updates rather than generating an S3 PUT for every file write. That delay is not a relocation of the source of truth, but it is a boundary that mixed-protocol workflows must respect.

Archil applies the same architectural principle to S3, GCS, R2, and Azure Blob buckets, mounting them as a POSIX filesystem without moving or copying objects. It keeps the bucket as durable backing storage and offers an S3-compatible API together with the file interface. Both protocols work against the same data. Products that share this approach can still have different guarantees for when writes become visible.

What existing pipelines and tools can still do once the POSIX layer is in place

Event notifications still fire when objects land, bucket policies still control who has access, and lifecycle rules still apply. S3's per-key strong consistency continues for object API reads. That guarantee applies to the object representation, while a file write may still be waiting for write-back. A service that cannot mount NFS can keep using its S3 SDK as it is.

AWS illustrates this continuity with a document intelligence pipeline. An S3 event notification routes a document upload to an SQS queue, which triggers the first agent. The trigger mechanism stays unchanged. Inside the agents, file operations replace SDK calls, but the event-driven entry point does not need a new identity. Similarly, because Archil leaves the bucket as the system of record, existing S3-native notifications, policies, lifecycle rules, and per-key consistency continue while mounted clients use the file interface.

The AWS example spans EC2, Lambda, EKS, ECS on Fargate, and Bedrock AgentCore Runtime. Each uses familiar operations such as open(), os.listdir(), and write(). Mount configuration still varies by compute service. EC2 and EKS mount directly as root, while Lambda, ECS on Fargate, and AgentCore Runtime use a shared access point with UID/GID 1000.

There is a networking bill in this bargain. S3 Files requires a VPC, so Lambda functions must be VPC-attached. Functions needing outbound access also need an appropriate path, such as a NAT gateway, an IPv6 egress-only internet gateway, or VPC endpoints for the services they access. A function that only accesses the filesystem needs no egress path. This is manageable setup work, but “no data migration” does not mean “no infrastructure configuration.”

How shared file access over S3 changes the handoff pattern in multi-agent pipelines

Once agents share a filesystem, directories can become the handoff interface. One agent writes its output to a designated location, and another reads that location with os.listdir(). With close-to-open consistency, other mounted clients see the completed write without having to poll the S3 API. The filesystem becomes the integration layer, replacing custom object API calls, pagination loops, and retry logic for those handoffs.

AWS demonstrates this with five agents handling classification, risk scoring, compliance validation, report assembly, and executive summarization. They run concurrently across different compute services and pass work through shared directories, including intake/, analyzed/, validated/, reports/, documents/, and summaries/. The steps work without direct agent-to-agent communication or custom integration code. The five-service spread is illustrative. A real pipeline would choose its compute services on their own merits.

Files also keep working memory after a session ends. A model's context window is finite, and putting every intermediate result into the prompt increases cost and can degrade quality. Persistent files give those results another home. At the same time, access points offer per-agent POSIX identity scoping, so each agent can be limited to directory scopes that do not overlap.

What agent sandboxes need from persistent storage, and why file semantics fit

A shared handoff directory solves coordination between agents, but an individual agent also needs its own workspace to survive. Ephemeral sandboxes lose installed packages, intermediate files, and execution state when compute stops. Restarting then means rebuilding the environment. Object storage is the durable backing, while a filesystem gives agents the interface they already use through shell commands and file operations. With a persistent POSIX disk, the agent gets both without having to manage upload and download cycles.

Don’t Let AI Agents YOLO Your Files, the SOSP '26 paper on agent-native filesystems, describes how coding agents run hundreds of file operations and shell commands in each session with the user's own privileges. The filesystem is already their main surface for changing state. Object-storage ergonomics are therefore less important to the agent than controlled file semantics. Durability alone is not enough, however. Preserving a workspace also preserves whatever an agent did to it.

The same paper documents corruption, loss, and leakage through a systematic study of public incident reports. It calls for ways at the filesystem level to check what changed, undo changes, and control access. These controls belong close to the state being changed, so they do not rely entirely on how the agent behaves. Persistence saves the work, but it cannot judge the work.

Isolation at the sandbox level and what the compute boundary must provide

Storage permissions cannot compensate for an insufficiently isolated execution environment. A sandbox sharing a kernel with other tenants can expose paths to corruption or exfiltration even when storage access controls are correct. The boundary needs a concrete description. Shared-kernel containers using runc, user-space kernel interposition using gVisor, and hardware-enforced microVMs using Firecracker make different trade-offs between overhead and isolation.

gVisor intercepts system calls through its user-space Sentry kernel before they reach the host kernel. This reduces the exposed host-kernel surface and suits workloads where microVM provisioning latency is unacceptable. The interception has a cost, though. I/O-heavy agents making many file and API calls can accumulate overhead. Firecracker instead has hardware-enforced isolation with a separate guest kernel, while Sandbox0 documents how it uses gVisor in production with block-COW storage and gives a live-migration benchmark between nodes.

Network access is a separate control from isolation. Without default-deny outbound rules, a compromised agent can contact arbitrary endpoints. On cloud VMs, an unblocked instance metadata service, or IMDS, also lets a process request the node's IAM credentials outside the platform's authorization model. Of the ways to deliver credentials described here, environment variables are the weakest, while network-boundary injection keeps real tokens out of the agent process. Sandbox0 describes injecting credentials at the kernel network layer for that purpose.

Branching and checkpointing agent environments without full copies

A durable workspace becomes more useful when it can branch and roll back cheaply. Agents that try different approaches need checkpoints of both files and process state as well as somewhere to save their final answer. Full duplication makes every branch expensive. DeltaBox, the May 2026 paper, starts from the observation that consecutive sandbox states differ only slightly, so checkpointing should duplicate changes.

DeltaBox implements that idea with two coordinated mechanisms. DeltaFS freezes the writable filesystem layer and inserts a new one, turning updates into copy-on-write and rollback into a layer switch. DeltaCR restores process state by forking from a frozen template process backed by a CRIU dump. The paper reports a low-latency checkpoint and a 1.86 ms rollback. Those latencies support frequent exploration without paying for a complete copy at each step.

That changes the economics of tree search and reinforcement-learning rollouts. MCTS, candidate-selection methods, and Tree of Thoughts can explore more nodes within the same time budget when branching no longer incurs hundreds of milliseconds to seconds of state duplication. File branching becomes a metadata operation. This complements the additive-storage argument, but remains a distinct capability. A POSIX mount over S3 does not, by itself, promise copy-on-write branching or process-state rollback.

What to verify before trusting a POSIX-over-S3 layer with production data

The practical evaluation starts with the two visibility timelines. Check whether mounted clients get close-to-open consistency or something weaker, then find out how far behind the S3 object representation can be. Test what downstream object readers see. A pipeline that mixes mounted writes with SDK reads needs both answers to assess “consistency.

Next, establish where the canonical data remains. Confirm that writes flow back to the customer's bucket rather than a shadow store, and that revoking the tool's access leaves the data in the customer's account. For teams using GCS, R2, or Azure Blob, verify that those backends receive the same no-migration treatment. The bucket should remain the source of truth even when the mount is gone.

For products that also provide sandboxes, ask for the named isolation mechanism, default egress posture, and location of credentials. “Secure” is not an isolation mechanism. Separately, examine how long the underlying infrastructure has handled production workloads, rather than treating the product launch date as its whole history.

Finally, evaluate the controls needed for agents to correct themselves. The agent-native filesystem paper identifies introspection, undo, and access gating, including staged mutations and snapshots of intermediate states. Those capabilities require specific testing even with POSIX compatibility. Choose an implementation whose documented behavior fits the actual handoffs, restart needs, and recovery paths of the workload, then validate those paths against the existing bucket.