BLUF: Choose multi-tenant RAG isolation according to the consequence of a boundary failure, not the number of customers. A pooled vector index with a mandatory tenant metadata filter is efficient, but its boundary is only as strong as the code that derives and applies that filter. Use a silo when contractual, regulatory or blast-radius requirements demand dedicated resources. Use a bridge when a small set of high-assurance tenants needs silos while the long tail can share a pool. A vector database with native multi-tenancy offers a fourth implementation choice: one collection with a separate physical shard per tenant, so the database requires tenant context on each operation. Whichever pattern you choose, derive tenant identity from authenticated claims, deny when context is missing, apply the boundary before retrieval, and test cross-tenant non-disclosure as a release gate.
The security boundary is the retrieval call
RAG access control must act before candidate chunks enter the prompt. Redacting the generated answer is too late: unauthorized text may already have reached the model, traces, caches or evaluation logs. The foundational RAG access-control pattern therefore binds the authenticated principal to permitted document attributes before vector search. Multi-tenancy adds a stricter question: is that binding implemented by application logic, a policy decision point, a database tenant selector, or an infrastructure boundary?
AWS describes three SaaS isolation concepts for multi-tenant RAG: silo, pool and bridge. In its Bedrock Knowledge Bases reference, silo deploys the RAG stack independently per tenant; pool shares the end-to-end stack and filters documents with tenant metadata at retrieval; bridge keeps shared infrastructure while assigning separate data sources, knowledge bases and vector indexes to tenants. These are patterns, not compliance certifications. Source: AWS multi-tenant RAG reference architecture.
Four boundary placements, not three product labels
Silo places the boundary around dedicated infrastructure: tenant-specific object storage, knowledge base and vector store or index. Pool places it inside every query: a shared collection is searched only with an authenticated tenant filter. Bridge places it in a tenant-to-resource mapping: requests select a dedicated index or stack for some tenants while others use shared resources. Native database multi-tenancy places the selector at the database API and stores each tenant on a separate shard inside one collection.
Weaviate documents that each tenant in a multi-tenancy collection is stored on a separate shard and that data in one tenant is not visible to another. Its clients require a tenant name for CRUD operations. That shifts enforcement from an arbitrary metadata predicate to the database’s tenant-aware operation path, but it does not eliminate application responsibility: the application can still select the wrong tenant, auto-create a misspelled tenant, leak through caches, or mis-handle backups. Source: Weaviate multi-tenancy operations.
Reference architecture: identity to tenant-scoped retrieval
CLIENT → identity provider → API gateway → authentication middleware → immutable tenant context → authorization decision → isolation router → [POOL: shared index + mandatory tenant filter] OR [NATIVE: collection.with_tenant(tenant_id)] OR [BRIDGE/SILO: tenant registry → dedicated knowledge base/index] → retriever → authorized chunks only → prompt builder → model → response → tenant-scoped cache and audit log.
The immutable tenant context is the control point. Build it from a verified token claim or a server-side subject-to-tenant mapping; never accept tenant_id from the request body as authoritative. Remove public retrieval methods that do not require this context. The retriever should expose one typed operation such as retrieve(TenantContext, Query), not a generic vector-client handle that downstream developers can call without a boundary.
Fail closed at every transition
The request path should reject missing, ambiguous, expired or conflicting tenant context before retrieval. Authorization denial must produce no query, not an empty filter object whose vendor semantics may mean “match all.” If the policy service, tenant registry or filter builder times out, return an authorization error. Retries must preserve the same verified tenant context; asynchronous jobs must carry a signed or server-issued tenant envelope rather than replaying user-supplied metadata.
AWS’s current Verified Permissions architecture explicitly distinguishes logical metadata-filter isolation from infrastructure isolation. It warns that middleware which fails open can expose documents from other groups, positions the example for fine-grained access within one tenant, and recommends a dedicated knowledge base with IAM-enforced boundaries when hard cross-tenant isolation is required. This is a useful engineering boundary even outside AWS. Source: AWS secure RAG with Verified Permissions.
Decision table: silo, pool, bridge or native shard
Requirement | Pool with metadata filter | Native tenant shard | Bridge | Silo Boundary enforcement | Application/policy layer constructs mandatory predicate | Database requires tenant selector and stores separate shard | Router maps tenant to shared or dedicated resource | IAM/resource boundary and dedicated stack Best fit | Many similar, lower-assurance tenants with strict cost pressure | Many tenants when the chosen database supports native isolation | Mixed assurance tiers or noisy-neighbour profiles | High-assurance tenant, bespoke configuration, strict blast radius Main advantage | Lowest infrastructure cost and simplest onboarding | Stronger database-enforced separation without one collection per tenant | Cost follows tenant tier | Strongest architectural independence and performance isolation Main failure mode | Missing, malformed or bypassed filter returns foreign chunks | Wrong tenant selected; typo creates orphan tenant; cross-layer cache leak | Stale registry routes tenant to wrong index | IaC drift, quota sprawl, expensive fleet operations Operational burden | Metadata integrity, filter tests, tenant-attributed telemetry | Tenant lifecycle, shard state, backups and capacity | Both pool and silo runbooks plus routing registry | Per-tenant provisioning, upgrades, monitoring, deletion and quotas Choose when | A documented risk decision accepts logical isolation | Database feature is validated and contractual needs permit shared cluster | Tenant classes have materially different requirements | Failure consequence justifies dedicated cost and operations
AWS’s comparison notes further trade-offs: the pool pattern has no vector-store performance isolation, while silo has the highest cost and hardest onboarding. Bridge offers tenant-specific configuration without fully independent infrastructure. Treat those characteristics as inputs to a cost and risk model; measure them against your provider’s current quotas and topology rather than copying one cloud diagram.
Compliance tiering is an engineering input, not a legal verdict
Create an isolation policy with tiers. Example: Tier A requires dedicated resources, customer-managed keys where available, independent deletion evidence and tenant-specific incident containment. Tier B permits a database-native shard within a shared cluster if penetration tests, backup handling and contractual terms are accepted. Tier C permits a pooled index with policy-derived metadata filters, synthetic cross-tenant tests and bounded data sensitivity. The labels are internal engineering categories, not legal categories.
Whether a contract, sector rule, data-protection assessment or supervisory expectation requires physical separation is a question for counsel, security and the accountable business owner. Engineering should supply the data-flow map, threat model, provider controls, residual risks, deletion behavior, test evidence and cost options. It should not claim that “separate shard” or “separate index” is legally sufficient without that review.
Ingestion must enforce the same boundary
Query isolation fails if ingestion labels are wrong. Bind each source connector to a server-side tenant identity. Write tenant_id as immutable provenance; reject updates that attempt to move an object between tenants; and include tenant, source object ID, content digest, parser version, embedding model and index target in the manifest. In a pool, require the sidecar or metadata field before indexing. In a silo or bridge, verify that the destination resource belongs to the connector’s tenant.
AWS’s pool example uses an object metadata sidecar containing tenantId and applies an equals filter on that key during Retrieve or RetrieveAndGenerate. It also notes that a missing metadata sidecar makes the document unavailable to metadata filtering. Production code should convert that observation into an ingestion quarantine: a document without validated tenant metadata must never enter the searchable corpus. Align retention and deletion with the RAG data-governance control plane.
Tenant-scoped caches, sessions and traces
Vector retrieval is not the only leakage path. Prefix every semantic cache, response cache and embedding cache key with tenant ID, authorization-policy revision and relevant document scope. Bind conversation sessions to the authenticated subject and tenant at creation; revalidate the binding on every turn. Do not allow a session ID to become a bearer credential across tenants. Store traces in tenant-aware partitions or enforce equivalent row-level access, and redact chunk bodies unless operationally necessary.
The AWS Verified Permissions reference recommends cryptographically random session IDs bound to user identity and group, with revalidation on subsequent requests and invalidation after membership changes. The same principle applies to customer tenants. Audit evidence should capture subject, tenant, authorization decision, policy revision, resource route, filter digest, retrieved document IDs and denial reason without logging unnecessary document content.
Six failure modes to test before production
1. Filter omission. A new code path calls the vector client directly and leaves out tenant_id. Prevent it structurally; then inject the defect in a test and require denial. 2. Fail-open error handling. Policy timeout or malformed claims become an empty filter. Map every indeterminate state to deny. 3. Ingestion mislabelling. A connector writes tenant B content with tenant A metadata. Reconcile source ownership against manifests before indexing. 4. Cache collision. Identical questions share a cache key across tenants. Include tenant and policy revision in every key and purge on authorization change. 5. Bridge routing drift. A tenant moves from pool to silo while workers retain stale routing. Version the tenant registry, make migration states explicit, dual-read only under controlled reconciliation, and block ambiguous writes. 6. Deletion gaps. Removing source files does not prove vectors, caches, backups and traces were deleted. Maintain a deletion ledger with provider-specific completion evidence.
Negative tests are the primary acceptance tests
Create at least three synthetic tenants with unique canary phrases and overlapping semantic topics. For every API, tool path and asynchronous worker, assert that tenant A retrieves only A canaries, receives no B/C document IDs, and leaves no B/C identifiers in traces or cache entries. Run tests for missing tenant, modified token, mismatched URL/body tenant, policy outage, retry, pagination, hybrid keyword/vector search, reranking, streaming, session continuation and batch ingestion.
Add property-based tests that generate tenant/filter combinations, static checks that prohibit raw vector-client imports outside the retrieval boundary, and an integration test against the real database. In canary deployment, monitor denied retrievals, zero-result rate, documents lacking tenant metadata, cross-tenant canary detections, routing-registry mismatch and cache-key cardinality. Record these controls in the RAG security operating model and retrieval evidence trail.
Implementation checklist
Architecture: classify tenant tiers; document enforcement layer; map every store, cache, session, trace and backup; define deny behavior. Identity: derive tenant from verified claims or server mapping; prohibit request-body authority; bind service jobs to server-issued context. Ingestion: verify source ownership; require immutable tenant provenance; quarantine missing metadata; reconcile target resource. Retrieval: expose only a tenant-required interface; apply boundary before search; deny on policy or registry errors; log filter and route digests. Testing: seed canary documents; execute cross-tenant negative tests on every path; test migration and deletion; scan for bypass imports. Operations: monitor noisy neighbours and shard capacity; version tenant routing; rehearse pool-to-silo migration; retain deletion evidence. Governance: obtain security, procurement and legal review for contractual or regulatory claims; record residual risk and approval.
Trade-offs and limitations
Silos reduce shared blast radius and noisy-neighbour risk, but multiply infrastructure, quotas, upgrades and deletion workflows. Pools minimize idle capacity, but logical isolation depends on complete metadata and non-bypassable query construction. Native shards improve database-level isolation, yet a wrong tenant selector, shared cache or provider backup behavior can still leak data. Bridge architectures fit mixed portfolios but create two operating models and a routing control plane that becomes security-critical.
Physical separation is also a spectrum: separate shard, index, collection, cluster, account and region provide different controls. Product terminology does not prove which resources, encryption keys, memory, logs or backups are shared. Verify the implementation and contract. Performance isolation must be load-tested; security isolation must be negatively tested; deletion must be evidenced end to end.
Sources and interpretation boundary
Primary and authoritative references: AWS multi-tenant RAG with Bedrock Knowledge Bases; AWS secure multi-tenant RAG with Verified Permissions; Weaviate multi-tenancy operations; and AWS SaaS tenant-isolation concepts. Vendor architectures describe implementation options and limitations; they do not certify a particular deployment or replace legal, contractual or security review.
Make the tenant boundary executable
If your RAG platform is moving from one internal knowledge base to a customer-facing multi-tenant service, I can help turn the isolation decision into an executable design: tenant tiers, identity binding, retrieval interface, pool/silo routing, negative-test suite, migration runbook and audit evidence. The useful deliverable is not a diagram labelled “secure.” It is a boundary that cannot be omitted by an ordinary code path and a test suite that proves foreign chunks stay out.
