Home / Knowledge hub / RAG security
Knowledge hub
RAG security
Controlling what a retrieval-based AI assistant can fetch and show to each person.
What it means
Retrieval-augmented generation, or RAG, is a way of building an AI assistant that first searches your own documents and then hands the best matches to a language model to write the answer. RAG security is the work of making sure that search and that answer respect your rules about who may see what.
The idea that makes it click: the model does not know your permissions. Whatever the search step puts in front of it, it will happily use. So the access check has to happen when documents are retrieved, for the person asking, not after the model has already read them.
Why it matters
A common failure is to index all company documents into one store and let any signed-in person query it. Then an ordinary employee, or a customer in a multi-tenant product, can ask a question and receive text drawn from files they could never open directly. It is broken access control with a friendly chat window.
A second risk is poisoned content. A document that contains hidden instructions can steer the model when it is retrieved, which is indirect prompt injection. The business cost is leaked customer or staff data, wrong answers given with confidence, and the audit question of who saw what.
How it shows up
You meet RAG in help-desk bots, internal knowledge assistants, document search and customer support tools. Behind them sit a store of embeddings, a search step and a model. Each stage can leak: the store may hold text from many tenants, the search may ignore the caller's rights, and the answer may quote sources the user should not see.
Good practice is to attach permissions to every stored chunk and filter by the asker's rights during retrieval, keep customer data in separate collections or enforce tenant isolation, treat retrieved text as untrusted input, log what was retrieved, and test with accounts of different rights. OWASP lists vector and embedding weaknesses among the top LLM risks.
Questions people ask
RAG security, answered
What is the biggest risk in a RAG system?
Usually a permission gap: the assistant retrieves content the asker is not allowed to see and quotes it in the answer.
The fix is to enforce access rules at retrieval time, using the signed-in person's rights, not just at the front door of the chat.
Does a system prompt stop the model sharing restricted data?
No. An instruction such as "do not reveal confidential files" can be bypassed, and it cannot enforce rules the model never sees.
If the text reaches the model, assume it can come out. Filter before retrieval.
Are embeddings safe because they are numbers?
Not entirely. Embeddings are derived from your text and research has shown that some information can be recovered from them.
Protect the vector store like the documents themselves, with access control and encryption.
How is RAG security different from prompt injection?
Prompt injection is one threat, where hostile text changes the model's behaviour. RAG security is wider and includes permission checks, tenant separation, poisoned sources and logging.
Injection through retrieved documents is a RAG-specific route.
How do we test a RAG assistant?
Sign in with accounts of different rights and ask for documents each should not see. Plant a test document with hidden instructions and see whether it changes the answer.
Check logs for what was retrieved, not only what was shown.
Sources
Where this comes from
Related
Terms that sit next to this one
Prompt injection
Text that tricks an AI model into ignoring its instructions and doing something else.
Indirect prompt injection
Instructions hidden in a web page or file that an AI assistant then obeys.
Tenant isolation
What keeps one customer's data unreachable from another's session.
Broken access control
An application failing to enforce its own rules about who may do what.
AI data leakage
A model or its logs exposing private data that went into prompts or training.
Who can your assistant quote?
We check cross-account access, including whether one signed-in account can pull another's data through a feature, and each finding carries the request and response that proved it. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.