A shared filesystem for AI agents — without handing out S3 keys

The standard way to give an AI agent file storage is also the standard way to have a storage incident: put cloud credentials in the sandbox and mount a bucket. The alternative is a brokered mount — a trusted process outside the agent holds the real credentials and exposes the workspace as an ordinary filesystem, while the agent holds only a short-lived, workspace-scoped grant. The agent gets full filesystem access; your S3 keys never enter the blast radius.

Why are credentials in agent sandboxes dangerous?

An agent process executes model-generated actions. Anything readable from inside it — environment variables, config files, instance metadata — must be assumed reachable by those actions, whether through prompt injection, a misfiring tool, or an ordinary bug. Cloud credentials rarely scope cleanly to "just the files this one agent should touch," so a leaked key routinely means read or write access to whole buckets. The pattern that is merely risky for human-operated servers becomes structural for agents, because the untrusted input is the operator.

How does a brokered mount work?

Three parties, one trust boundary:

• The agent requests a session on a workspace and receives a short-lived grant scoped to exactly that session.
• The mount broker — running outside the agent process — validates the grant and serves the workspace as a mounted filesystem. It alone holds object-store and database credentials.
• The storage backend only ever talks to the broker.

From the agent's perspective there is no ceremony: files at /workspace, standard tools, nothing to configure. From the security perspective, everything changed: nothing inside the sandbox is worth stealing.

What can a stolen grant actually do?

Little, briefly, and auditably. A grant authorizes one session on one workspace, expires on its own, and can be revoked instantly — revoke the session and the mount stops authorizing, with no key rotation cleanup afterward because there were no long-lived keys to copy. And because every write an agent publishes lands as a commit recording the actor, session, and run, misuse is visible in history rather than buried in access logs.

Doesn't sharing still require coordination?

Coordination is the other half of the problem, and scoped credentials alone don't solve it — two well-credentialed agents can still overwrite each other. That's why sessions are isolated forks rather than views onto one live tree: each agent works alone, and results merge through conflict-checked publishesthat refuse to silently discard a peer's work. Contrast this with bucket adapters like s3fs, where every agent on the host effectively holds the bucket keys and last-writer-wins is the merge strategy.

What does this look like in practice?

An agent platform provisions a workspace per project and a session per agent run. Sandboxes — E2B, Daytona, your own VMs — mount the session in under 100 ms at boot. Agents read shared inputs instantly, write freely in isolation, and publish attributable results. Humans review history, restore anything, and revoke anything, from outside the sandbox. No agent, at any point, could name the bucket its work lives in.