Agent State Isolation Across Tenants on Shared Infrastructure

Isolated per-tenant storage for multi-tenant AI agent applications requires more than a database filter. Each customer needs a workspace scoped to authenticated tenant identity, with that boundary enforced across files, compute, network access, credentials, and logs. Isolation must survive an agent’s mistakes independently of its cooperation.

Why agents cross tenant boundaries that web apps never would

Traditional web apps check permissions at the API surface, where a person makes a relatively bounded set of requests. Agents take autonomous actions across tools, queues, caches, files, and credentials, often without another human decision between steps. That changes where authorization has to hold. A missed boundary can expose another tenant’s data without anything unusual appearing in the UI.

A tenant_id in a prompt does not close that gap. Retrieved content can be hostile, tool arguments can be wrong, and two customers can both have a resource called production. A friendly name is not a passport. The Sema Code paper points to another risk in a global singleton state space, where one agent may read what another agent has written and see its conversation histories or artifacts. Because agents act autonomously across many backend systems, isolation must be a property of every layer.

What tenant identity actually means for an agent runtime

The runtime must get tenant identity from the session or application credential before it accepts resource input. The control plane then propagates that identity through every subsystem the agent touches. A tool argument must never override authenticated scope, even when the requested resource has a globally unique ID.

Before a tool runs, authorization must check a server-side resource record under the current tenant. Denials must go in an audit log so they leave a record. NIST’s zero trust architecture treats access as a per-request decision based on identity and resource, independent of network location. Internal workers get no diplomatic immunity. A background task must stay within the access its tenant allows, even when it runs inside the platform.

The same identity must scope file access and the credentials used at network or storage boundaries. Archil combines tenant-scoped file systems with credentials brokered at the boundary and isolated microVMs with their own kernels. This places enforcement outside agent-generated instructions. A practical verification test is to create the same resource name in two tenants and check that each resolves only within its authenticated context.

Choosing a database isolation model deliberately, not by default

Shared tables, separate schemas, and separate databases make different operational bargains. Shared tables use a tenant column, row-level policy, and scoped queries, which keep migrations simple but leave every access path dependent on the policy and connection role. A schema per tenant creates a separate namespace inside one database, at the cost of per-schema migrations and connection setup. Separate databases provide the strongest storage boundary of these models, with separate credentials and more provisioning, pooling, backup, and migration work. There is no free isolation lunch here.

Row-level security can provide strong isolation when tenant context is set server-side and the application role cannot bypass the policy. A tenant column on its own cannot guarantee that isolation. Other connection paths need to be checked as closely as the main application connection. Regulatory requirements, unusually large tenants, customer-managed encryption, and independent restore needs justify higher-isolation models.

Vector memory needs an equally deliberate boundary. Semantic search is approximate, but tenant authorization cannot be. Per-tenant namespaces and a tenant_id stamped on every vector, required on every query, keep retrieval scoped. A relevant match from the wrong customer is still a breach.

How do you give each customer an isolated file workspace?

Agents read, analyze, and generate files as part of their day-to-day work, so file storage has to do more than hold uploads. When application logic alone separates tenants in a shared bucket, that logic is all that stops cross-tenant access. Search makes the risk especially sharp. A search tool unconstrained by the tenant’s workspace gives the agent effective admin access to everything it can retrieve.

The workspace-per-tenant model binds ingestion, indexing, and retrieval to a specific Workspace ID. Uploaded files receive that scope immediately, embeddings enter the corresponding namespace, and search queries only that namespace. The identity chain must remain unbroken. Otherwise, careful database isolation ends at the first file operation.

The storage design still has to choose between shared storage with tenant namespacing, separate mount points, and dedicated infrastructure. An object path such as gs://{bucket}/tenants/{tenant_id}/sessions/ provides a useful structure, but its protective value depends on storage-level enforcement. The tenant-scoped file system in Archil is one concrete option for enforcing that workspace boundary. Sandbox file systems must belong to a tenant and have separate credentials, and browser and sandbox sessions must stay per-tenant too.

Compute isolation — what containers, gVisor, and microVMs actually guarantee

Agents execute arbitrary, LLM-generated code, so the execution boundary has to be chosen for what it prevents. Standard containers isolate processes but share the host kernel. They do not provide kernel-level separation. In this threat model, containers alone suit trusted code.

gVisor places a user-space kernel between the workload and the real kernel, intercepting most system calls, with some overhead on I/O-heavy workloads. MicroVMs instead provide a separate kernel boundary. A risk-based production split can use gVisor for routine execution and microVMs for builds or third-party code. Container hardening still includes user namespace remapping, dropped capabilities, disabled privilege escalation, and resource limits.

Production examples make these distinctions concrete. Amazon Bedrock AgentCore Runtime gives each user session a dedicated microVM with isolated CPU, memory, and filesystem, then terminates and sanitizes it after completion. For another production option, Archil uses microVMs, with over a year of production load and millions of agents per week. The useful comparison is specific. A vendor should name its hypervisor, default egress policy, and secret location to substantiate its isolation claim of “secure sandbox.

Default-deny egress and why the network boundary matters as much as the execution boundary

