The Tenant Boundary: Isolation for Shared AI Systems

A support agent receives a valid request from an authenticated administrator: “Show the unpaid July invoices for our account.” Retrieval finds six relevant documents. Five belong to the administrator's company. The sixth belongs to another customer whose project name, invoice vocabulary, and embedding happen to be similar. The model cites all six clearly and produces a polished answer.

Nothing in that sequence requires a jailbreak. The user was logged in, the agent had permission to search invoices, the vector query worked, and the answer was grounded. The failure is architectural: customer identity was treated as prompt context and a search filter, not as a non-bypassable information-flow boundary.

The reader decision is therefore concrete: which components may be pooled across customers, which require a dedicated silo, and where must tenant identity be re-enforced so a model can never trade isolation for relevance or convenience? The answer depends on consequence and threat, but one rule does not: every read, write, reuse, action, and evidence path must prove that its subject, source, and destination belong to the same permitted tenant boundary.

Tenant isolation is not another name for login

Authentication answers who presented a credential. Authorization answers whether that principal may perform an action on a resource. Tenant isolation adds a different invariant: resources associated with one customer, business unit, legal entity, or security domain must not flow to another, even when infrastructure is shared and both users are otherwise legitimate.

AWS's SaaS Architecture Fundamentals makes this separation explicit: a user can be authenticated and authorized yet still reach another tenant's resource unless tenant context independently constrains access. Its dedicated agentic AI guidance, published in July 2025, applies the same principle to agent knowledge, memory, MCP servers, tools, credentials, and shared model capacity.

This extends the agent-passport pattern. A task-scoped identity says which agent is acting and under whose delegation. A tenant boundary says which population of resources that identity may ever observe or affect. Neither substitutes for the other.

Define the tenant before choosing the infrastructure

“Tenant” is an application-owned security label, not a synonym for user, database, namespace, or subscription tier. It may be a company, hospital, regulated fund, subsidiary, or internal unit. One person can belong to several tenants with different roles, so membership must be versioned.

Create a registry with stable, opaque identifiers and resolve an immutable tenant envelope before retrieval or inference:

Field	Purpose
`tenant_id`	Stable security identifier, never inferred from a name or prompt
`subject_id` and `membership_version`	User or workload and the exact membership decision used
`task_id` and `purpose`	Why access exists for this bounded operation
`policy_version`	Isolation and sharing rules evaluated for the request
`allowed_regions` and `data_classes`	Residency and sensitivity limits
`credential_audience` and `expires_at`	Where delegated authority works and when it ends
`trace_id`	Evidence handle without making raw content the identifier

Integrity-protect the envelope and derive it from trusted identity state—not a request body, URL slug, model output, client metadata, or MCP argument. Downstream services may narrow it; they must not broaden or replace it.

Separate established controls from the AI-specific design

Several primary sources establish useful properties, but none turns a shared AI application into an isolated system by itself.

The NIST SP 800-53 Rev. 5 catalog defines information-flow enforcement using approved source, destination, and object attributes, including logical or physical separation. It is not a RAG implementation recipe.

Kubernetes multi-tenancy guidance covers namespaces, virtual control planes, dedicated clusters, node isolation, network policy, quotas, and sandboxing. A namespace still needs supporting RBAC, networking, storage, and workload controls.

PostgreSQL 18 row security can default-deny row access. Important exceptions remain: superusers, BYPASSRLS, and normally table owners bypass policies; whole-table operations are outside RLS; policy subqueries can leak through races.

These are verified source properties. The layered contract below is ZharfAI analysis: a way to compose them with retrieval, memory, cache, tools, model calls, logs, and evaluation so the tenant invariant survives the full decision path.

Choose pool, bridge, or silo per layer

Do not label the whole product “multi-tenant” and make one global architecture choice. Each layer has its own attack surface, cost curve, operational burden, and consequence of a boundary failure.

Pattern	What is shared	Best fit	Main tradeoff
Pool	Compute or storage with tenant-aware policies and keys	Large populations with comparable controls and strong automated enforcement	Lowest unit cost; widest blast radius for a policy defect
Bridge	Shared control plane with tenant-dedicated data, indexes, workers, keys, or tools	Mixed risk, residency, and customer requirements	More routing and lifecycle complexity
Silo	Dedicated stack or security perimeter for one tenant	Untrusted code, strict sovereignty, exceptional consequence, or contractual separation	Stronger reasoning boundary; higher cost and operational load

Google's multi-tenant agentic AI reference architecture, last reviewed June 18, 2026, uses a hub-and-spoke design with central governance and dedicated tenant projects, datastores, agent runtimes, policy boundaries, and optionally tenant-local MCP servers. It is one strong bridge-to-silo pattern, not proof that every workload needs a project per tenant.

