The classic SaaS isolation problem is well understood: keep tenant data, queries, and identity separated through the request path. An agent platform adds two new surfaces that have to follow the same rules. The retrieval layer (vector stores, document stores, memory) and the tool-execution layer (outbound credentials, MCP servers, browser sessions) both carry tenant data and both can leak across boundaries if you build them like single-tenant systems. Companion to the agent security checklist and to SOC 2 compliance for agents.

This piece covers the six layers an agent platform isolates at, the specific patterns that pass a SOC 2 sample, and the automated tests that prove isolation in CI. The framing is "what would an auditor or pen tester actually push on", not generic multi-tenant theory.

What "tenant" means for an agent platform

A tenant is the boundary against which authorization decisions are made. In SaaS that is usually the customer organization. In an agent marketplace it can be more granular: a customer organization, a user within an organization, or even a single agent instance with its own credentials. The right grain depends on what data the agent touches. If the agent reads only personal calendar data, the user is the tenant. If it reads shared org documents, the organization is the tenant. Many platforms keep both grains and apply both checks.

Two anti-patterns to name. First, no tenant id at all, with tenancy implicit in the URL or in the session. This breaks the moment an internal admin runs a query without a session. Second, tenant id present but advisory, with the application code expected to filter. The audit finding writes itself: "the control depends on developers remembering to apply it."

Six layers of isolation

  1. Authentication. Every request carries a verified tenant claim from your identity layer. JWT or session token, signed and validated. No tenant id from a path parameter without cross-check.
  2. Request routing. A tenant-aware router or middleware decorates every downstream call. Tenant id is a first-class request argument, not an optional kwarg.
  3. Storage. Tenant id is part of the primary key, or the storage layer enforces row-level security. Postgres RLS, DynamoDB partition keys, or per-tenant database depending on scale.
  4. Retrieval (vector store). Per-tenant namespace, index, or collection. Cross-namespace queries should be an API-level impossibility, not an application filter.
  5. Cache and trace logs. Cache keys include tenant id. Traces are tagged with tenant id and routed to a tenant-scoped log store, or stored in a shared store with strict role-based access.
  6. Tool credentials and outbound auth. Per-tenant credentials for every tool the agent can call. No shared keys; tokens are vaulted and rotated.

Vector store isolation patterns

The retrieval layer is where the most common isolation bugs hide. Three patterns, from strongest to weakest.

Per-tenant index or collection. Each tenant gets a dedicated index in the vector database. Queries are scoped at the API by index name. Cross-tenant queries require a different API call and a different IAM grant. This is the cleanest model and what major vector databases now recommend (Pinecone multi-tenancy, 2025; Weaviate multi-tenancy, 2025). Cost trade-off: more indexes, slightly higher overhead.

Per-tenant namespace within a shared index. One index, namespaces partition the data. Queries must specify a namespace; the API enforces the boundary. Cheaper than per-index, equally strong if the API truly rejects cross-namespace queries (most do; verify with a test).

Per-row filter with shared index and no namespace. All tenants' vectors in one index; queries include a tenant_id filter. Weakest. The control depends on every query path applying the filter; one missing filter is a cross-tenant leak. Avoid for any production multi-tenant agent.

Prompt cache and traces

Prompt caching cuts cost (cached input tokens at roughly 10 percent of fresh rates on Anthropic, OpenAI, and Google) but introduces a subtle isolation surface (Anthropic prompt caching, 2025). If two tenants share a system prompt that you cache at the provider, the cache itself is per-API-key on most providers, so per-tenant API keys give you natural isolation. If you build a cross-tenant cache layer yourself, tenant id must be part of the cache key.

Trace and prompt logs need the same discipline. Logs are tagged with tenant id; the dashboard view enforces a tenant filter; cross-tenant queries require an explicit admin grant and a logged justification. SOC 2 auditors increasingly ask to see this access path, especially for logs that contain customer prompts.

