Secure RAG Design Patterns for Enterprise Data

Secure RAG is not a vector database choice. It is an access decision that must finish before enterprise data reaches a model.

That is the line most designs blur. Teams focus on chunking, embeddings, ranking, and answer quality. Those choices matter. They do not answer the security question: why was this user allowed to place this exact passage into model context at this exact moment?

A secure retrieval augmented generation system has to preserve source authority across ingestion, indexing, retrieval, model use, citation, logging, and deletion. If one stage silently widens access, the system can produce a fluent answer from data the requester was never allowed to read.

This guide covers the enterprise design choice. The companion secure RAG architecture for GovCon goes deeper on CUI boundaries and contractor control context. The Private LLM and Secure RAG hub connects both guides to deployment and leakage prevention. GS Consulting applies these patterns through its secure AI automation work.

What Secure RAG Actually Means

RAG retrieves passages from approved sources and places them into the model context so the model can answer with current, specific material. Security depends on what the retrieval layer returns, not on a promise that the model will ignore material after it sees it.

The OWASP guidance on vector and embedding weaknesses identifies unauthorized access, data leakage, poisoning, and weak access controls as material risks. The NSA AI Data Security guidance treats data provenance, integrity, access, and monitoring as lifecycle concerns. Both point to the same operating conclusion: protect the data path, not only the answer screen.

A credible design has six connected controls:

1. Source authority. Know which system owns the content and which access rules remain authoritative.
2. Identity context. Resolve the user, service, role, tenant, device, purpose, and session conditions needed for the query.
3. Ingestion control. Preserve classification, ownership, permissions, version, retention, and deletion state with each chunk.
4. Retrieval enforcement. Apply current authority before content enters the candidate set or model context.
5. Answer traceability. Return usable citations and preserve the source, policy, model, and prompt versions behind the response.
6. Failure handling. Deny, narrow, or route to review when identity, metadata, policy, or source state cannot be trusted.

Five Questions That Choose the Secure RAG Pattern

Where does authority live? If the source system makes the current access decision, copying a stale permission list into a vector store may weaken the boundary. How much isolation is required? A business unit boundary is different from a customer, legal, export, or regulated data boundary. How quickly do content and permissions change? Daily synchronization may be acceptable for a policy library and unacceptable for case records. How many systems and tenants participate? Scale changes the cost of separate stores, delegated queries, and policy evaluation. What must an investigator prove? The answer needs a source, an authority decision, and a reproducible event trail.

NIST SP 800-207 says access should be determined per session and based on dynamic policy. That principle is directly useful for RAG even when the system is not a formal Zero Trust implementation. Retrieval should depend on current identity and resource facts, not on network location or a one time indexing decision.

Six Secure RAG Design Patterns

1. Shared index with metadata filters

One index holds content from multiple teams or sources. Every chunk carries authoritative fields such as tenant, business unit, role, sensitivity, owner, source identifier, and permission version. The query receives a mandatory filter built from current user context.

Use it when: knowledge is broad, sensitivity is moderate, metadata is stable, and a common retrieval service has strong test coverage. Do not use it when: a missing field or filter defect would cross a customer, legal, or regulated boundary.

2. Indexes separated by domain

Legal, human resources, finance, engineering, and other controlled domains use separate indexes or collections. Policy routes the user to an approved domain before search begins.

Use it when: a small number of durable business boundaries justify isolation. This pattern reduces the scope of a filter failure but adds synchronization, lifecycle, and ownership work.

3. Store per tenant

Each customer or tenant receives a separate vector store or a dedicated logical partition with independently enforced credentials and lifecycle. Shared application services may remain, but data plane authority stays tenant specific.

Use it when: tenant separation is a core contractual or product promise. The architecture must also prevent tenant mix ups in routing, cache keys, logs, evaluation data, and support tools.

4. Delegated source retrieval

The RAG service asks the source system to search or retrieve on behalf of the current user. The source retains its own permissions, current content, deletion state, and record authority.

Use it when: permissions or content change quickly and source search is capable enough. Microsoft describes this general principle in its secure multi tenant RAG guidance, which separates identity, data isolation, and application responsibilities. Delegation can preserve freshness, though latency and source availability become part of answer quality.

5. Brokered hybrid retrieval

A policy broker evaluates identity, purpose, data class, source capability, and query risk. It can search a shared index, a domain store, a tenant store, or the live source, then combine only authorized passages.

Use it when: the enterprise has mixed sensitivity, many systems, and more than one defensible retrieval path. This pattern offers the best fit in the GS model and the highest control burden because policy, routing, evidence, and recovery span several systems.

6. Isolated local RAG lane

Content, embeddings, retrieval, model execution, logs, and administration stay inside a dedicated environment. Movement into and out of the lane is explicit and reviewed.

Use it when: network separation, high sensitivity, mission continuity, or local control outweighs model variety and operating simplicity. Isolation does not remove insider, poisoning, privilege, or evidence risks. It changes where those risks must be controlled.

GS Secure RAG Pattern Fit Index

GS Consulting built a derived planning model to compare the six patterns across permission fidelity, isolation, freshness, audit evidence, scale, and simplicity. The base weights are 25, 20, 18, 17, 12, and 8 percent. Each pattern receives an analyst rating from 1 to 5 for a defined enterprise scenario.

