Secure RAG Architecture: Threat Modeling Retrieval-Augmented Generation Systems

Slug: secure-rag-architecture-threat-modeling Effective Date: 2026-05-17 Version: v1.0 Author: David Wolf Status: Draft Minimum Target Length: 2,000 words

RAG is not just search with a model on top. It is a controlled knowledge path. If retrieval is not governed, the model can be steered by the wrong documents, the wrong tenant, or the wrong metadata.

1. Why This Matters

RAG systems look safe because they feel familiar. The risk appears when retrieval, embedding, permissions, and generation are mixed without a trust model. Then the system can leak data even when the user interface looks simple.

2. Core Concept

Secure RAG starts with authorization-aware retrieval, provenance, and tenant isolation. If the model can read more than the user should see, the architecture is already behind.

3. Threat Model or Failure Model

• A poisoned or stale document changes the assistant's answer.
• Tenant boundaries fail and the retriever returns the wrong corpus.
• Metadata leaks enough context to expose private material.
• The output reproduces sensitive text because the system never limited retrieval scope.

4. Framework Mapping

Map the problem to OWASP for prompt and output abuse, NIST AI RMF for governance, and MITRE ATLAS for the retrieval and exfiltration path. Use CSA AICM or similar controls to structure the access model.

5. Engineering Controls

• Authorize retrieval before generation.
• Enforce tenant isolation at the vector and document layers.
• Track source provenance and document freshness.
• Add tests for poisoning, leakage, and cross-tenant access.

6. Tooling

• Use retrieval logs, corpus filters, and vector-store access controls.
• Keep embeddings, documents, and permissions in the same review process.
• Instrument the retrieval path so the answer can be replayed later.

7. Evidence and Observability

• Evidence should show what was retrieved, why it was allowed, and what the model emitted.
• A sample answer is not enough without the retrieval record.
• Keep the provenance and the permission state together.

8. Operating Model

Data engineering owns the corpus, platform engineering owns the retriever, and security owns the access model. The model should not decide which documents it is allowed to see.

9. Common Mistakes

• Treating the vector store as a simple search index.
• Skipping tenant isolation tests.
• Ignoring metadata leakage.
• Letting the model retrieve first and ask questions later.

10. Practical Example

A support assistant pulls policy documents for a customer. The right design proves that only that customer's documents were retrievable, that the corpus was fresh, and that the final answer did not quote private material from elsewhere.

11. Governance and Claim Caveats

• Sponsor support does not influence methodology, scoring, findings, chart outputs, or editorial conclusions.
• Job-description intelligence and public hiring signals are directional signals, not proof of internal security maturity.
• Psychometric outputs are role-language evidence, not diagnosis.
• Avoid accusatory company-level language.
• Avoid product endorsement language.

12. Conclusion

Secure RAG is a permission problem first and a prompt problem second. If retrieval is not governed, the model can only make the leak more fluent.

Implementation Checklist

• Authorize retrieval.
• Test tenant isolation.
• Track provenance.
• Limit metadata exposure.
• Log retrieval results.
• Retest after corpus changes.
• Review embedding pipelines.
• Document bypass paths.
• Keep caveats visible.
• Use replayable evidence.

Source Notes Needed

• RAG and vector security references.
• NIST AI RMF.
• OWASP LLM guidance.
• MITRE ATLAS.
• Vendor documentation for the selected vector stack.