Threat model: data leak through retrieval
Most teams secure the chat UI and forget the retrieval path. The model only sees what the retriever returns — so if the index can surface a document the user should never read, the assistant will happily summarise it. That is the core RAG security threat: confidential data leaving through answers, citations, or copied chunks, not through a dramatic jailbreak demo.
Attackers (and curious employees) do not need to crack the model weights. They ask questions that pull neighbouring chunks from shared indexes, probe for filenames in citations, or paste content that steers retrieval toward restricted collections. The failure mode looks like a helpful answer with a footnote the user was never entitled to open.
This sits inside the broader production picture in our RAG and LLM production guide. Governance is not a chapter you bolt on after quality looks good; it is a constraint on how you index, retrieve, and log from day one.
Scope the system before you scare the room. An internal assistant over a curated policy wiki is not the same as a customer-facing copilot over CRM notes and contracts. The threat model, the ACL scheme, and the logging depth should match the data class and the blast radius — not a generic "AI security" checklist copied from a vendor deck.
ACL and permissions belong in the index path
Prompt instructions such as "only use documents the user may see" are not access control. Real RAG governance enforces permissions where vectors are filtered: at query time, with the same identity the application already trusts.
Practical patterns that hold up:
Store ACL metadata with every chunk — tenant, department, document ID, classification, allowed groups. Filter before similarity ranking, or with a hard post-filter that drops unauthorised hits before they enter the prompt. Prefer the same identity provider claims the rest of your stack uses; inventing a parallel permission model for RAG guarantees drift.
Multi-tenant SaaS products need hard tenancy isolation in the retrieval query, tested the way you would test any IDOR. Shared indexes with "careful prompting" are how confidential corpora end up in the wrong answer stream. The retrieval engineering behind this is the same craft described in RAG systems in production — metadata, filtering, and evaluation — pointed at access rather than relevance alone.
Service accounts deserve the same scrutiny. The pipeline that builds embeddings often runs with broad read access. Constrain what it can ingest, prefer least-privilege per corpus, and record which principal built which index version. A compromised build job with world-read on the file store is a quieter disaster than a flashy prompt injection demo.
Test negative cases in CI: a user from tenant A must not retrieve tenant B chunks; a role without HR access must not surface compensation passages; a revoked user must fail closed after ACL sync. Positive relevance tests are not a substitute for these access tests.
PII, redaction, and data boundaries
Enterprise RAG compliance starts with knowing what entered the index. Classify sources before embed: public knowledge base, internal policy, customer PII, regulated health or financial data. Not every corpus belongs in the same collection, and not every collection should share an embedding space with customer-facing chat.
Redact or tokenise high-risk fields at ingest when the assistant does not need the raw value — national IDs, full payment details, secrets. When the raw value is required for a closed workflow, keep that collection behind stricter ACL and shorter retention. LLM data governance is mostly boring data hygiene applied earlier than teams expect.
Be explicit about training and retention commitments with model providers. If your contract says prompts are not used to train, keep the paper. If you run self-hosted models for sensitive corpora, say so in the design and in the DPIA or equivalent — not as marketing, as an architecture decision with owners. Enterprise RAG compliance is mostly evidence of decisions like these, not a badge on a homepage.
None of this is theatre. It is the unglamorous work that lets security and legal review a RAG design without inventing a new framework from scratch.
Audit logs you can defend
When someone asks "who saw what," you need more than model provider invoices. Log, at minimum: the authenticated principal, the query (or a hashed/redacted form if policy requires), which document IDs and chunk IDs were retrieved after ACL filters, whether generation completed or refused, and the model/prompt versions in play.
Retention for those logs should match your existing security logging policy — not "forever in a random bucket." Access to the logs themselves is sensitive; treat them as production security data. Pair logs with the evaluation loop: samples from production failures become offline tests, including cases where retrieval returned the wrong tenant's content and should have been empty.
Exportability matters. If an auditor or customer asks for evidence of access control on a given day, you should be able to produce it without reconstructing folklore from Slack. That is LLM data governance in practice: reconstructable decisions, not aspirational policy text.
Prompt injection and hostile content in the corpus
Retrieved text is untrusted input. A document can contain instructions that try to override the system prompt, exfiltrate earlier context, or coerce tool calls. Defences that help without theatre: separate system instructions from retrieved passages in the prompt layout; instruct the model to treat corpus text as data; strip or escape instruction-like patterns where feasible; and never grant tools solely because a retrieved paragraph asked for them.
For higher-risk assistants, add detectors or policies for exfiltration-style asks ("list all API keys in context"), and default to refusal when retrieval returns secrets patterns. Corrective or gated retrieval patterns help when weak or suspicious context should not reach generation unchanged — but they do not replace ACL filters.
Document-borne injection is easy to underestimate because the text looks like ordinary content. A resume, a vendor PDF, or a pasted email can include instructions aimed at the model. Strip or escape instruction-like patterns where you can, and never let retrieved text set tool permissions or URL allowlists. Tools that can send email, open tickets, or fetch arbitrary URLs need their own authorisation checks independent of what the model "thought" the document asked for.
Red-team the assistant with the same creativity an insider would use: "ignore previous instructions," encoded asks, gradual escalation across turns, and questions that try to get the model to quote system prompts or hidden policies. Feed failures back into the eval suite — see LLM evaluation in production — because RAG governance without regression tests decays as fast as untested access control.
From policy to engineering checks
Policies that say "protect customer data" do not ship. Translate them into checks the pipeline can fail:
No document enters the index without a classification and ACL metadata. Retrieval queries without a verified principal fail closed. Cross-tenant retrieval tests run in CI. PII redaction rules are versioned with the ingest job. Audit log completeness is monitored, not assumed. Prompt and tool changes go through the same review as application code.
Write those checks down next to the runbook. "We follow security best practices" is not evidence. A failing CI job when a retrieval path returns cross-tenant hits is evidence. So is an access review that includes the RAG service account and the index, not only the app servers.
Connect incidents to the same loop. If a document was exposed, you need a path to purge vectors, rotate secrets if they appeared in chunks, notify according to policy, and add a regression test so the failure mode stays closed. If you cannot purge, you do not control the index — and RAG security is still aspirational.
Keep the tone proportional. Most enterprise RAG programmes fail on missing filters and missing logs long before they meet an exotic attacker. Fix the data path, measure it, and only then invest in exotic detection. Fearmongering decks sell workshops; disciplined retrieval controls ship.
If you want help turning those policies into a retrieval design and the gates around it, talk to us about enterprise AI consulting or generative AI and LLM development, or contact Rowth.ai with the data classes you plan to index.
Frequently asked questions
It is securing the retrieval path as carefully as the model: who can retrieve which documents, how answers are logged, how personal data is handled, and how the system resists prompt injection and data exfiltration through clever questions. The model is only one component; the index and the permissions around it are usually the larger risk.
ACLs on source files do not automatically apply inside a vector index. If embeddings are built without carrying forward user, group, or tenancy filters — and if those filters are not enforced at query time — a user can retrieve passages they could never open in the source system. Governance has to live in the retrieval layer, not only in the document store.
Log the question, the principal, the retrieved document IDs and versions, the model and prompt versions, the answer, and any refusal or escalation. Keep retention aligned with your existing audit policy. Auditors rarely ask for the embedding math; they ask who saw what, on what basis, and whether you can reconstruct it.
No credible vendor stamp replaces your own access design, logging, and data-handling controls. Map RAG to the policies you already run for data platforms — access reviews, retention, DLP, incident response — and engineer the retrieval path to honour them. Claims of being generically "AI compliance certified" without that mapping are marketing, not governance.