Tool credentials and outbound auth

The biggest leak surface in production agent platforms is shared service accounts. The agent calls "Slack" with one workspace token, even though four tenants connected four different workspaces. Tenant A's agent could (accidentally or via prompt injection) read from tenant B's workspace.

The pattern: each tenant connects their own credentials, the platform stores them in a per-tenant vault entry, and the runtime injects them at call time. The agent code never has access to a credential outside the tenant it is running for. Rotation is per tenant, revocation is per tenant, scope follows the principle of least privilege. See the agent security checklist for the broader credential discipline.

Testing isolation in CI

Three test classes run on every deploy.

  1. Direct API tests. Sign in as tenant A; query for an asset that exists in tenant B; assert empty result, denied access, or a 404. Run for every tenant-scoped resource: documents, vectors, traces, memory, tool credentials, agent runs.
  2. Cross-tenant retrieval probe. Insert a known canary vector with a unique string into tenant B's namespace. Issue a query for that string as tenant A. Assert zero results.
  3. Cache poisoning probe. Cause tenant A to run a prompt that caches. Run tenant B with a prompt designed to collide. Inspect whether tenant B receives tenant A's cached completion. (Most managed caches will not allow this; the test confirms.)

Any successful cross-tenant read or write is a P0. The incident gets a public-ish writeup, depending on customer impact, plus a remediation pull request that closes the path.

Evidence the auditor will ask for

For SOC 2 readiness, prepare three artifacts. First, an isolation architecture diagram that shows the tenant boundary at each layer. Second, the test suite output proving CI runs cross-tenant probes on each deploy. Third, the incident runbook for a confirmed cross-tenant leak (definition, severity, notification, remediation). Auditors sample; these three documents shorten the sample. Pair with the broader agent governance and compliance documentation.

Common isolation pitfalls in production

Four patterns recur in audit findings and incident reports across multi-tenant agent platforms.

The "platform admin" backdoor. A super-admin role can read across tenants for support. The role exists, the role is used during incidents, the role is logged but the log is not reviewed. The fix is not removing the role; it is reviewing the access log monthly and requiring an incident ticket id for every elevated read.

Embeddings reused across tenants. Two tenants happen to ingest the same public document. Their embeddings are byte-identical, and a deduplication-aware vector store could collide them at the index level. Per-tenant namespaces neutralize this; per-row filters do not.

Tool outputs that include other tenants' identifiers. A search tool returns IDs that the agent uses as input to a write tool. If the search results were not tenant-scoped, the write hits another tenant's resource. Scope at the tool, not just at the read.

Forgetting test tenants. A test tenant created during onboarding sits with prod-data leaked into it for QA. Six months later nobody remembers it exists. Test tenants get the same isolation tests and the same retention policies.

FAQ

What does multi-tenant isolation mean for AI agents?
A tenant's prompts, retrieval data, memory, tool credentials, model outputs, and traces stay within their tenant boundary. No data, query, or action ever surfaces in another tenant's context.
Is multi-tenant safe enough for regulated data?
Yes, when isolation is enforced at every layer and verified by automated tests. For some regimes (defense, internal-only finance), single-tenant or VPC is still mandated by policy.
How do I isolate vector stores across tenants?
Use a tenant-scoped namespace, index, or collection per tenant. Cross-namespace queries should be impossible by API design, not by application-layer filtering.
What about prompt caching across tenants?
Cache keys must include the tenant identifier. Most managed providers cache per API key, which gives you isolation if you use per-tenant keys.
Can one tenant's prompt injection affect another?
Only if shared memory or shared retrieval crosses the boundary. With per-tenant namespaces, per-tenant credentials, and no cross-tenant cache, prompt injection in tenant A cannot reach tenant B.
How do I test isolation is actually enforced?
Run automated CI tests that issue queries as tenant A targeting tenant B's identifiers and assert empty results, denied access, or explicit errors. Any success is a P0.

Sources