Why Storage Boundaries Outperform Application-Layer Tenant Separation for AI Agents

Isolated per-tenant storage for multi-tenant AI agent applications means giving each customer a separate persistent workspace enforced by the storage layer. Those workspaces belong in isolated execution environments, with credentials and network access controlled outside the agent. An agent cannot read another tenant’s files if it has no access to their file system.

Why application-layer tenant separation is a structural bet, not an architecture

CockroachDB’s analysis gives the test bluntly. If the answer to “what happens if the agent touches data it shouldn't?” depends on application code doing the right thing every time, “that's not an architecture — that's a hope.” Application-layer filtering does have a useful role. It lets tenants share storage while the vendor controls which code runs and which records each request returns. In ordinary SaaS, a misconfigured query can remain a bounded bug, with one request and one wrong response.

Agents make that bargain harder to keep. They consume user input, web pages, database records, and tool outputs as context, allowing outside data to influence subsequent actions. Every tool call must therefore keep the tenant check in place, even as the agent chooses its next step. OpenLegion’s multi-tenancy guide identifies the weakness in a pool of shared compute and vector storage protected only by tenant_id filtering. If a filter is left out or overridden, an application bug can give an agent cross-tenant access.

How AI agents widen the blast radius when a boundary fails

CockroachDB describes unauthorized data entering an agent’s reasoning chain, where it can drive writes to downstream systems, API calls, and dozens of further tool calls before a human notices. The next action takes the wrong answer as input, allowing damage to spread as far as the agent’s tools can reach. A leaking query now has hands and a company credit card.

Hindsight’s per-user memory guide supplies a concrete example of how little needs to go wrong. A support SaaS used a customer_id tag to scope memory inside one shared bank, but a single retain call omitted the tag. Because the default match mode included untagged memories, Customer A’s contract terms appeared in Customer B’s session. OpenLegion identifies a related problem in shared audit logs, where exporting one tenant’s tool calls can expose another’s records unless their exclusion can be proved.

What genuine storage-layer isolation enforces that application logic cannot

Hindsight distinguishes a hard boundary enforced by storage in a separate store from a soft partition enforced by a label when a query runs. A query-time filter must keep excluding other tenants, while a hard boundary gives the caller no cross-boundary query path. HydraDB’s database guide expresses the same principle as “move all isolation logic out of the LLM prompt and into the database execution plan.” Vector searches and graph traversals need storage-level constraints outside the model’s influence.

OpenLegion identifies credentials, memory, and audit logs as separate isolation concerns, any one of which can produce cross-tenant bleed. Four boundaries therefore frame the rest of the evaluation. Data isolation limits what a tenant can reach, while performance isolation keeps one tenant’s burst from starving another’s SLA. Lifecycle and policy isolation allow different retention regimes, and operational isolation prevents maintenance from becoming a disruption for each tenant.

Why compute isolation requires a dedicated kernel per tenant, not a shared container

A storage boundary needs an execution boundary that agent-generated code cannot simply step around. Containers separate processes but share the host kernel with their neighbors. That shared kernel remains an escape surface. MicroVMs instead give workloads dedicated guest kernels behind hardware virtualization, placing the boundary below the kernel that agent code can attack. Compromising a guest kernel does not by itself grant access to the host or neighboring tenants.

That distinction does not make every alternative worthless. gVisor uses a user-space kernel interception layer, with a performance cost for syscall-heavy workloads. It guards against host kernel bugs, while Firecracker puts a boundary around a guest that has been compromised. The choice follows the threat model.

Archil uses Firecracker microVMs with a dedicated kernel per sandbox and persistent disks that survive stops and restarts. This couples the agent’s execution environment to a defined storage workspace rather than leaving every tool to reconstruct the boundary. An agent cannot use its local file system to read another tenant’s unmounted disk, regardless of what a prompt asks it to do. The scope of that claim is important. Compute and disk isolation do not replace controls on credentials or network routes that could reach data elsewhere.

How credentials and egress must be handled at the network boundary, not inside agent code

Raw credentials in agent code give it that other route to data. OpenLegion describes agents needing tenant-scoped OpenAI, Stripe, or Salesforce keys, with each tenant’s secrets held in its own credential vault scope. A private disk cannot protect a key that is handed straight to untrusted execution. If outbound traffic is also open, a boundary failure has a route for sending data away. The controls must sit outside the code they constrain.

Credential brokering and network policy close different gaps. Brokering keeps secrets out of the sandbox, while egress rules limit which destinations agent code can contact. In Archil’s implementation, credentials are injected at the network boundary. Its Developer plan limits outbound traffic to a managed allowlist of package registries, git hosts, container registries, OS package mirrors, and model APIs. Team plans can set their own firewall rules, and ports stay private until they are explicitly exposed.

How to give each customer an isolated storage workspace and memory

