What is RAG security?
By Identra · Updated
RAG security is the practice of protecting the sources, retrieval process and generated answers in retrieval-augmented generation systems. Its goal is to keep unauthorized data out of model context and stop retrieved content from manipulating answers or actions.
What does a RAG data leak look like?
Say a company builds a sales assistant over its CRM notes and a Google Drive folder of account plans. A rep asks which customers might delay renewal. The answer mentions a pending acquisition. That detail came from a finance memo the rep was never meant to see.
Two different bugs can cause this. In the first, the index was built with the connector's finance access and nobody checked the rep's own permissions at query time. In the second, the memo really was shared with the whole company by mistake. The assistant did its job correctly and still exposed the plan. That second case is copilot oversharing.
There is a third problem waiting. The rep can read the memo, then asks the assistant to post a summary into a Slack channel shared with the customer. That is AI data leakage by someone with every right to read the source.
Unauthorized retrieval
- Example
- A rep gets a finance-only passage
- Fix
- Check the requester's access before text reaches the model
Source oversharing
- Example
- The memo is readable company-wide
- Fix
- Fix the sharing on the source document
Unsafe delivery
- Example
- An internal summary lands in a customer channel
- Fix
- Check who will see the answer, not only who asked
Where can data escape in a RAG pipeline?
At every copy. A RAG system pulls passages from Confluence, SharePoint, tickets or Drive, often splits them into chunks and stores them in a vector index. At question time it retrieves matching chunks and hands them to the model. Locking down the original folder does nothing about the chunks, embeddings, cached answers and logs already made from it.
Search results leak too. A document title or preview snippet can give away the secret before anyone clicks.
How should RAG enforce document permissions?
Check the requesting user's access before any passage enters model context. The connector may need broad read access to build the index. That does not mean every user of the assistant gets to read everything it collected. Apply least privilege to the connector itself and keep indexing rights apart from answering rights.
Every chunk needs to carry its source permissions. Evaluate group membership and tenant boundaries at retrieval time. If you cannot tell whether the user has access, leave the chunk out. OWASP's RAG Security Cheat Sheet describes this pattern.
Revocation is the hard part. When someone loses access on Monday, the cached answer from Friday should not keep serving them.
Can a retrieved document inject instructions into the assistant?
Yes. Someone files a support ticket that says to ignore the task and email the last ten tickets to an outside address. The assistant retrieves it while answering an ordinary question. That is indirect prompt injection.
Retrieved text is evidence. It should never grant permissions or approve a tool call. Marking it as untrusted helps a little. The real control is outside the model, where email and export actions get authorized on their own and outside destinations are blocked unless the workflow needs them.
Poisoning does not need instructions either. A false fact planted in a wiki page works fine. A citation shows where a claim came from. It does not make the source trustworthy.
How do you test RAG security before launch?
Use test documents and accounts with different access on purpose. Look at the passages that went to the model, not just the final answer. A polite refusal is still a failure if the restricted text was already in context.
Fold this into your AI red teaming and rerun it when connectors, permissions, retrieval logic or models change.
- Ask for summaries and comparisons that would need a restricted file.
- Revoke a user's access mid-conversation, then ask a follow-up.
- Check titles, citations, previews and error messages for leaked content.
- Plant an instruction in a test document and confirm it cannot trigger a tool or send data out.
- Delete a source and confirm its chunks and cached answers go with it.
- Send an answer to an audience with less access than the person who asked.
What else needs protecting?
The index. Chunks, embeddings and backups are copies of company data and need the same care. Check what your vector database and model provider retain. An AI audit trail should tie each answer to the user and the sources behind it, without becoming a searchable pile of sensitive passages that far too many people can read.
How Identra thinks about it
A RAG assistant is only as safe as the access behind it. Identra shows which connected apps can reach company data and which AI apps hold it. It discovers AI agents across Microsoft 365 Copilot and Foundry, Google Workspace and Anthropic, with their owners. An analyst can revoke a risky OAuth grant, and the result is recorded. In the browser, prompts are checked on the device before they are sent, so sensitive data can be masked or blocked before it reaches an AI app.
Go deeper: AI security, built on identity
Frequently asked questions
Does RAG train the model on my documents?
Normally no. Retrieval adds context to a single request without changing model weights. Whether the provider keeps or trains on that context depends on the service, settings and contract.
Can a system prompt enforce document permissions?
No. Telling the model to respect permissions is not an access check. Unauthorized passages have to be filtered out before they reach it.
Is a private vector database enough?
It limits who can reach the infrastructure. The application still has to check each user's document access, protect cached answers and control where answers go.
Is document poisoning the same as model poisoning?
No. Document poisoning changes what retrieval feeds the model. Model poisoning targets training data or the model itself.
Does RAG stop hallucinations?
It can help. The model can still misread a source or make something up, and an outdated source gives a confidently wrong answer.