Per-Customer Agent Isolation in Multi-Tenant Agent Product Architectures

Each customer needs an isolated, persistent agent environment, provisioned automatically at onboarding. A single API call can be the provisioning interface, but it is not proof of isolation. Per-customer agent isolation requires separate enforcement across storage, compute, memory, retrieval, and tools, with those boundaries designed before the first customer arrives.

Why multi-tenant AI agents break assumptions that standard SaaS architecture was built on

An agent can return another customer's data without producing an error. A sub-agent misses a retrieval filter, pulls fragments from the wrong index, and builds a plausible answer around them. The response looks ordinary because semantic relevance says nothing about permission. Traditional SaaS controls take for granted that the vendor knows what code runs. Agents break that assumption by generating code and actions from customer prompts at runtime.

Context windows also ingest documents, embeddings, and tool results from shared systems, making each input path a possible crossing point. State makes the damage harder to contain. A misconfigured execution graph can pass corrupted state into later calls and, when memory persists, later sessions. Meanwhile, token consumption follows a heavy-tailed distribution, as complex tasks and retry loops use far more tokens than most sessions. A compromised, long-lived session can therefore spread contamination while burning a disproportionate share of the token budget.

The failure pattern that emerges reliably as platforms scale past their first customers

Teams establish tenant_id at the HTTP gateway, validate it in middleware, and treat isolation as finished. Internal tool calls, sub-agent retrieval chains, and memory queries then bypass that work. Leakage typically occurs somewhere between customer 20 and customer 30 as those less visible paths multiply and bypass isolation checks.

Nothing necessarily crashes when the boundary fails. Retrieval returns the wrong fragments, and the agent uses them as though they belong. By the time an alert customer or compliance audit exposes the problem, the repair requires examining every retrieval operation, tool executor, and memory manager. That requires months of remediation.

The three data-isolation models and how tenant count, regulatory exposure, and cost sensitivity determine which one to choose

Silo separates each tenant's runtime, vector index, and API endpoint. It provides the strongest data partitioning but pays for provisioned capacity regardless of use. This fits high-exposure tenants in HIPAA, SOC 2, or FedRAMP environments, where separation takes priority over utilization. Recovery is also more contained. An infrastructure-level rollback replaces the need to untangle shared retrieval paths.

Pool shares infrastructure and separates tenants through query-level tenant_id filters. It costs less and scales easily, but one missed filter can expose data silently, while noisy neighbors compete for resources. It works for PII-free, low-risk data when there are few tenants. AWS Bedrock AgentCore demonstrates a pool implementation using scoped identifiers, access policies, and data partitioning across a Tier → Tenant → User hierarchy, with cost allocation tags for per-tier tracking.

Bridge combines Pool for low-risk tenants with Silo for high-risk tenants. Its scale sweet spot is fifty to five hundred tenants, with dedicated capacity purchased only where required. Design for Bridge even when launching with Pool. Retrofitting it means inserting scoping logic into every retrieval path that lacked it, while starting regulated health or financial tenants in Silo avoids a costly compliance repair.

Why storage and vector database isolation demand their own enforcement layer, independent of the model tier chosen

A sound data model still needs storage enforcement. When every customer's files are in one bucket and application logic is all that protects them, one bug can let the files leak. The workspace-per-tenant pattern establishes ownership when data arrives. Uploaded files receive a Workspace ID immediately, the RAG pipeline writes their embeddings into that workspace's namespace, and search queries only the namespace matching the current workspace.

Vector search needs controls of its own. Each tenant gets a unique namespace, every vector receives tenant_id, and every query requires the corresponding filter. Finance and healthcare customers need separate indexes as well as filtering. These controls belong both where a request enters the platform and where retrieval happens.

Red Hat AI's research on multitenant retrieval found that Attribute-Based Access Control gating at retrieval eliminated cross-tenant leakage while adding a small, bounded latency cost. Throughput scaled linearly without a gating bottleneck. That finding establishes why authorization must constrain search before results enter the agent's context. Compute isolation cannot fix an answer already built from data the agent had no right to use.