Persistent files and vector memory need the same rule. A tenant must not gain access to another tenant’s state simply because the data is relevant to its task. OpenLegion describes embedded passages from TenantA returning as top-K nearest neighbors to TenantB when both use a shared vector store without a tenant-partitioned index. Similarity search is doing its job. Access control is not. No adversarial input is required.

HydraDB recommends namespaces or separate indexes rather than relying only on metadata filters on every query. For finance or healthcare customers, separate indexes enforce the boundary at the storage-address layer instead of exposing it as a parameter agent code could modify. Hindsight proposes recalling from each bank the caller is entitled to use, then merging and ranking the results before they reach the model.

For file workspaces, Archil’s model gives each sandbox a persistent disk addressable within that tenant’s sandbox unless explicitly mounted elsewhere. That mount rule is part of the security boundary. Disks can mount an existing S3, GCS, R2, Azure Blob, or S3-compatible bucket as a POSIX file system without migration, leaving the customer’s data in the customer’s account. Writes are durable once fsync returns, with redundant storage across multiple Availability Zones, and configured bucket sources receive background synchronization. Each disk also has an S3-compatible API, allowing the rest of the stack to read artifacts without entering the sandbox, so isolation evaluation must cover that access path too.

Branching and checkpointing as storage-layer primitives for agent isolation across parallel runs

The 2026 arxiv paper “ACRFence: Preventing semantic rollback attacks in agent checkpoint-restore” identifies a trap in restoring agent state. A checkpoint can silently replay side effects unless the restore protocol knows what was already committed externally. Application-layer state alone cannot tell those states apart, so storage-integrated checkpoint awareness is needed for safety as well as ease of use.

Parallel attempts introduce a related need for separate writable workspaces. Archil disks checkpoint and branch in approximately 90 ms regardless of disk size, allowing attempts to start from the same checkpoint without sharing their subsequent changes. Its serverless execution, available since April 2026, runs one command in a fresh microVM against a disk, supporting that branch-per-attempt pattern. Disks can also mount on multiple machines for inspection while an agent continues working. These are useful isolation primitives, but their speed alone does not establish protection against semantic rollback attacks identified by the paper.

Scaling per-tenant isolation to thousands of tenants without per-tenant infrastructure costs that break unit economics

Hard boundaries are hard to sell if every tenant needs fully provisioned infrastructure even when idle. HydraDB identifies that pressure in memory-priced systems, where vector indexes and graph topologies occupy RAM whether their tenants are querying or not. Designs built on object storage shift costs toward the compute and storage I/O used for each query. Isolation need not mean an idle machine with a nameplate.

OpenLegion recommends a bridge model for B2B SaaS, combining shared compute governed by infrastructure ACLs with dedicated credential vault scopes and memory namespaces. That protects the two high-risk dimensions without requiring dedicated infrastructure everywhere. It does not remove the stronger execution requirement for untrusted agent-generated code. Shared infrastructure and shared trust are different decisions, so a cost-saving design still needs to explain where each boundary is enforced.

Archil’s 2026 pricing charges $0.20 per unit of storage per month for active disk storage, without charging for the full provisioned disk size. An agent using 1 MB pays for that usage, and one growing to 1 GB pays for the larger usage, subject to plan minimums. No advance capacity guess is required. Branching also means a new workspace need not be a full copy, keeping workspace creation from becoming a copying bill.

Mounting buckets that customers own also lets them control where source data lives without migration or an ETL pipeline, and the data stays in the customer’s account when access is revoked. Placement is only part of the compliance test. OpenLegion explains that a SOC 2 test fails if TenantB’s credential can use a direct storage API to query TenantA’s audit records, bypassing application filters. Storage-layer enforcement instead denies TenantB’s identity permission to read TenantA’s storage prefix. That is a boundary an auditor can inspect without trusting every application code path.

What to verify before trusting an isolation claim

The practical evaluation should apply equally to Archil and every other provider. Start by requiring a named mechanism at a named layer to substantiate an assurance that a sandbox is “secure. For compute, establish whether each workload has a dedicated guest kernel or shares the host kernel, and require the hypervisor name or a threat-model justification for sharing. For egress, distinguish a default allowlist from open outbound access with optional restrictions. For credentials, check whether secrets ever enter agent memory or are kept out through network-boundary brokering.

Establish whether tenant separation lives in a namespace, index, store, or disk enforced below application code, and whether direct APIs preserve it. For vector memory, require an account of index or namespace partitioning. For logs, require a tenant-specific export that excludes other tenants’ tool calls. For parallel runs and restores, distinguish isolated branches from proof that externally committed side effects cannot silently replay.

Archil’s Firecracker infrastructure handled production load for over a year before general availability, while persistent sandboxes became generally available in August 2026 and serverless execution in April 2026. A buyer can ask the provider to substantiate those specific claims and must still test the boundaries themselves. Testing the boundary requires checking whether a missed application check can grant access to another tenant’s data. If it can, the isolation still depends on the agent-facing application getting everything right.