Choose per layer using data sensitivity, irreversible authority, untrusted inputs, residency, customer control, blast radius, restore and deletion needs, and the team's ability to test pooled policy. Price tier alone is not a security rationale.

Enforce tenant scope before semantic relevance

Tenant isolation must happen below the model and before ranking. Never retrieve broadly and ask the model to ignore results from other customers. Never rely on a hidden prompt saying “only discuss the current account.” OWASP's LLM02:2025 Sensitive Information Disclosure notes that prompt restrictions may be bypassed and recommends strict access controls plus restricted data sources.

For pooled relational storage, bind trusted tenant context to the session, require row policy on every tenant table, use a non-owner role without bypass, and test USING reads plus WITH CHECK writes. For object storage, derive prefixes server-side and issue credentials that cannot list a parent namespace. For vector search, use a tenant index or enforce the predicate before approximate search returns candidates.

Trust metadata filters only if the engine enforces them server-side and callers cannot omit them; otherwise separate collections, accounts, projects, or services. The enterprise-memory guide already requires scope before semantic ranking; multi-tenancy makes that order a release blocker.

After retrieval, verify every returned object's tenant attribute and source authority again before prompt assembly. This second check is defence in depth, not permission to weaken the first. A mismatch must fail closed, raise a security signal, and keep foreign content out of prompts, traces, repair queues, and model-provider requests.

Keep shared state from becoming a side door

The obvious database is rarely the only cross-tenant path. Inventory all state that can influence or retain a result:

conversation history, summaries, scratchpads, and durable memory;
exact and semantic response caches, provider cache keys, and embedding caches;
retrieval indexes, document chunks, reranker features, and temporary files;
tool results, workflow checkpoints, retry payloads, and dead-letter queues;
logs, traces, screenshots, human-review queues, and support exports;
feedback datasets, evaluation corpora, fine-tuning candidates, and replay fixtures.

Every key must include trusted tenant identity where sharing is allowed, plus the policy, purpose, release, and evidence attributes that determine equivalence. The semantic-cache guide explains why similarity is not a safe reuse decision; a cross-tenant cache hit is forbidden even when two questions and public sources are identical, unless the cached object was deliberately classified as tenant-neutral at creation and stored in a separate public namespace.

Removing customer names later does not sanitize a mixed trace: snippets, identifiers, rare phrases, tool arguments, timing, and embeddings may remain sensitive. Minimize content before shared observability. Store partitioned references, policy decisions, counts, hashes, and outcome codes; keep raw payload access narrower and auditable.

Training and evaluation are destinations too. A ticket from tenant A must not silently become an example or fine-tuning candidate for tenant B. Shared learning needs an explicit rights, privacy, purpose, and quality decision.

Make tools enforce the boundary themselves

An agent may hold correct tenant context and still call a tool that accepts an arbitrary customer_id. That is a confused-deputy design: the model can propose a different target than the credential was meant to serve.

At each tool gateway or MCP server, derive tenant scope from the authenticated workload and signed task envelope. Ignore, reject, or compare any model-supplied tenant identifier; never treat it as authority. Exchange the agent credential for a short-lived downstream credential restricted to the tenant, exact tool, operation class, resource family, purpose, and expiry. The resource server must enforce the same boundary at the final read or effect target.

This complements the tool-permission guide: least privilege controls what an agent may do, while tenant isolation controls whose resources can be touched. For shared MCP servers, isolate connections, credential caches, filesystem mounts, process environment, temporary artifacts, and error messages. When the server cannot provide that assurance, deploy it per tenant.

Cross-tenant administration needs a distinct capability, not a wildcard tenant credential: explicit support purpose, case reference, narrow resources, short duration, sensitive-access approval, and a separately reviewed trail.

Worked example: a shared invoice assistant

Consider a SaaS invoice assistant serving 800 companies. Most use pooled compute and PostgreSQL; regulated tenants receive dedicated storage, search, keys, and workers behind the same governance plane.

An administrator signs in under T-731. The gateway resolves membership version 44 and signs task Q-9921 for 90 seconds of read-only search. The orchestrator cannot edit it. PostgreSQL uses a non-owner role with forced row security; vector search receives a server-side collection handle, not a free-form filter.

Retrieval returns five chunks. A guard verifies their tenant, data class, and policy before text enters the prompt. The output guard then verifies every cited invoice and URL under the same envelope. No tool has export or payment authority.

Now suppose an index migration accidentally writes one T-552 chunk into the T-731 collection. The pre-prompt guard detects the mismatch, returns no answer, records identifiers and hashes without foreign text, disables the affected collection, and opens a security incident. It does not ask the model to remove the paragraph. The index owner rebuilds from tenant manifests, tests the entire population, and proves which requests could have encountered the contaminated collection before reopening it.

The important property is not that no component can fail. It is that one failed partition does not automatically become customer-visible disclosure.

Test isolation as an adversarial invariant