Brokered hybrid retrieval scores 92.8 for mixed sensitivity across many systems. Delegated source retrieval scores 86.4 where source permissions and freshness dominate. Store per tenant scores 83.2 for customer isolation. Isolated local RAG scores 80.8 for disconnected or highly sensitive environments. Separate domain indexes score 78.4, and a shared index with metadata filters scores 74.4.

These are not product scores or universal rankings. They are planning values derived from the cited public guidance and stated analyst assumptions. A buyer should change the scenario ratings, weights, and thresholds before using the model. An alternate weight set changes the leading score by 1.0 point and changes no pattern by more than 3.0 points, so the broad ordering is stable under that limited test.

The public reference set includes the NIST Generative AI Profile, NIST SP 800-207, OWASP vector guidance, NSA data security guidance, the AWS generative AI security reference architecture, and the Google Cloud RAG reference architectures.

Pattern Fit Is Not Control Burden

The burden model scores integration, policy complexity, test load, operations, and cost. Brokered hybrid retrieval reaches 100.0. Isolated local RAG reaches 95.6. Delegated source retrieval reaches 93.2. Store per tenant reaches 86.8. Domain separation reaches 72.0. Shared metadata filtering reaches 61.2.

That does not make the shared design safest. It makes it simpler to operate. Choose the least burdensome pattern that can still hold the real data boundary. If a customer separation promise depends on every metadata field and every query filter being perfect, the apparent simplicity is false economy.

A Secure RAG Decision Path

1. Name the source authority. Record which system owns content, permissions, retention, deletion, and version state.
2. Define the security boundary. Separate ordinary business access from tenant, legal, regulated, or mission boundaries.
3. Measure change. Compare permission and content change speed with indexing and synchronization delay.
4. Select the retrieval pattern. Use shared, separated, delegated, hybrid, or isolated retrieval based on the first three decisions.
5. Prove denied behavior. Test missing identity, stale permission, malformed metadata, cross tenant query, deleted content, and unavailable source conditions.

The implementation should use one policy vocabulary across identity, source, index, broker, model gateway, and evidence. A role named differently in three systems is not merely a naming issue. It is a hidden authorization translation that must be owned and tested.

Six Secure RAG Failure Modes

Permission drift leaves the index behind the source. Missing metadata turns an unknown boundary into an allowed passage. Cache mixing reuses content across users or tenants. Deletion lag keeps removed content searchable. Citation mismatch points to a source that does not support the answer. Unlogged context prevents an investigator from reconstructing what the model saw.

Prompt injection belongs in the test plan too. Retrieved content can contain instructions that attempt to redirect the model or expose other context. Treat content as data, not authority. The retrieval layer, tool layer, and model gateway should keep instructions, data, permissions, and actions separate.

A 90 Day Secure RAG Plan

Days 1 through 30: authority and data

• Choose one business question and identify every source that could answer it.
• Map content owners, identity providers, permission rules, data classes, retention, and deletion paths.
• Measure how often content and permissions change and how quickly the RAG index can reflect that change.
• Define denied cases before building the useful query set.

Days 31 through 60: pattern and proof

• Choose the simplest pattern that can preserve the actual boundary.
• Carry source identifiers, authority fields, version, and classification with every chunk.
• Bind retrieval to current identity and purpose through mandatory policy.
• Record citations, policy decision, model version, prompt version, and exception path.

Days 61 through 90: adverse testing and operation

• Test valid access, denied access, revoked access, deleted content, missing metadata, source outage, and cross tenant requests.
• Measure unsupported answer rate, citation validity, denial accuracy, stale content delay, and exception volume.
• Assign policy, source, index, model, and evidence owners with a review cadence.
• Expand only after the team can explain both an allowed answer and a denied answer from the records.

The Minimum Secure RAG Evidence Packet

Keep eight records together: source register, access model, ingestion rules, retrieval policy, model context record, test results, exception decisions, and owner review. The Microsoft RAG enrichment guidance is useful for understanding chunk metadata and update design, while OpenFGA guidance for RAG authorization shows how retrieval can intersect with relationship based authority. Neither replaces an enterprise decision about ownership, retention, evidence, and acceptable failure.

Review the packet whenever the source, permission model, index process, embedding model, retrieval logic, prompt, generation model, or output control changes. A RAG system can preserve the same interface while its security behavior changes underneath.

Bottom Line

Secure RAG is not proved by a private endpoint, an encrypted vector store, or a model that produces citations. It is proved when the system can show why each passage was authorized, which source and version supplied it, what the model received, how denied cases behaved, and who reviewed exceptions.

That is the operating standard: authorized retrieval, traceable sources, tested denial, controlled model context, and no surprise data exposure.

Sources and Method Note

• NIST Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• NIST SP 800-207, Zero Trust Architecture
• OWASP Vector and Embedding Weaknesses
• NSA AI Data Security Guidance
• Microsoft Secure Multi Tenant RAG
• AWS Generative AI Security Reference Architecture
• Google Cloud RAG Reference Architectures

GS Consulting Original Research. The pattern scores are derived planning tools based on public sources and stated analyst assumptions. They are not measured security outcomes, legal advice, compliance determinations, or product endorsements. Validate the model against your data, contracts, authority, architecture, and risk process before use.

Frequently Asked Questions

Related Reading

• Private LLM and Secure RAG Hub
• Secure RAG Architecture for GovCon
• Preventing CUI Leakage in LLMs
• Data Classification Before AI Automation
• Secure AI Automation