BLUF: an enterprise RAG system is not secure because it has an ACL filter and a vector database. It is secure when a named owner can show, for every answer, which identity was evaluated, which policy version applied, which source chunks were eligible, what was redacted, and how an exception or incident is handled. Treat that as an operating model—not a feature checklist.
Why the controls must operate together
The pipeline crosses several security boundaries: source onboarding, classification, chunking, embedding, retrieval, prompt construction, model output and operational evidence. A policy enforced only in the front end fails when another integration calls retrieval directly. A filter applied after top-k search can still expose unauthorized text to a model context. A log that records only the final answer cannot explain whether access was correctly denied.
OWASP’s 2025 LLM08 guidance explicitly identifies unauthorized access, cross-context leakage and data poisoning as RAG risks, and recommends fine-grained, permission-aware vector stores with logical partitioning. The practical implication is simple: authorization has to be evaluated before content is selected for the prompt—not inferred from the answer afterwards.
The minimum production control path
1. Bind a stable requester identity and relevant attributes to each request. Capture the human user, service identity, tenant or business unit, role, purpose where applicable, and authentication strength. Do not let a conversational session label substitute for identity.
2. Preserve source metadata through ingestion. Each chunk needs an immutable source ID, source version, classification, owner, allowed audience, retention state and policy-relevant attributes. Re-indexing must carry the metadata forward; otherwise the new index silently becomes a wider access path.
3. Make the retrieval service the policy enforcement point. It should turn identity and attributes into an allow-list or a server-side filter before candidate chunks become model context. The application must not rely on the LLM to respect a document label. For high-risk boundaries, separate indexes or tenants reduce blast radius, but they increase operational cost and update complexity.
4. Construct the prompt from the authorized, minimally necessary excerpt. Apply deterministic redaction for secrets, personal data or restricted fields before context assembly. Redaction is not a replacement for authorization: if a source is prohibited, do not retrieve it merely because a pattern scanner might remove part of it.
5. Emit evidence at each decision point. Record a correlation ID, requester and service identity, policy version, retrieval filter or decision reference, candidate and returned source IDs, redaction action, model and prompt-template version, response disposition, latency and error class. Avoid logging raw sensitive passages by default; the evidence store itself needs access control and retention rules.
An operating model: ownership, change and revocation
Give the knowledge-base owner accountability for source fitness and classification. Give the IAM or platform owner accountability for policy evaluation. Give the product owner accountability for intended users and escalation paths. Security should approve the control design and periodically test it; it should not become the queue that manually approves every document.
The highest-value test is revocation. Remove a user from a group, change a document classification, delete a source, or expire a retention rule; then prove that the old chunks are unavailable across every index, cache, reranker and conversation memory. Define a measurable revocation objective. A system that updates nightly may be acceptable for a low-risk handbook, but it is not acceptable for incident records or personnel data where access must disappear promptly.
Incident response for RAG leakage
Prepare a runbook before deployment. On suspected leakage, first stop the affected retrieval route or tenant scope, preserve the correlation IDs and policy/index versions, and determine whether the issue was authorization, stale metadata, a cache, a connector or prompt injection. Then contain: revoke the affected entitlement, invalidate derived artifacts, rotate any exposed secrets, and notify the appropriate internal incident process. Legal notification duties depend on the facts and jurisdiction; obtain legal review rather than treating this technical article as legal advice.
A useful investigation can answer five questions quickly: who requested the answer; which policy allowed it; which chunks reached the model; whether the output contained those data; which other requests used the same stale index or cache. If those answers require reconstructing several disconnected logs, your design is not audit-ready.
A practical acceptance test
Before go-live, test with synthetic restricted documents and identities that should be allowed, denied and recently revoked. Include cross-tenant queries, stale ACL changes, connector failures, poisoned documents that contain instructions, empty retrieval, and a fail-closed policy-service outage. Measure both security and service behavior: denial correctness, unauthorized-chunk rate, revocation time, audit-event completeness, retrieval latency and false-positive redaction rate.
Do not silently fail open when the identity, policy service or metadata is unavailable. A fail-closed retrieval path can reduce availability, so define a business-approved fallback—for example, an answer limited to public curated material or an explicit ‘I cannot access this source right now’ response. That trade-off is more defensible than supplying plausible but unauthorized context.
Decision checklist
You are ready to move beyond a prototype when you can answer yes to all of these: Is every chunk traceable to an owner and source version? Is authorization enforced before prompt construction? Can you demonstrate revocation across indexes and caches? Are redaction rules deterministic and tested? Can an investigator reconstruct one answer without storing unnecessary sensitive text? Is there an owner for policy drift and connector failure?
Sources
OWASP GenAI Project, LLM08:2025 Vector and Embedding Weaknesses: https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/
NIST SP 800-92, Guide to Computer Security Log Management: https://csrc.nist.gov/pubs/sp/800/92/final
This is implementation guidance, not legal advice. For regulated processing, align retention, access review and incident obligations with your organisation’s counsel and applicable requirements.
