Scaling a multi-tenant AI agent product to thousands of tenants is a storage, credential, lifecycle, and compute problem. The durable boundary should be each tenant’s disk, with its own identity, access scope, and usage-based cost. That boundary works only when provisioning and governance grow together. Otherwise, a fleet of neatly isolated disks becomes a fleet of neatly forgotten liabilities.
Why logical partitioning breaks when AI agents run at scale
Teams often check tenant_id at the HTTP gateway, but agents leak state further inside the execution graph. A sub-agent makes a retrieval call without the right metadata filter and gets pieces of another tenant’s index. The response looks plausible and throws no error. There is no stack trace to flag the leak. Omnithium’s May 2026 architecture guide describes this gap between gateway checks and internal tool calls or retrieval chains.
Standard web multi-tenancy assumes stateless requests, predictable resource use, and deterministic output boundaries. Agents violate all three. Their context windows can absorb the wrong tenant’s data, and stateful, re-entrant execution can propagate that contamination into later calls or sessions. Meanwhile, heavy-tailed token consumption makes fixed allocations wasteful for light users and inadequate for heavy ones. HydraDB’s 2025 analysis identifies continuous per-tenant metering as the response to that uneven demand.
Silent contamination makes diagnosis especially expensive after growth. A customer or compliance audit may expose the breach only after it has spread through persisted state. Remediation then means tracing every retrieval path, tool executor, and memory manager, rather than fixing the gateway check that looked sufficient at launch.
The three isolation models teams actually reach for, and where each breaks down
The Silo model gives each tenant a separate runtime, vector index, and API endpoint. It offers strong blast-radius containment for regulated customers with contractual data-residency requirements. That separation comes with a standing operational bill. Tenants still use baseline resources when idle, and updates must reach hundreds of separate stacks. Omnithium describes the model as “costly and operationally complex”.
The Pool model shares infrastructure and filters queries by tenant_id, giving low-risk tenants a lower-cost home. Its weakness is the application’s responsibility to apply every check. One missed filter can become a leak. Prompt injection makes the distinction sharper because an LLM can be persuaded to request restricted data. HydraDB argues that the database execution plan must turn down such requests because prompts or application filters alone cannot be trusted to do so.
Bridge combines Pool for low-risk tenants with Silo for high-risk ones. It pays for stronger separation where classification requires it. However, retrofitting Bridge means adding scope to retrieval paths that were never instrumented. Omnithium recommends designing for Bridge from the start, even when launching with Pool. These models choose how to share or separate stacks, but do not make the tenant’s disk the durable identity primitive.
Why the disk, not the server, is the right isolation boundary for per-tenant agents
An agent’s working environment is made up of its installed packages, files, conversational history, and tool state. The server running it is interchangeable. That state is not. A persistent disk lets the environment survive restarts without rebuilding or remaining attached to a particular compute instance. Agents trained heavily on bash and file tools can use the environment without bespoke MCP tools or extra context devoted to explaining them.
Archil treats persistent disks as that structural boundary for agents running in Firecracker microVM sandboxes. Each tenant can use a managed disk or mount its own object-storage bucket as a POSIX file system. Compute is temporary, while the disk keeps the environment. The important change is where access gets enforced. Reaching another tenant’s disk requires an explicit mount or credential grant, rather than merely a missing filter inside shared retrieval.
That separation also changes what onboarding provisions. A new tenant needs a disk with a stable identity. Credential scope can then follow the resource that actually contains the tenant’s state, while compute can change without redefining ownership.
Provisioning a disk per tenant at each stage of growth
For tens of tenants, disk provisioning can be manual or semi-automated. An API call creates the disk at onboarding, and its ID enters the platform’s tenant data model. Ownership starts with that durable reference. Because Archil’s cloud file system supports mounting disks on multiple machines and access through an S3-compatible API, provisioning need not repeat whenever compute starts. Its serverless execution can also run onboarding commands in a fresh microVM without a persistent sandbox.
At hundreds of tenants, creation becomes part of the onboarding pipeline, together with identity provisioning and credential registration. Salesforce’s BYOP platform separates platform infrastructure from each team’s reasoning logic, illustrating the same ownership principle. Runtime quotas still need attention at this stage. AWS Bedrock AgentCore has a default quota of 1,000 agents per AWS account, adjustable through Service Quotas, while disk-centric provisioning separates storage creation from runtime allocation.
At thousands of tenants, onboarding must be programmatic and idempotent. Disk creation, credential issuance, and firewall rules belong in the same onboarding transaction so retries do not leave orphaned resources. A named immutable checkpoint can establish a clean rollback point before the agent starts writing.
Scoping credentials to each tenant's disk without shared secrets
A platform-wide secret defeats the purpose of separate tenant disks. A misdirected tool call or compromised agent could use it to reach data beyond its tenant. The credential needs the same boundary as the resource. Each agent therefore needs an identity issued in its tenant’s context, limited to that disk and explicitly granted integrations. Omnithium’s vault pattern requests a tool secret by (tenant_id, tool_name) and permits retrieval only by a process authenticated for that tenant.
External credentials should be brokered at the network boundary. On Archil’s Free plan, outbound traffic is restricted to a managed allowlist covering package sources, git hosts, container registries, and model APIs. Ports remain private until explicitly exposed. Developer plans and above allow custom firewall rules, including deny-by-default, with separate policies for loading, execution, and upload, and can broker credentials so secrets never enter the sandbox.
Those policy changes apply to new connections, but connections that are already open stay open. A deny rule is therefore not a time machine. Cross-tenant grants also need explicit scope, an audit record, and a time limit. A disk boundary makes the grant visible, but its lifetime still needs a limit.
Isolating agent-generated code at the execution layer
Even with the right disk credentials, a host kernel faces risks from agent-generated code. Standard containers start quickly, but share that kernel. A kernel escape can reach beyond the container. gVisor reduces the exposed kernel surface by interposing a user-space kernel, with roughly 8–15% overhead versus native execution for agent workloads requiring security isolation. Omnithium presents it as a balance point for trusted tool code within a platform.
MicroVMs provide a separate kernel for each sandbox. Archil uses Firecracker with a persistent root disk, separating the agent’s kernel from the host’s. That is a stronger boundary. The paper arXiv:2606.08433 documents escape-class CVEs affecting Firecracker and Cloud Hypervisor within roughly four months in 2026. Hardware virtualization therefore cannot be the only control.
Claims of isolation should name the hypervisor, the default egress policy, and where secrets are kept. Default-deny agent egress, network-level credential brokering, and no sandbox access to cloud metadata provide independent defenses. Kubernetes operators can also separate platform services from agent workloads through RuntimeClass, using standard containers for the former and gVisor or Kata for the latter.
Giving agents file access to large shared datasets without copying data per tenant
A regulatory reference or shared document corpus does not need a separate copy for every tenant. A shared disk can mount read-only across many sandboxes, while each sandbox mounts its tenant’s writable disk. The permissions make the distinction concrete and enforceable. Archil can present those mounts as a unified POSIX file system, with tenant writes kept off the shared dataset.
Existing tenant buckets can also stay in S3, GCS, R2, or Azure Blob without migration or an ETL pipeline. The bucket remains the source of truth. Writes are durable once fsync returns and are copied to the bucket in the background. Standard POSIX features, including atomic rename, mmap, hard links, symlinks, and sparse files, let existing tools run unmodified.
An already-running reader on another node caches directory listings for up to five minutes by default, so new files can take that long to appear unless it runs archil invalidate-cache. That latency needs a place in workflow planning. For one-off loading or query tasks, serverless execution can instead run a command against an existing disk without provisioning a persistent sandbox.
Branching and checkpointing tenant environments for parallel work and safe rollbacks
Agents trying tasks in parallel need separate places to write, while recovery needs a known-good state to restore. Archil creates named, independent, writable branches quickly regardless of disk size, while checkpoints preserve immutable disk states. A checkpoint can mark the moment before a major task or another platform-defined rollback target.
The timing claim is for the disk checkpoint-plus-branch operation. It does not describe forking a running sandbox with its CPU and memory state. Branches and checkpoints became generally available across all AWS regions in June 2026, but on Developer and Team they are not supported on bring-your-own-bucket disks; Enterprise offers bring-your-own-bucket disks that support them. Billing charges only for active data in each branch.
Parallel writes still need explicit ownership and coordination. Archil has no distributed file locking, and flock and fcntl apply per client. The recommended pattern is one writer per branch, separating attempts rather than expecting advisory locks to serialize them. Where machines share access, coordination uses read-only or conditional mounts and archil checkout.
How the cost model changes as tenant count grows into the thousands
A disk per tenant sounds expensive if “disk” means capacity reserved in advance. Usage-based billing changes that assumption. Most tenants in a large fleet are cold, so keeping every environment resident in memory or attached to dedicated compute makes inactivity expensive. HydraDB identifies memory-priced vector indexes and graph topologies as a scaling risk because they remain in RAM even when tenants are not querying. With designs based on object storage, more of the spending goes to query compute and storage I/O.
With active-data metering, as in Archil’s disk model, provisioning does not require predicting every tenant’s eventual workload. Light tenants need not subsidize generous fixed allocations for everyone. Heavy tenants are not constrained by those guesses. Archive storage can still incur separate charges for disks that do not synchronize to customer-owned buckets, so idle does not mean free.
For read-heavy fleets, egress can dominate the bill. Repeated retrieval and context fetches turn data movement into a recurring expense. Co-located cache nodes and avoiding cross-region movement unless explicitly configured address that exposure. Cost attribution still needs tenant-aware traces. Omnithium treats that attribution as a built-in platform control, while disk metering supplies a storage signal rather than a complete account of token and compute consumption.
Governing credentials, audit trails, and lifecycle across a fleet of tenant disks
A fleet needs credential rotation, accountable owners, and retirement rules as much as it needs a creation API. Short-lived credentials cut the risk from secrets that have been forgotten. Google’s Gemini Enterprise Agent Platform gives agents runtime-bound IAM identities with X.509 certificates that renew automatically, in place of long-lived keys that developers generate. Disk authorization needs equivalent lifecycle attention. Archil disk tokens can be long-lived or can carry a TTL or be one-time use, so expiry is a choice the platform has to make for each tenant.
Audit records must stay easy to use as the number of tenants grows. Omnithium requires tenant_id in every OpenTelemetry span and tenant-aware dashboards for errors and latency. Those views show whether an outage affects everyone or a failure affects just one tenant. A single audit view can show access across the fleet, while disk-scoped credentials show what authority allowed each access. Enterprises that span legal entities can see across all of them while keeping permissions separate.
Offboarding closes the loop that onboarding began earlier. It should revoke disk credentials and either delete the disk or, for a disk synced to the tenant’s own bucket, simply end access. For bring-your-own-bucket disks, revoking access leaves the data in the customer’s account. Archival and deletion policies also need to govern retained checkpoints and inactive environments. The Pool-to-Bridge retrofit offers the warning here too. Governance belongs in the provisioning design, before thousands of tenants turn an omitted lifecycle rule into a migration project.