Even with a strong execution boundary, an agent can send data through an open network connection. Permissive outbound access leaves routes for exfiltration, lateral probing, and credential abuse without any sandbox escape. Network policy must contain a compromised workload.

The strongest pattern is default-deny egress through an allowlist proxy. All traffic goes through that proxy, and connections anywhere else are rejected. Approved VCS providers and LLM endpoints remain reachable, while arbitrary destinations fail. Allowlists should follow agent class rather than the whole cluster, because research, customer-support, and computer-use agents have different legitimate destinations. Separate namespaces or network segments preserve those distinctions.

Credential abuse also has a direct financial consequence. Model-provider API keys authorize billable use, and soft budget notifications do not provide the protection of enforced spend caps. A leaked key can generate charges before alerts prompt a response. Rate and spend limits therefore need partitions by tenant, agent, and high-impact action. Those partitions depend on the authenticated identity established earlier.

Credential handling — why environment variables and runtime vault retrieval leave secrets inside the sandbox

Environment variables put secrets where sandbox code can read them. Runtime vault retrieval changes how a secret arrives, but still deposits it in sandbox memory. Neither removes the exposure. A long-lived agent handling adversarial input can otherwise accumulate the credentials of many tools across concurrent tasks.

The stronger pattern injects credentials outside the agent process at the network or storage boundary. A proxy applies credentials scoped to the specific sandbox and logs each use per request. The agent gets permission to make a particular call while the secret behind it stays outside the agent process. Short-lived workload credentials also limit what the workload can do to the downstream action it needs. Identity mechanisms include SPIFFE/SPIRE SVIDs and cloud workload identity federation, rather than long-lived credentials accumulating in agent memory.

The paper identified as arXiv:2604.03070 describes frameworks feeding tool stdout back into the LLM context, turning debugging output into an exposure channel. Its findings put 73.5% of credential vulnerabilities in information exposure through print() or console.log(). A console can become a very expensive gossip.

Vault partitions also need cryptographic separation, with each tenant’s credentials encrypted under a separately derived HKDF key. Logs and traces must have tenant fields, and prompts, tool arguments, and results must go through redaction before they are exported. Observability is itself a data layer. Access that can search across tenants is privileged and needs its own access control.

Containing loops and runaway agents without confusing rate limits for authorization

Infinite loops, repeated retries, and runaway model spending can use up shared resources. Per-tenant limits on concurrent runs, tool calls, model spend, storage, and repeated failures contain that blast radius. Narrower limits on destructive or expensive tools protect the tenant’s own allocation too.

Limits do not make an unauthorized call acceptable. Authorization must run before quota is charged, and stable error classes should make it clear which errors are policy denials and which are failures worth retrying. Otherwise, a refusal can become an invitation to try forever. When a loop is detected, the affected workload should pause and leave an operation record for human inspection, rather than silently dropping requests or returning ambiguous errors.

Branching and checkpointing agent workspaces across parallel tenant sessions

Search-time reasoning, RL rollouts, and iterative debug-test loops require many parallel, stateful sandbox clones. Fast branching is therefore an architectural requirement for these workloads. Full-state duplication can take hundreds of milliseconds to seconds per checkpoint or restore. That cost makes deep search and large fan-outs harder to run in practice.

DeltaBox’s 2026 research uses change-based transactional checkpointing through DeltaFS and DeltaCR. DeltaFS combines dynamic freezing with copy-on-write writable layers, while DeltaCR uses incremental process dumps and direct forks from frozen templates. On MCTS workloads for a software engineering benchmark, DeltaBox reports checkpoint latency of 14 ms and rollback latency of 5 ms. Each trajectory gets its own writable layer. With that layer in place, a write in one branch cannot change another branch’s filesystem view, but the starting workspace must still belong to the correct tenant.

Archil offers disk checkpoints that complete in sub-second time regardless of size and can be mounted on many machines simultaneously. That is a concrete storage option, distinct from DeltaBox’s combined filesystem and process checkpointing. An incorrect result or boundary-crossing action can trigger a return to a known-good workspace without rebuilding the environment from scratch.

Tenant deletion as a multi-layer operation, not a database transaction

Tenant deletion reveals every subsystem that escaped tenant scoping. Deleting database rows leaves the job unfinished if files, credentials, or running sandboxes are still elsewhere. Offboarding is an architecture audit with consequences. Its inventory includes databases, cached values, queued work, artifacts, memories, indexes, browser sessions, sandboxes, credentials, logs, backups, and active operations.

The order is part of the control. New work must stop and credentials must be revoked before data deletion starts, or new writes can reach a tenant while it is partly deleted. Queued work, in-flight tool calls, and running sandboxes must be inventoried and terminated. The deletion process must make clear what is removed right away, what expires later, and what is kept for legal or security reasons. “Deleted” cannot mean whichever of those happened to be easiest.

Partial failures also require deletion to be resumable and idempotent, so rerunning it safely completes unfinished work. An untracked subsystem makes proof of removal impossible. The same tenant identity that binds access during operation must make each resource accountable at offboarding. Multi-layer isolation is what makes the full tenant lifecycle, from onboarding through deletion, auditable and complete.