What AI Agent Sandboxes on Modal and E2B Actually Store

An AI agent sandbox is compute, not storage: it spins up, runs code, and can be torn down at any moment, which means any file an agent needs to keep has to live somewhere outside the sandbox itself. Object storage is where that ends up in practice, mounted into the sandbox as a directory the agent reads and writes like any other. This article covers how that actually works across the real hosted sandbox providers the OpenAI Agents SDK supports, and exactly where an S3-compatible endpoint like AIOZ Storage's fits into it.

TL;DR:

• Agent sandboxes are ephemeral. Anything an agent needs to persist, uploaded documents, generated files, logs, has to be mounted in from external storage.
• The OpenAI Agents SDK defines mount types like S3Mount generically, but each of its 7 official hosted sandbox providers implements the actual mounting differently.
• Two of those providers, Modal and E2B, are independently confirmed to support custom S3-compatible endpoints, which is where AIOZ Storage fits.

Why Agent Sandboxes Need External Storage at All

A sandbox exists to run untrusted or model-generated code safely, isolated compute with its own filesystem, and that filesystem doesn't survive the sandbox's lifecycle by default. An agent analyzing a set of documents needs those documents available when the sandbox starts. An agent generating files, reports, images, processed data, needs those files to still exist after the sandbox that created them is gone. Mounting external storage into the sandbox's filesystem is how both directions get solved, without the agent's code needing to know it's talking to a remote bucket instead of a local disk.

The OpenAI Agents SDK's Manifest System

The OpenAI Agents SDK defines a Manifest system for exactly this: S3Mount, GCSMount, R2Mount, AzureBlobMount, and BoxMount are its documented mount types for making external storage available inside a sandbox. As of the SDK's native sandbox support, launched April 2026, there are 7 officially integrated hosted sandbox providers: Modal, Blaxel, Cloudflare, Daytona, E2B, Runloop, and Vercel. The Manifest concept is generic across all of them, a way to declare "this bucket should be available at this path," but the SDK's own documentation is explicit that the actual mounting mechanics are deferred to each provider's own implementation, not specified once at the manifest level.

Where the Real Mounting Logic Actually Lives

That per-provider deferral is not a documentation gap, it's a genuine architectural choice, and it means the honest answer to "does S3Mount support a custom endpoint" is: it depends which provider's sandbox you're running on. Two real, checkable examples:

Modal, one of the SDK's official providers, publishes its own ModalCloudBucketMountStrategy, which translates S3Mount, R2Mount, and GCSMount manifest entries into Modal's native CloudBucketMount volumes. Its configuration includes a bucket_endpoint_url field, documented as the S3-compatible endpoint URL, required specifically for non-AWS buckets. That field exists in Modal's own extension code, not the SDK's core manifest spec, which is exactly the "provider-specific" framing the SDK's own docs point to.

E2B, another official provider, mounts buckets using s3fs, a FUSE-based tool, run directly inside the sandbox. Its documented pattern for a non-AWS bucket, demonstrated against Cloudflare R2, passes a custom endpoint through s3fs's own -o url= flag alongside a credentials file:

await sandbox.files.write('/root/.passwd-s3fs', '<ACCESS_KEY_ID>:<SECRET_ACCESS_KEY>')
await sandbox.commands.run('sudo s3fs -o url=https://<endpoint> <bucket-name> /home/user/bucket')

Swap in AIOZ Storage's own access key, secret, and https://s3.aiozstorage.network endpoint, and the same command mounts an AIOZ Storage bucket into an E2B sandbox as a local directory, using nothing AIOZ-specific, just the S3-compatible surface every AIOZ Storage integration in this series already relies on.

Read-Only vs Read-Write Mounts

The same distinction that matters for a human team sharing access to a bucket matters for an agent mounting one. Modal's ModalCloudBucketMountConfig includes a documented read_only field alongside bucket_endpoint_url, and it's worth setting deliberately rather than leaving at whatever the default happens to be. An agent that only needs to read source documents or a dataset should get a read-only mount, full stop, regardless of what credential scope it's using underneath. An agent that needs to write generated files back out needs read-write, but only on the bucket it's actually supposed to write to, not the one it's reading from.

That mapping isn't unique to sandbox mounts, it's the same read/write split AIOZ Storage's access grants already enforce at the credential level: an access grant scoped to Read on a dataset bucket and a separate one scoped to Write on an output bucket means a misbehaving or compromised agent can't overwrite the data it was only supposed to read, even before the sandbox provider's own mount mode adds a second layer of the same restriction.

What This Means for a Specific Provider

If you're building on Modal or E2B specifically, AIOZ Storage is a legitimate mount target today, verified against each provider's own public documentation, not assumed from the generic manifest description. If you're building on one of the SDK's other 5 official providers, Blaxel, Cloudflare, Daytona, Runloop, or Vercel, this article does not claim the same thing works there. Each implements its own mount mechanics, and the only honest way to know is to check that specific provider's own docs the way this article checked Modal's and E2B's, rather than assuming every provider behaves the same way because they all speak the same manifest vocabulary.

Frequently Asked Questions

Does OpenAI's Agents SDK support AIOZ Storage directly?
The SDK itself defines generic mount types like S3Mount without specifying endpoint behavior; that's deferred to each sandbox provider. Two providers, Modal and E2B, are independently confirmed to support custom S3-compatible endpoints in their own mounting implementations, which is where AIOZ Storage fits.

Why doesn't OpenAI's own documentation just say whether custom endpoints work?
Because the actual mounting mechanics differ by sandbox provider. The SDK's manifest system is a shared vocabulary across 7 official providers, but each one implements the underlying mount differently, so a universal answer at the SDK level wouldn't be accurate for all of them.

How does E2B mount a non-AWS S3-compatible bucket?
Through s3fs, a FUSE-based mounting tool run inside the sandbox, with the target endpoint passed via its -o url= flag alongside a credentials file, demonstrated in E2B's own docs against Cloudflare R2.

What is Modal's bucket_endpoint_url field for?
It's part of Modal's own ModalCloudBucketMountStrategy, which translates the SDK's generic mount types into Modal's native storage volumes. The field is documented as required specifically for non-AWS buckets like R2 or GCS, the same slot AIOZ Storage's endpoint fills.

Will this same setup work on every OpenAI Agents SDK sandbox provider?
Not confirmed. This article verified Modal and E2B specifically. The other 5 official providers each implement their own mounting mechanics, and whether they support a custom S3-compatible endpoint has to be checked against that provider's own documentation individually.

What kinds of files typically get mounted into an agent sandbox this way?
Anything the agent needs to read that exists before the sandbox starts, like source documents or datasets, and anything it needs to persist after the sandbox ends, like generated reports, processed files, or logs.

Related Reading

• AIOZ Storage for AI and Data Pipelines: What's Actually Documented Today - the hub this article is part of, including the original summary of this claim.
• Offloading LangGraph Agent Checkpoints to AIOZ Storage - the other AI-agent infrastructure pattern in this cluster, agent state persistence instead of sandbox file mounts.
• Using AIOZ Storage as a Dataset and Model-Output Backend - the honest can/can't framing this article's provider-by-provider verification continues.
• AIOZ Storage Access Control: Macaroons and Access Grants - generating the access key and secret these mount configs authenticate with.

References

• OpenAI: Sandbox Agents Documentation
• Modal Blog: Building with Modal and the OpenAI Agents SDK
• E2B Documentation: Connecting a Storage Bucket to the Sandbox