RAG Security & Tenancy Architecture

Tier: Advanced · Hands-on time: ~40 minutes

The canon takes this seriously: Azure's baseline chat reference architecture is explicitly network-isolated, and DPDP practitioner analysis is blunt that prompts, embeddings, and model outputs are all personal-data surfaces in their own right. The security track owns attack depth; the architect owns what this playbook produces — the isolation model, drawn and justified, before the first document is ingested. Retrofitting tenancy into a live index is the expensive version of this afternoon.

When to use

• A multi-tenant RAG product is being designed and tenancy isolation must be chosen before ingestion starts.
• A RAG corpus includes access-controlled documentsretrieval must respect source ACLs, not flatten them.
• Personal or regulated data will enter the pipeline and someone must answer "where does PII live once it's embedded?"
• Don't reach for this when the corpus is genuinely public, single-tenant marketing content — note that fact in the design and spend the effort elsewhere.

Prerequisites

• The tenancy facts: tenant count and growth, isolation obligations from contracts or regulation, noisy-neighbor sensitivity.
• The source-ACL model of the systems feeding the corpus (SharePoint permissions, repo access, HR-system roles).
• A chat assistant for adversarial design review, plus your diagramming tool of choice.
• Vendor docs for your RAG platform's access-control featurescapabilities differ sharply between managed offerings.

The workflow

1. 1.

   Map every place data rests or flows. Source documents, chunks, embeddings, vector index, retrieval cache, prompts, outputs, traces. For each: which tenant's data, which users may see it, and which regulation touches it. This map is the substrate for every later decision.

2. 2.

   Choose the tenant isolation model deliberately. The fork: index-per-tenant (hard blast-radius boundary, per-tenant deletion is index deletion, but cost and ops multiply with tenant count) versus shared index with metadata filters (efficient, scales to thousands of tenants, but every query is one missing filter clause away from cross-tenant leakage). Hybrids are legitimate — dedicated indexes for regulated or premium tenants, pooled for the rest. Write down which contractual promise ("your data is never co-mingled") the choice must honor.

3. 3.

   Design document-level authorization as a retrieval-time property. Source ACLs must survive into retrieval: carry permission metadata on every chunk, resolve the caller's entitlements at query time, and filter before the LLM ever sees context. Decide the staleness contract too — when a user loses access to a document, how long until retrieval reflects it?

4. 4.

   Red-team the design before review does. Vikram runs this on a BFSI knowledge copilot before it reaches his ARB:

   Copy

   Act as an adversarial reviewer of this RAG tenancy design (attached:
   isolation model, filter scheme, ACL sync approach).
   
   Attack it specifically on:
   1. Cross-tenant leakage: enumerate every query path where a missing or
      wrong metadata filter returns another tenant's chunks.
   2. ACL drift: what happens between a source-permission revocation and
      index sync? Who can see what during the gap?
   3. Embedding exposure: which fields end up inside embedding vectors,
      and what would deletion of one data principal's data actually require?
   4. Poisoning: which ingestion paths accept content that could carry
      injected instructions into future prompts?
   
   For each finding: severity, concrete scenario, and the design change
   that closes it. Do not soften findings. Flag anything you cannot
   assess from the attached material as UNKNOWN.
   

5. 5.

   Decide the PII-in-embeddings stance. Embeddings derived from personal data are personal-data surfaces. Options: redact PII before embedding (redaction gateway in the ingestion path), embed but scope deletion to chunk-plus-vector, or keep PII-bearing content out of RAG entirely. Whatever you choose, deletion must be executable: a named path from "data principal requests erasure" to vectors actually gone.

6. 6.

   Bound the poisoning surface. List every ingestion source that accepts third-party or user-supplied content; those documents can carry adversarial instructions into prompts. Design the mitigations you can draw: source allowlists, content quarantine on ingest, and clear provenance metadata so a poisoned answer can be traced to its chunk.

7. 7.

   Ship the artifact. One diagram (data flows with trust boundaries), the isolation ADR (model chosen, rejected alternative's best argument, revisit trigger at tenant-count or regulation change), and the authorization design table (surface × control × staleness contract).

Verify before you trust it

• Filter enforcement is proven with a hostile query. In a test index with two fake tenants, run queries as tenant A engineered to want tenant B's content; zero cross-tenant chunks is the pass bar. A design review is not this test.
• Platform access-control claims checked in vendor docs. Managed-RAG offerings differ on metadata filtering, per-user authorization, and encryption scope — confirm the specific features your design leans on exist in your platform and region, in current documentation.
• The deletion path executes end to end. Delete one test principal's document; verify the chunks and vectors are gone and retrieval no longer surfaces the content. Time it — that number goes in the compliance story.
• ACL sync staleness measured. Revoke a permission at the source and measure how long retrieval keeps serving the document. If the number embarrasses the design, the design changes.
• AI red-team findings triaged, not transcribed. Each finding is confirmed or rejected by a human with the design in hand; rejected findings get a one-line reason in the review record.

Restricted-environment variant

Per MSA discipline, the isolation design itself may be client-confidential — build it in client-approved tooling or describe the architecture abstractly (tenant classes, not client names) to external assistants. Use synthetic tenants and schema-faithful fake documents for all leakage testing; real tenant data never enters test indexes. Where contracts require, place the whole pipeline in client tenancy — Bedrock or Azure OpenAI inside the client subscription with private endpoints — and for the strictest data classes run embedding and retrieval locally (Ollama + pgvector) so vectors never leave the boundary.