Why container isolation is insufficient for agents that execute untrusted, AI-generated code at runtime

Containers on a node share the host kernel. A kernel exploit in one tenant's container can therefore reach the host and neighboring tenants. CNCF's assessment of the November 2025 runc breakouts identified critical risk in multi-tenant environments running user-defined containers or unvetted images. Unreviewed, AI-generated code creates the same underlying trust problem.

Kubernetes' documentation says containers are a weaker isolation boundary than hardware-based virtual machines. Resource exhaustion creates another route to shared failure. An agent stuck in an infinite loop can starve CPU for co-located tenants and turn one session's bug into platform-wide latency. Containers remain appropriate for platform-controlled, predefined workloads, but they are the wrong boundary when tenants influence the code that executes.

The compute isolation spectrum from lightweight state binding to microVMs, and where each tier earns its place

The first distinction is who controls the code. In Node.js environments, AsyncLocalStorage can bind an engine instance to its own resource bundle without creating another operating-system process. This helps keep trusted first-party code from mixing up state across users by accident. It is not a sandbox for adversarial tenant code.

gVisor provides a stronger middle tier by intercepting system calls between the container and host kernel. With roughly 8–15% overhead versus native execution, it adds protection beyond container namespaces without the need for dedicated virtual machines. That works for platforms that control what runs and trust their tool code. MicroVMs, including Firecracker and Kata Containers, instead give workloads dedicated guest kernels behind hardware virtualization. With memory overhead under five MiB per VM and sub-second boot latency, their cost profile weakens the old objection to VM-per-tenant designs.

AgentCore runs each user session in a dedicated microVM with isolated CPU, memory, and filesystem. Customer-facing agents that run arbitrary or AI-generated code use microVMs, while background jobs that run platform-written code stay in containers. For regulated workloads needing protection even from the host, AMD SEV-SNP and Intel TDX extend isolation with hardware-encrypted memory.

The six surfaces where isolation leaks regardless of the compute tier chosen

The first three leak surfaces involve context: retrieval filters must cover every vector search and document lookup, including sub-agent calls. Shared prompt caches can transfer one tenant's instructions, persona, or configuration data into another session. Long-term memory keys need tenant scope as well as user or session identity, because collisions or session migrations can expose accumulated context.

The next three extend beyond the model. Tool credentials must be scoped at execution, rather than assumed safe because the session was authenticated. Logs and traces need tenant-filtered access so conversation content, file paths, and query strings do not become shared data. Network egress is the often-missed boundary. An agent can send data out through a connection, so a default-deny policy or proxy must restrict it to explicitly approved destinations.

The tenant identity set at runtime must be passed to all six surfaces. The implementation follows from that requirement, with MCP tools scoped to the tenant's root directory and file access and memory retrieval logged with tenant ID. Rate limits for each tenant also keep resource exhaustion in one tenant from affecting others. Tests must show that these controls hold, beyond what code review can show.

How tool authentication compounds the isolation problem when agents act in the real world

An agent opening a GitHub issue, sending a Slack message, or querying a database acts through credentials that grant real access. A shared OAuth token or API key can therefore defeat otherwise sound sandboxing. The tool layer is an authorization boundary too. A per-user session pattern binds external access to the person and tenant on whose behalf the agent acts.

Composio uses that pattern with least-privilege session access, audit trails for each tenant, and isolation built for customer-facing deployments with more than one user. Its credential scoping complements compute and retrieval controls. As more integrations are added, it also gets harder to manage which tools are available. Loading hundreds of applications' schemas into context consumes token budget before useful work begins, while meta-tool routing exposes tools selectively.

What a hub-and-spoke governance architecture looks like when isolation must scale across many tenants simultaneously

