Skip to content
AI Security & Governance

Secure RAG Architecture: answers only from what the user may see

Document-level ACLs, tenant isolation, retrieval filtering and citation enforcement, designed and implemented on the vector stack you already run.

  • pgvector, Milvus, Pinecone, Qdrant
  • Claude, OpenAI, Gemini, open models
  • Design review or full build
The problem

Three ways a naive knowledge base leaks

The index forgets permissions

SharePoint, Google Drive and your CRM know who may read a file. The vector index usually does not. One embedding job turns a restricted folder into public knowledge.

Tenants share a collection

In multi-tenant products, one collection with a tenant column is only safe if every query filters on it. One missed filter in one code path is a cross-customer breach.

Documents carry instructions

Anyone who can get a document into the index can get text into the prompt. Without provenance and scanning, the knowledge base is an injection channel.

Reference architecture

Permissions enforced before the model, citations checked after it

Secure RAG flow: the user's identity comes from the identity provider into the app; the app sends the query with tenant and group claims to the retriever; the retriever queries the vector index with a filter on tenant and ACL and receives only allowed chunks; the model drafts an answer with citations; a guard checks every citation against the retrieved set before the answer is shown. User tenant B · analyst App authenticated Retriever enforces ACL Model drafts + cites Guard citation check query + claims allowed chunks draft Identity provider tenant, groups, roles claims Vector index chunk + tenant + acl WHERE tenant = B AND acl ∩ groups top-k Answer verified citations pass Rejected uncited claim, retry Two gates: the filter before the model, the citation check after it. The model never sees a chunk the user cannot open, and cannot cite one it was not given.
Identity claims flow into the retrieval query; the guard rejects any answer whose citations are not in the retrieved set.
The four controls

What we design and implement

  • Document-level ACLs

    Every chunk carries the permission list of its source document: user ids, group ids or roles, copied at ingestion and refreshed on change. Permissions live in metadata, not in the prompt.

  • Tenant isolation

    One partition, collection or schema per tenant where the database supports it; a mandatory tenant filter injected by the data layer where it does not. The application code cannot forget it because it never writes the filter.

  • Retrieval filtering

    The retriever takes the caller's identity claims and applies tenant and ACL filters inside the vector query, before ranking. Post-filtering after top-k is not acceptable: it leaks through counts and can return empty results for authorised users.

  • Citation enforcement

    The model must cite chunk ids for every claim. A guard verifies each id exists in the retrieved set and that the quoted text appears in it. Uncited or mis-cited answers are rejected and regenerated, or shown with a visible warning.

Comparison

Naive versus secure RAG

ConcernNaive RAGSecure RAG
PermissionsLost at ingestionStored per chunk, filtered per query
Multi-tenancyTenant column, filter optionalPartition or enforced filter
Filter timingAfter top-k, if at allInside the vector query
Document provenanceUnknownSource, uploader, time, hash on every chunk
Injection in documentsPasted straight into the promptScanned, wrapped as data, flagged
CitationsDecorativeVerified against retrieved chunks
RevocationStale until re-indexEvent-driven removal + reconciliation
LoggingFull prompts, foreverChunk ids and user, redacted, time-limited
How we work

Design review or full build

  1. Map sources

    Where documents come from, who may read them, how permissions are expressed, how often they change.

  2. Choose the isolation model

    Partitions, collections or enforced filters, based on tenant count, data volume and your vector database.

  3. Build ingestion and retrieval

    ACL-aware ingestion, identity-aware retriever, citation guard, revocation handling.

  4. Test and measure

    Cross-tenant and ACL probes in CI, latency before and after filtering, answer quality on your eval set.

Stack we work with

PostgreSQL + pgvectorMilvusPineconeQdrantWeaviateClaudeOpenAIGeminiLlama / MistralPythonNode.js

A typical design review takes one to two weeks. A full secure RAG build for one source system runs four to eight weeks, including evals. Pair it with AI data privacy work if documents contain personal data.

FAQ

Frequently asked questions

Why is RAG a security problem? The model only reads documents.

Because retrieval copies documents into an index that usually has no access control, then pastes the best matches into the prompt. If the retriever does not check who is asking, the model will happily summarise a document the user could never open. See our RAG explained guide for the mechanics.

Can we enforce permissions with a prompt instruction instead?

No. Once a chunk is in the context window the model has already seen it, and models do not reliably follow restrictions about what to repeat. Permissions must be enforced in the retrieval query, before the model is called.

Which vector databases support this?

All the ones we work with: PostgreSQL with pgvector, Milvus, Pinecone, Qdrant and Weaviate support metadata filters or partitions that carry tenant and ACL data. The design differs; the principle does not. See vector database selection.

How do you keep permissions in sync when documents change?

Ingestion records the source system's ACL on every chunk and listens for changes. Revocations and deletions remove or re-tag chunks within an agreed window, and a periodic reconciliation job compares the index against the source.

Does this slow retrieval down?

Filtered search costs a little, especially when the filter is very selective. We design partitions and indexes so that tenant and ACL filters are cheap, and we measure latency before and after.

Ready to make AI work in production?

Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.