Per-Tenant Disk Provisioning Without a Storage Fleet

Isolated per-tenant storage for multi-tenant AI agent applications needs a durable disk for each workspace, an isolated execution environment, and tenant-scoped credentials. The key is to separate disk lifecycle from compute lifecycle, so files survive while idle compute stops. With on-demand microVMs and storage billed on active data, each customer can have a persistent workspace without the platform team running a storage fleet.

Why per-tenant disk provisioning is harder than it looks

An agent doing long-horizon work needs a place to keep work it has yet to finish. Installed packages, generated files, build artifacts, and working directories must still be there when the next session starts. An ephemeral sandbox throws that environment away when the task ends. The next session starts with housekeeping that delays progress. For a multi-step agent, that is a development machine with a cleaning crew that mistakes everything for rubbish.

A persistent sandbox preserves the filesystem across sessions, but that promise needs careful reading. Most persistent sandboxes limit persistence to files. A package can still be installed after a restart without the process that used it still running. Compute and disk lifecycles are often coupled by default, leaving teams to choose between keeping compute alive and rebuilding the environment.

One always-on VM or container per tenant can work at small scale. In that model, storage must be sized for peak use, compute stays running to hold state, and the fleet grows with the customer count. The workspace needs a way to outlive the machine running it.

What separating disk lifecycle from compute lifecycle actually means

A disk-first model gives the workspace its own lifecycle. The disk is created once per tenant or agent workspace, rather than once per session, and exists independently of the compute attached to it. When work begins, a microVM or container mounts the disk. When work finishes, compute releases it. Deleting the workspace takes a deliberate decision to deprovision it, so ending a session cannot delete it by accident.

Files, packages, and artifacts remain available without CPU and RAM being held open for them. Storage still exists and is still metered. The saving comes from releasing compute for a quiet workspace while keeping the existing environment ready for the next session.

Hibernation makes the separation especially easy to picture. A sandbox can pause, release CPU and RAM, and resume on the next network connection without losing its working directory. That lifecycle capability leaves process-memory preservation dependent on the persistent sandbox. Disk creation, compute attachment, and disk teardown need to be able to happen independently. If ending a session also ends the workspace, the separation is incomplete.

How do you keep one tenant’s agent from accessing another tenant’s workspace?

Attaching compute to a durable disk introduces another requirement. One tenant’s running code must not be able to read, overwrite, or observe another tenant’s files or processes. Storage permissions alone cannot provide that execution boundary. A durable workspace with porous execution isolation has solved only half the problem.

MicroVMs such as Firecracker, and VM-based isolation through Kata Containers, give workloads dedicated kernels and a hardware memory boundary. That is the safer default for arbitrary, unpredictable agent-generated code. Standard containers share the host kernel, so kernel exploits are still part of the threat model. SELinux and AppArmor use kernel-level Linux Security Modules to add mandatory access controls, but they do not add a hardware boundary. For more predictable workloads where density takes priority, gVisor offers a different tradeoff.

Credentials need their own boundary as well. A secret in a sandbox environment variable remains available to the code inside, however strong the hypervisor is. Prompt injection needs only a one-liner and an outbound network path to exfiltrate it. The production pattern is therefore to deny network egress by default and broker credentials at the network boundary, keeping them outside the agent’s reach.

For a multi-tenant product, those controls must follow tenant identity. Each agent needs access to that tenant’s credentials and must never hold another’s. Credentials should be resolved at call time from tenant context and kept outside prompts and shared environments. This makes the hypervisor, outbound network policy, and location of secrets separate, checkable parts of the isolation design.

How object storage falls short as the provisioning primitive for per-tenant agent disks

Shared-bucket prefix isolation with per-tenant IAM policies has a legitimate role. It can scope access to tenant objects while keeping durable data in an object store. Object storage is also a useful backend for connecting to other systems. The limitation is narrower than “buckets are unsafe.” A tenant’s authorized collection of objects is not, by itself, a disk that an agent can use as a persistent development environment.

The missing capabilities are filesystem semantics, workspace branching, and scoped environment provisioning. S3, R2, GCS, and Azure Blob do not expose the production fork primitive described here. IAM policies also need to be provisioned by a human or deployment pipeline. Running against a bucket does not give an agent acting for a tenant the ability to provision its own scoped credentials. A bucket is a good place for objects.

There is also an important distinction between enforced access control and application filtering. In a shared store accessed through broader credentials, a missing tenant filter on a similarity search or list call can expose another customer’s data. A correctly scoped IAM policy enforces the security boundary independently of the application filter. Neither filtering nor bucket permissions, however, supplies the isolated compute environment discussed above.