Unit tests with two clean tenant IDs are not enough. Build a generated matrix across users, roles, tenants, states, resources, interfaces, and timing. Include:

valid user with a foreign object ID, guessed slug, copied URL, or stale deep link;
user who belongs to two tenants and switches context during a long-running task;
removed membership while memory, caches, retries, or tool calls remain in flight;
documents with forged tenant metadata or prompt injection requesting another namespace;
cache-key collision, empty tenant field, default namespace, and case/encoding variants;
poisoned index entry, mixed batch, backup restore, reindex, export, and deletion job;
privileged support, migration, analytics, and break-glass paths;
retries after credentials expire and delayed workers using an earlier membership version;
logs, review queues, evaluation datasets, and incident bundles opened by the wrong team;
noisy-neighbour load intended to trigger a fallback that accidentally drops isolation.

Test through public APIs and effect targets, not only policy mocks. Seed synthetic canaries per tenant and alert on any foreign candidate, prompt, output, cache hit, tool request, log attachment, or evaluation admission.

Operate from boundary evidence, not confidence

Monitor both denied attempts and successful boundary proofs:

Measure	What it reveals
Foreign candidates before prompt assembly	Partition or ingestion defects caught by defence in depth
Cross-tenant denials by layer	Probing, client bugs, or broken context propagation
Missing or default tenant-envelope rate	Fail-open integration paths
Credential scope and lifetime distribution	Authority broader or longer than task need
Shared-state key coverage	Caches, queues, and memory missing trusted scope
Canary escape rate	End-to-end isolation failure; target is zero
Privileged cross-tenant sessions	Support and incident-access exposure
Revocation-to-quiescence time	How quickly removed authority stops all descendants
Isolation-test population coverage	Whether rare tenants and routes are actually exercised

Do not log foreign payloads to prove a guard worked. Record protected tenant identifiers, component, object handle, policy version, decision, and trace. Test that central monitoring does not become a data lake with weaker controls than production.

When a possible disclosure occurs, freeze affected caches and indexes, revoke scoped credentials, preserve integrity-protected evidence, determine the exposed population, and follow applicable contractual, privacy, regulatory, and incident-notification duties. The audit-evidence guide is useful here: the assertion is not “the policy exists,” but “every consequential path enforced the current tenant envelope, and these are the exceptions.”

The tenant-isolation release gate

Before a shared AI workflow reaches production, verify:

the tenant unit, membership lifecycle, cross-tenant roles, and public/neutral data class are explicitly defined;
tenant context comes from trusted identity state and is integrity-protected for the task;
pooled, bridge, and silo choices are documented per layer with consequence and threat rationale;
every database, object store, index, memory, cache, queue, tool, log, and evaluation path is classified;
authorization is enforced before retrieval and again before prompt assembly or action;
models cannot select, widen, or override tenant scope;
credentials are short-lived, audience-bound, tenant-scoped, and checked at the final resource;
adversarial cross-tenant tests cover lifecycle changes, delayed work, poisoned metadata, restores, exports, and fallback paths;
the incident runbook can disable one tenant or one shared layer without erasing evidence or exposing another tenant.

What to revisit as the system changes

Revisit the boundary for every new tenant class, region, provider, cache, memory feature, MCP server, dataset, support role, export, migration, or cross-customer analysis—and after a disclosure, bypass, restore failure, or increase in tool authority.

The goal is not to dedicate every server. It is to make sharing a deliberate, provable property. A well-designed multi-tenant AI system can pool expensive models and operations while keeping customer knowledge and authority separate—but only when tenant identity remains outside the prompt, travels with every task, narrows every resource, and is enforced again at every place information can be read, remembered, reused, acted on, or learned from.

Source notes — reviewed August 16, 2026

AWS Prescriptive Guidance: Enforcing tenant isolation for agentic AI — July 2025 guide; verified tenant-context enforcement across agent knowledge, memory, tools, MCP, credentials, and shared capacity.
AWS SaaS Architecture Fundamentals: Tenant isolation — verified the distinction between authentication, authorization, and tenant-scoped resource isolation.
Google Cloud: Multi-tenant agentic AI system — last reviewed June 18, 2026; verified the hub-and-spoke reference architecture, tenant projects, datastores, runtimes, policy boundaries, and MCP deployment options.
Kubernetes: Multi-tenancy — last modified May 22, 2025; verified the isolation spectrum and the limits of namespaces without supporting control- and data-plane policy.
PostgreSQL 18: Row Security Policies — verified default-deny behavior, owner and bypass exceptions, restrictive policies, and documented race and covert-channel cautions.
NIST SP 800-53 Rev. 5 — September 2020 publication with later minor releases; verified AC-4 information-flow enforcement and logical or physical separation concepts.
OWASP LLM02:2025 Sensitive Information Disclosure — verified disclosure risks, the limits of prompt-only restrictions, strict access control, and restricted data-source guidance.