TL;DR
RAG security means controlling what a retrieval-augmented generation system can fetch, for whom, and what that fetched text is allowed to do. The retrieval layer is the real security boundary, because it decides which documents reach the model. The five attacks that target it are corpus poisoning, indirect prompt injection, permission leakage, vector store exposure and citation spoofing. Your first and most important control filters by the user’s permissions inside the search call, before any text reaches the model. Scan documents before indexing, lock down the vector database, and build citations from retrieval metadata rather than document text. Then prove it all with a test suite that runs after every connector, index or policy change.
Key Takeaways RAG security covers the retrieval pipeline, meaning who can retrieve which document and whether retrieved text can give the model orders. Permission leakage is the most common enterprise failure, so enforce document permissions at query time, not only at ingest. Filter before retrieval, because redaction after generation comes too late once the model has read the restricted text. Treat every retrieved chunk as untrusted data, and scan documents for hidden instructions before they become searchable. Embeddings can leak the text they came from, so protect the vector store the way you protect the source systems. A RAG security test plan with zero unauthorized retrievals as its release gate turns these controls into evidence. Watch on YouTube
Document Intelligence Explained: OCR vs IDP vs LLMs, RAG, Tools, ROI & Security
Kanerika’s experts walk through how document intelligence and RAG pull enterprise files into AI answers, and where security and access control have to sit.
Could Your Internal Assistant Hand an Engineer the HR Salary Bands?
Ask an internal RAG assistant about promotion criteria, and could it quote the HR salary bands back to you? Unless the pipeline carries document permissions all the way to the search call, yes. The policy file came in from SharePoint with its permissions intact, but the chunking job dropped them.
So an engineer asks a career question, and the assistant answers with the pay band for the next level, citing a file the engineer cannot even open.
Nobody hacked anything. Instead, the retriever simply had read access to everything, and the model trusted whatever it received.
That gap between what a user may open and what the assistant may fetch is where RAG security starts. Closing it before launch is also far cheaper than closing it after a salary figure lands in a chat log.
What Is RAG Security?
RAG security is the set of controls that protect a retrieval-augmented generation system’s documents, embeddings, retrieval permissions, retrieved context and citations. A retrieval-augmented generation app pulls your own content into the model’s prompt at query time. So the question shifts from what the model knows to what the pipeline may fetch, and for whom.
The OWASP RAG Security Cheat Sheet makes the point directly. RAG does not reduce risk, it says, but redistributes it across the data pipeline. That is why securing a RAG pipeline is a different job from building one.
Where the Attack Surface Sits
A RAG pipeline has nine stages, and each one can fail on security. First, connectors pull documents in and a chunker splits them. Then an embedding model turns each chunk into a vector, and the pipeline writes it to a vector database .
At query time, the retriever searches that store and a reranker orders the results. After that, the app assembles a prompt, the model answers and the interface shows citations.
Meanwhile, three trust boundaries cross that path. Source content stays untrusted until something scans it, while the user’s identity has to travel from login all the way to the search call. And the vector store holds a copy of sensitive data in a new format, which needs its own protection.
How RAG Security Differs From General LLM Security
General LLM security asks whether someone can manipulate the model. RAG security, however, asks four narrower questions, and a control that answers one leaves the other three open. For instance, a well-aligned model does nothing about a shared index, while an encrypted vector database does nothing about a poisoned PDF.
Concern Question it answers What does not cover it Source authorization May this user retrieve this document? Model alignment, encryption at rest Content trust Can the model treat retrieved text as instructions? Access control lists, TLS Store protection Who can read, export or change vectors and payloads? Prompt filters, output moderation Output grounding Does each citation point to a real, permitted source? Retrieval accuracy alone
Model-level defenses such as jailbreak resistance sit in the wider LLM security guide . If you need a refresher on the parts themselves, the RAG application overview explains each component.
The 5 RAG Security Attacks at a Glance
Five attacks target the retrieval layer specifically. Because each one enters at a different point in the pipeline, no single control covers all five.
The table maps every attack to its entry in the OWASP Top 10 for LLM Applications 2025 . It also names the first control worth putting in place.
Attack Entry point What the attacker needs Impact OWASP 2025 First control Corpus poisoning Ingestion Write access to any indexed source Wrong or steered answers LLM04 Source admission and provenance checks Indirect prompt injection Retrieved chunk Text the retriever will surface Data exfiltration, hijacked tasks LLM01 Treat chunks as data and mark their origin Permission leakage Retrieval query An ordinary user account Restricted documents in answers LLM02, LLM08 Permission filter inside the search call Embedding and vector store exposure Vector database Network or credential access to the store Source text recovered from vectors or payloads LLM08 Private network, scoped credentials, encryption Citation spoofing Citation rendering Control over a title, URL or metadata field False answers that look sourced LLM09, LLM08 Citations built from retrieval metadata
Unlike the others, permission leakage needs no attacker at all, only a curious employee. That makes it the failure most teams hit first, and the one this guide spends the most time on. For the broader set of generative AI risks beyond retrieval, see the generative AI security overview.
How Each RAG Attack Works
Each attack below gets its mechanism, one concrete example and a sign that your system is exposed. The controls follow in the sections after it.
Corpus Poisoning at Ingest
Corpus poisoning plants documents that the retriever will rank highly for a target question, so the model answers from the attacker’s text. The researchers behind PoisonedRAG (USENIX Security 2025) reported a 90% attack success rate in their tests. To get it, they injected five malicious texts per target question into a knowledge database of millions of texts.
That figure is a lab result under the authors’ setup, not an incident rate, but the defenses they tested did not stop it.
In an enterprise, the real question is who can write to the corpus. After all, wikis, shared drives, ticket systems, CRM notes and scraped web pages are editable by far more people than the assistant’s audience. So if you cannot list every source feeding the index and who can edit it, the corpus is open to poisoning.
Indirect Prompt Injection in Retrieved Chunks
Indirect prompt injection hides instructions inside content the model will read later. In 2023, Greshake et al. showed that attackers could steer LLM-integrated apps by placing prompts in data likely to be retrieved. Their targets included Bing’s GPT-4 powered chat. The attack works because the model has no reliable way to tell a quoted instruction from a real one.
Planted text does not even need to be visible. The AWS Security Blog describes a link hidden as white text on a white background. A reader never sees it, yet the parser indexes it, and the model may return it.
Later, EchoLeak made the risk concrete. Tracked as CVE-2025-32711 with a CVSS score of 9.3, it was a zero-click prompt injection in Microsoft 365 Copilot. According to the EchoLeak case-study paper , one crafted email was enough to trigger remote data exfiltration.
The attack chained bypasses of Microsoft’s injection classifier, link redaction and auto-loaded images.
Permission Leakage at Retrieval
Permission leakage happens when the retriever can see more than the person asking. The OWASP cheat sheet names access control inheritance as the most common compliance failure in enterprise RAG deployments. In plain terms, permissions never travel from documents to their chunks.
It usually comes from one of three shortcuts. The pipeline drops permission metadata during chunking, or it checks permissions at ingest but not at query time. Sometimes every tenant simply shares one index with no filter at all.
Caches also open a second path. If the cache keys an answer only by the question, the next person who asks it gets the first person’s answer, restricted content and all. The clearest sign of exposure, though, is a retriever that runs under a service account with read access to every source.
AI Assessment
Find Where Your AI Systems Are Exposed
Score your organization’s AI maturity across data, governance and security to see which assistants and pipelines need retrieval controls first.
Start Your AI Assessment → Embedding and Vector Store Exposure
Embeddings look like meaningless numbers, but they are not anonymous. Morris et al. recovered 92% of 32-token text inputs exactly from their embeddings, and pulled full names out of a dataset of clinical notes. Those results came from specific models and short inputs, so read them as proof of possibility rather than a forecast for your stack.
Still, the store itself is often the softer target. Qdrant’s security documentation states that self-hosted open source deployments are not secure by default, and that connections stay unencrypted until you turn on TLS. Many stores also keep the raw chunk text as a payload next to each vector, so a stolen snapshot is a stolen document set.
Citation Spoofing and Source Forgery
Citation spoofing makes a bad answer look well sourced. When the app builds citations from document text, an attacker can plant a convincing title, a familiar URL or a fake policy number. The interface then displays it as evidence.
Because users trust a footnote more than a bare claim, the spoof amplifies whatever the poisoned chunk says.
A genuine citation has limits too. It proves traceability, meaning the answer came from that document. However, it does not prove the document is true.
A Worked Example: How a RAG Assistant Leaks an HR Document
Here is the salary-band leak from the opening, traced step by step. It is illustrative rather than a customer incident, though each step matches a failure the OWASP cheat sheet describes. The company runs one internal assistant over a single shared index, and one of its sources is the HR salary-band policy from SharePoint, which only the HR group can open.
The Leak, Step by Step
First, the ingestion job pulls the policy file along with its SharePoint permissions. The chunker splits the file into passages and keeps only text, title and URL, so the HR-only permission never reaches the chunks. An engineer asks the assistant what it takes to reach senior engineer. Similarity search ranks a chunk from the salary-band policy in the top three, because it mentions promotion levels. The model quotes the pay range for the next level and cites a file the engineer cannot open. That last detail is the giveaway, because it shows where the leak happened. Although the citation fails for the user, the answer already contains the restricted text.
The Fix and the Expected Deny
The fix carries group IDs onto every chunk at ingest and filters on them inside the search call. In Azure AI Search, the security trimming pattern indexes a group_ids field with each document and trims results with the search.in function.
# Ingest: every chunk inherits its source document's groups
chunk = {"id": "hr-bands-004", "text": "...", "group_ids": ["hr-team"]}
# Query: groups come from the signed-in user's token, never from the prompt
user_groups = token_claims["groups"] # e.g. ["eng-platform", "all-staff"]
results = search_client.search(
search_text="promotion to senior engineer",
filter="group_ids/any(g: search.in(g, '" + ",".join(user_groups) + "'))",
top=5,
)
# Expected: zero hr-team chunks. If nothing permitted matches,
# the assistant says it found no answer this user may see.Rerun the engineer’s question after the fix, and the HR chunk never enters the candidate set. The same filter then has to cover the reranker input and the cache key, or the leak simply moves one step down the pipeline.
Enforce Document-Level Access Control at Query Time
Document-level access control means the retriever returns only chunks the asking user could open in the source system. The rule that matters most is order. Filter before retrieval, because once a restricted chunk reaches the model, no later step can make it unread.
Pattern How it works Where it fails Use when Pre-filter on chunk permission metadata The search call includes the user’s groups as a filter Stale permission sync, chunks missing metadata Default for any shared index Post-filter after top-k Retrieve top-k, then drop chunks the user cannot see Thin or empty results; restricted text can reach rerankers and logs Only as a second check Index or namespace per tenant Each tenant gets its own partition Does nothing for permissions inside a tenant Strict multi-tenant isolation Delegated user token to the source The retriever queries the source system as the user Latency, source APIs that cannot filter at scale Live systems with complex permissions Redaction after generation Scan the answer and mask sensitive values The model has already read the text Backstop only
In practice, the first and third rows work well together, with the last row kept as a safety net. The models behind those group filters, role-based and attribute-based access, are covered in the data access governance guide.
Carry the User’s Identity End to End
The retriever should run as the user, not as a service account that can read everything. So pass the signed-in user’s token from the app to the search layer, and derive groups from that token alone. OAuth 2.0 Token Exchange (RFC 8693) defines how a service obtains a token that acts for the user, with delegation and impersonation semantics.
Never derive permissions from anything the user types, since a prompt can claim any role. The same principle also applies to agents, as the guide to AI agent authentication explains.
Case Study
43% Faster Document Retrieval for an Investment Bank
Kanerika put role-based access control inside the retrieval layer for an investment bank, reaching 100% role-based compliance at the point of retrieval and 43% faster retrieval.
Read the Case Study → What Each Platform Actually Enforces
Platforms differ in what they enforce for you, so check before you rely on them.
Azure AI Search supports security filters on user or group IDs in any API version. Its built-in identity-based document-level access control , which covers ADLS Gen2 ACLs and Microsoft Purview sensitivity labels, is still in preview, so test it before production. Pinecone recommends one namespace per tenant, and its serverless architecture stores each namespace separately. Metadata filters in a shared namespace suit looser isolation, though $in filters cap at 10,000 values.PostgreSQL row security applies a default-deny policy once enabled, which suits pgvector stores. Superusers and roles with BYPASSRLS skip it, and so do table owners unless you set FORCE ROW LEVEL SECURITY.Amazon Bedrock Knowledge Bases support metadata filters at retrieval. Treat them as a filtering feature, while your application still decides who may see what.Handle Permission Drift and Fail Closed
Permissions also change after indexing. For example, someone leaves a project, a group gets renamed, or a sync job fails overnight.
For that reason, the OWASP cheat sheet asks for checks at retrieval time. It also wants caches scoped by user, tenant and permission level that clear on any permission change.
Design the pipeline to fail closed as well. If the identity lookup or the policy service times out, the assistant should answer with nothing rather than with everything.
Scan and Quarantine Documents Before They Become Retrievable
Ingestion is the cheapest place to stop a poisoned or injected document, because nothing downstream has seen it yet. The checks fall into three groups, and each one leaves evidence you can use later.
Source Admission and Provenance
Admit sources through approved connectors only, and record an owner for each one. Capture the version, a hash and the source permissions at ingest, since the OWASP cheat sheet puts provenance and integrity checks in its implement-immediately tier. So a file with no owner and no permissions should never reach the index.
Content Checks
Hidden text and format tricks, such as white-on-white text, tiny fonts and off-page content. AWS pairs a format breaker with Amazon Textract as filters for this. Instruction-like patterns. Azure AI Content Safety Prompt Shields detect document attacks, meaning hidden instructions planted in documents. Personal data that the pipeline should redact or exclude before embedding, in line with your data privacy rules. Parser anomalies, such as files that extract far more text than they display. Still, these scanners are probabilistic. They lower the risk, but they never remove it, which is why the next two control layers exist.
Quarantine and Rollback
Hold suspicious files outside the index until a person reviews them. Also keep the hash and index version for every chunk. Then, when a bad document slips through, you can find every answer that used it and roll the index back.
Ingestion connectors are only one part of the chain, though. Models, packages and third-party datasets carry their own risks, and the guide to AI supply chain security covers them.
Harden the Vector Database and Embeddings
The vector store holds a second copy of your sensitive content, so it deserves the same protection as the source systems. Treat embeddings as sensitive data too, because the inversion research shows they can give back the text they came from.
Control Why it matters Quick check Private network access An exposed endpoint is the easiest way in Can anyone reach the store from the internet? Separate ingest and query credentials The query path should never write Does the app’s credential have write rights? Read-only, per-collection scopes A leaked credential then exposes one collection, not all Qdrant, for example, offers JWT-based read or read-write access per collection TLS and encryption at rest Self-hosted stores may run unencrypted Is TLS on for every client connection? Locked-down snapshots and exports A backup is a full copy of the corpus Who can export, and does anyone log it? Minimal payloads Raw text next to vectors doubles the exposure Do you store chunk text you never display?
Deletion That Actually Deletes
Deleting a source file does not, by itself, delete its chunks. The OWASP cheat sheet asks for cascading deletion from the source to vectors, caches and derived indexes, plus a deletion log for erasure requests. Also run a scheduled audit for orphaned chunks whose source no longer exists, because nobody can see those documents except the assistant.
Checklist
Generative AI Checklist
A practical checklist for secure generative AI adoption and governance, from data access and vendor review to monitoring in production.
Get the Checklist → Defend the Context Window and the Output
Some injected text will get past ingestion anyway. So the prompt and the answer need their own defenses, and they matter most for assistants that read email, tickets or the open web.
Separate Data From Instructions
Wrap retrieved chunks in clear delimiters, and tell the model they are reference material rather than commands. Microsoft’s spotlighting research went further by transforming retrieved text to signal where it came from. In their experiments with GPT-family models, it cut indirect injection success from over 50% to under 2%, with little effect on task quality.
If the RAG app can call tools, give it the fewest permissions possible. An injected instruction can only use the tools the app already holds.
Bind Citations to Verified Sources
Build every citation from retrieval metadata, never from text inside the document. A sound citation carries the document ID, version, chunk ID and hash, and it points to a source the user may open. Then reject any citation the retriever did not return, and any source the user cannot access.
Filter the Output and Log Every Retrieval
EchoLeak pulled data out through links and images that loaded automatically. So strip or proxy external links and images in answers, and turn off auto-loading wherever you can. Output AI guardrails add a further layer of checks on what leaves the system.
Also log each retrieval with the user identity and chunk permissions, since that log is how you answer an auditor or trace a leak later. Retrieval sometimes grows into agentic RAG , where the model plans and acts. At that point, the runtime controls in the AI agent security tools roundup and the wider agentic AI security practices also apply.
A RAG Security Test Plan You Can Run in CI
Controls only count once a test proves them. A RAG security test plan turns each attack into a repeatable check that runs in CI like any other regression suite. Your threat register then decides which tests come first, and the guide to AI threat modeling shows how to build that register.
Build the Fixtures
Start with a synthetic corpus that spans at least two tenants and several permission groups. Next, create a test identity for each role, including one that has just lost access. Then plant canary documents, each with a unique string, so any leak shows up as an exact match in the output.
The Test Matrix
Test How to run it Pass condition Attack covered Poisoned document Ingest a planted document aimed at one question Quarantined, or never cited Corpus poisoning Injected chunk Index a chunk carrying hidden instructions Model ignores it, with no tool call or link Indirect injection Cross-tenant probe Tenant A asks for Tenant B’s canary Zero canary strings returned Permission leakage Revoked-access probe Remove a user from a group, then query Zero restricted chunks after the sync window Permission leakage Cache replay Two users with different rights ask the same question Second user gets an answer from permitted documents only Permission leakage Unauthenticated store call Query the vector API without credentials Request refused Vector store exposure Forged citation Plant a document with a fake title and URL Citation shows only verified metadata Citation spoofing
Measure With Denominators
Report every metric as a count over a total, such as 0 unauthorized retrievals out of 2,000 probes. Also track the unauthorized retrieval rate, injection success rate, citation validity, false-positive quarantine rate and added latency. The release gate for unauthorized retrievals is zero, since one leaked salary file is one too many.
Answer quality also belongs in the same report. An LLM evaluation framework tells you whether the security filters made answers worse, which is the trade-off product owners will ask about first.
Re-Run on Every Change That Touches Retrieval
Re-run the suite whenever a connector, identity provider, chunking rule, embedding model, index, reranker, policy or cache changes. Those are the moments when permissions silently stop matching. Pair the suite with periodic AI red teaming to catch what a fixed test set misses.
Privacy and Compliance Considerations for RAG
RAG creates new copies of personal data in chunks, embeddings, prompts, logs and traces. Each copy carries the same privacy obligations as the source, so an erasure request has to reach all of them. Logs need special care, because a full prompt log can hold every restricted chunk the system ever retrieved.
Clear ownership stops these controls from falling between teams, so the split below gives each control one owner and one kind of evidence.
Owner Control Evidence to keep Data owner Source permissions and classification Access reviews per source Security Identity propagation and policy Policy configurations, failed-authorization logs Engineering Retrieval enforcement and tests Test results with denominators Platform Ingest scanning, quarantine and deletion Quarantine and deletion logs Risk and compliance Acceptance criteria and exceptions Signed risk acceptances
For a framework map, NIST AI 600-1 , the voluntary Generative AI Profile of the AI RMF, lists information security and information integrity among its risks. That also gives auditors familiar terms for this evidence.
The wider program, including policy and the model inventory, sits under AI governance . Assistants that teams set up without approval never reach that inventory, and the shadow AI detection playbook covers how to find them. An AI security assessment is also a sensible first check of where a deployment stands.
On-Demand Webinar
Data Security Risks in AI: How Microsoft Purview Helps
An on-demand Kanerika webinar on the data security and privacy risks AI introduces, and how Microsoft Purview labels, policies and monitoring keep them in check.
Watch the Webinar → How Kanerika Secures RAG Systems
Kanerika builds retrieval systems with access control inside the retrieval layer from the start. According to its RAG development services page, an engagement begins with a 4 to 6 week advisory phase. That phase produces a production blueprint and an effort estimate.
The work then runs through three phases, named Pilot, Production Build, and Run and Improve.
Security also sits inside those phases. The production build adds sources with permission-aware retrieval, shows citations on every answer and runs evaluation checks on changes. Role-based access controls live in the retrieval layer, and the system logs every retrieval event for audit.
Personal data comes out before ingestion through Susan , Kanerika’s AI agent for PII redaction. Azure deployments run inside the client’s existing Microsoft security perimeter with private endpoints, which closes the exposed-endpoint gap from the vector database section.
An investment bank shows why that ordering matters. Its access controls sat outside the retrieval process, so every new retrieval path reopened a compliance question. Kanerika then deployed KlarityIQ for documents and Karl for databases, with role-based access control applied at the retrieval layer.
The investment bank case study reports 43% faster information retrieval, 100% role-based compliance at the point of retrieval and 35% higher workforce efficiency.
Kanerika also holds ISO 27001, ISO 27701 and SOC 2 Type II certifications and is appraised at CMMI Level 3. Its generative AI services and AI governance services teams work alongside the RAG builds. You can also talk to Kanerika’s experts about an assistant you already run.
Kanerika Service
RAG Development Services
Kanerika builds RAG systems with permission-aware retrieval, citations on every answer and audit logging, from a pilot on one source to production.
Explore RAG Development Retrieval Is the Security Boundary
How do you secure a RAG system? Treat retrieval as the security boundary, learn the five attacks that target it, and filter by the user’s permissions inside the search call. Then scan what you ingest, protect the vector store like source data, and build citations from metadata.
Secure RAG means the retriever returns only what the asking user may see, and retrieved text stays data rather than orders. A test suite then proves both after every change.
Frequently Asked Questions
What is RAG security?
RAG security is the set of controls that protect a retrieval-augmented generation system’s documents, embeddings, retrieval permissions, retrieved context and citations. It decides which documents each user’s questions may pull into the model, whether retrieved text can act as instructions, how the vector store is protected, and whether every citation points to a real, permitted source.
How do I stop a RAG system from leaking restricted documents?
Carry each source document’s permissions onto every chunk at ingest, then filter by the signed-in user’s groups inside the search call, before results reach the model. Apply the same filter to reranker input and cached answers, run the retriever as the user rather than a service account, and fail closed when identity or policy lookups break.
Can retrieved documents carry prompt injection?
Yes. Indirect prompt injection hides instructions inside documents, emails or web pages that the retriever later surfaces, sometimes as invisible white text. The model cannot reliably tell quoted instructions from real ones, so scan documents at ingest, mark retrieved text as data with delimiters or spotlighting, limit tool permissions, and block auto-loaded links and images.
Is the vector database a security risk?
Yes, because it holds a second copy of your sensitive content. One study recovered 92% of 32-token inputs exactly from their embeddings, and many stores keep raw chunk text as payloads. Self-hosted stores may also ship without TLS or authentication, so use private networking, scoped credentials, encryption and controlled snapshots.
Is metadata filtering enough for multi-tenant RAG?
Metadata filtering works when it runs inside the search call on permissions captured at ingest, and when the filter values come from the user’s verified token. For strict tenant isolation, a separate index or namespace per tenant is safer, with metadata filters handling permissions inside each tenant. Test both paths with cross-tenant canary documents.
What happens when a user loses access to an indexed document?
Unless the pipeline checks permissions at query time, the user may still retrieve chunks from that document. Sync permission changes into the index promptly, scope caches by user and permission level, clear cached answers on any permission change, and run a revoked-access test that confirms zero restricted chunks come back after the sync window.
How do you test RAG security?
Build a synthetic multi-tenant corpus with role-based test identities and canary documents carrying unique strings. Then run one test per attack, covering poisoned documents, injected chunks, cross-tenant probes, revoked access, cache replay, unauthenticated vector store calls and forged citations. Report results as counts over totals, with zero unauthorized retrievals as the release gate.
Is RAG more secure than fine-tuning on private data?
RAG can be easier to secure, because documents stay outside the model where you can filter, revoke and delete them per user. Fine-tuned weights cannot forget one document or hide it from one user. That advantage only holds when the retrieval layer actually enforces permissions, so a RAG system without access filters can leak more.
What is citation spoofing in RAG?
Citation spoofing happens when an attacker plants a convincing title, URL or reference number in a document, and the application displays it as a source. The answer then looks well supported even when it is false. Prevent it by building citations from retrieval metadata, such as document ID, version and hash, never from document text.