Google Cloud's reference architecture separates shared governance from tenant execution. A routing hub handles authentication, security inspection, and routing, while a central governance and security hub handles logging and IAM. Each isolated tenant spoke contains its own agent runtime, MCP servers, and datastore. The design blocks access to data in other spokes.

Central ingress admits authenticated, inspected requests, identity verification establishes user context, and prompt inspection runs at the edge and again within tenant environments. Centralized IAM limits policy drift across projects, while aggregated logging supports fleet-wide audits without exposing tenant content to other tenants. Within each spoke, Principal Access Boundary Policy restricts principals to approved resources, and the dedicated datastore limits access to that tenant's agent. Service tiers can then govern capabilities and cost attribution without weakening those tenant boundaries.

How isolation architecture choices interact with the agent runtimes operators are actually deploying in production

OpenClaw disclosed nine CVEs in four days in March 2026, including one rated CVSS 9.9. That makes an active CVE-watch and patch cadence an essential part of its production isolation design. Hermes Agent creates a different pressure. Nous Research launched it in February 2026 with self-improving skills and persistent cross-session memory, so strict tenant-scoped memory keys are essential to prevent contamination from compounding.

Claude Code includes OS process sandboxing through Seatbelt on macOS and bubblewrap on Linux. That is useful process isolation, but its single-model dependency on Anthropic's API leaves no internal fallback during an outage. Subscription requirements and lack of model flexibility also constrain per-tenant economics. OpenAI Codex cloud instead runs tasks in platform-controlled sandboxes and returns diffs or pull requests, trading operator control over isolation for hosted execution.

Codex's token-based pricing through codex-mini-latest, available since May 2025, supports straightforward per-tenant cost metering. Neither runtime makes the surrounding architecture uniform. When OpenClaw hosts Codex or Claude Code, the combined system adds attack surfaces rather than inheriting one universal sandbox guarantee. Each runtime needs assessment separately and in combination.

How do you give every customer an isolated agent without maintaining complex infrastructure?

The operational unit is one isolated, persistent agent per customer, provisioned automatically at onboarding. Reproducing that unit is only the beginning. A self-hosting operator must maintain namespaces and sandboxes, patch runtimes, manage secret injection and credential stores, and operate egress controls. Every added sub-agent or tool also requires another audit of identity propagation and retrieval filtering.

Recovery and observability create recurring work of their own. A failed tenant instance must be recoverable without disrupting neighbors, while logs must remain useful without becoming a disclosure channel. These responsibilities require ongoing DevOps capacity, a CVE response process, and retrieval-audit capability. At low scale they impose fixed costs, and at higher scale the labor grows.

Managed agent hosting is the alternative to owning that infrastructure work. AgentCore provides managed agent deployment, identity, memory, and observability, while Codex cloud provides hosted task sandboxes with less operator control. Those offerings carry different implications for obtaining a persistent per-user environment provisioned in one call. Evaluate services by the isolation responsibilities they actually take over.

The architectural decisions that must be made before the first customer, and how to sequence them

First, choose Silo, Pool, or Bridge based on expected tenant count and regulatory exposure, while designing for Bridge even if launch uses Pool. Second, establish workspace-per-tenant storage before ingestion, with namespace assignment at upload. Third, enforce ABAC gating on every retrieval query, including sub-agent and tool paths. The order prevents data from entering unscoped paths.

Fourth, match compute to code trust, using microVMs for arbitrary or generated code, gVisor for controlled tools, and containers for pre-reviewed platform workloads. Fifth, enforce per-user credential sessions before connecting external integrations. Sixth, close egress with a default-deny policy before agents face customers. Seventh, make logging and observability tenant-aware before the first production session, because missing audit trails cannot be reconstructed afterward.

These choices are cheap before paths multiply. After a breach, establishing its scope requires auditing execution paths across customer sessions. Before customer one, the architecture decisions take an afternoon. Discovering their absence after the platform scales can mean months of remediation.