Retaining object storage for durability and integration while adding the disk interface the execution environment needs addresses these limitations. Mounting a bucket as a filesystem complements the existing backend. That distinction preserves the strengths of object storage without asking its API to act like a tenant workspace.

What the right primitive looks like — a disk that provisions, forks, and tears down per tenant

Archil’s serverless runtime implements the disk-first model by running one command in a fresh microVM against a durable disk. In its persistent sandboxes, installed packages and files survive stops and restarts without the application having to coordinate them. Each sandbox is a Firecracker microVM with its own kernel and persistent disk. The workspace remains the durable unit, while execution attaches when needed.

Archil’s serverless execution has been available since April 2026, and its persistent sandboxes have been generally available since August 2026. Its underlying Firecracker infrastructure handled production load for over a year before the product page went up. Millions of agents run on the platform every week.

Workspace branching is equally specific to the disk model. Checkpointing and branching each take about 90 ms whatever the disk size, so parallel attempts and rollbacks can run without the cost of a full copy. Pausing and booting a fork take additional time. That distinction keeps a storage-operation figure from masquerading as an end-to-end startup guarantee. Disks can also mount on many machines at once through shared or conditional mode.

Durability has a defined handoff point as well. Writes are durable once fsync returns and are stored redundantly across multiple Availability Zones. For disks configured with a data source, changes synchronize to the bucket in the background. Every disk is reachable through an S3-compatible API, so filesystem access does not cut the workspace off from the rest of the stack.

The network controls put the isolation model into practice. On Archil’s Developer plan, outbound traffic is limited to a managed allowlist of package registries, git hosts, container registries, OS package mirrors, and model provider APIs. Team plans and above set their own firewall rules, with egress denied by default. Brokered credentials keep secrets outside the sandbox. Ports remain private until explicitly exposed.

For teams that want to operate the infrastructure themselves, the Kubernetes SIG Apps Agent Sandbox project offers a different path. Its custom resources manage isolated, stateful workloads on Kubernetes, with stable identity and persistent storage. The project is runtime-agnostic, so isolation depends on the chosen runtime. It is a legitimate fit for Kubernetes expertise, but the team still operates the cluster and storage backend. That operational contract assigns the infrastructure responsibilities to the team.

Connecting tenant disks to the data they need without copying it

Copying large datasets into every tenant environment undermines elastic billing and creates stale-data and compliance problems. It also leaves the platform operator maintaining copies that exist only to make execution possible. The cleaner model mounts the existing bucket as a POSIX filesystem inside the sandbox. The agent gets familiar files while the data stays in the customer’s account.

A disk in Archil can be managed directly or backed by an existing S3, GCS, R2, Azure Blob, or S3-compatible bucket. Mounting a bucket needs no migration or ETL pipeline. The bucket remains the source of truth. Revoking access leaves the data where it is in the customer’s account, and cross-region movement requires explicit configuration. This provides a filesystem access layer over the existing object storage.

POSIX semantics give that access layer practical value. Agents are trained heavily on bash and file tools, and existing tools expect operations such as atomic rename, mmap, fsync, hard links, symlinks, and sparse files. Supporting those operations lets tools run unmodified inside the sandbox. Otherwise, “looks like a file” can become a surprisingly expensive promise. The interface must support the tool’s operations.

AWS’s 2026 S3 Files announcement illustrates the same direction. It mounts an S3 bucket into an agent’s local environment, using EFS technology to deliver full filesystem semantics. That does not make files the right interface for every workload. Databases remain better for data that fits a clean schema, while files suit unstructured data that would otherwise need to be forced into one. The goal is direct access through the interface appropriate to the workload.

Running thousands of tenant environments without sizing a fleet

The platform provisions a durable disk per workspace and attaches short-lived compute when an agent has work. Tenant count no longer implies an equal count of always-on VMs. Against that alternative, Archil meters disks on active data and compute only while a microVM runs. The operator does not have to reserve a storage fleet for the busiest possible version of every customer.

The security model must scale with that separation. Each tenant’s disk and execution environment need a hard boundary that does more than a tenant ID filter inside a shared application can do alone. A missing filter must not become permission to read another workspace. Call-time credential scoping extends the same rule to external tools and APIs. Each additional tenant should get an independently scoped environment.

Branching then becomes a scheduling concern. Parallel attempts within one workflow can use workspace branches, while their compute runs only when those attempts execute. For teams taking the Kubernetes route, Agent Sandbox’s SandboxWarmPool CRD addresses provisioning latency with pre-warmed pod pools. Near-instant allocation skips the wait for cold-start scheduling, but the team still has to run the cluster and storage backend.

Self-operated pools can improve allocation time, while a serverless disk-and-compute model removes the fleet-sizing obligation.