The summary. When a team adds retrieval to an LLM application, the security boundary moves from the prompt to the corpus. The document store, the retriever, and the code that assembles context become part of the trust boundary, and most one-time reviews never test them. There are four surfaces to exercise - corpus poisoning, retrieval authorization, context-to-action, and knowledge extraction - and each needs a specific probe and a specific piece of evidence. This is the testing pattern we run, and the parts an auditor inspects.
Retrieval-augmented generation (RAG) is now the default architecture for enterprise assistants that answer over private content. It is also the part of the stack that a January penetration test tells you almost nothing about in July, because the corpus changes every day and the retrieval code changes with every release. A finding against a static prompt ages slowly. A finding against a living document store ages in a sprint.
The framing that has held up in our testing is the one the current research literature has converged on: secure RAG is the security of the external knowledge-access pipeline. The 2025 OWASP Top 10 for LLM Applications made this explicit by adding LLM08: Vector and Embedding Weaknesses, the first entry dedicated to the retrieval layer. The recent survey work on RAG threats organizes the same pipeline into stages and trust boundaries. We test it as four surfaces.
The security boundary moved to the corpus
A chat-only LLM application has one untrusted input: the user turn. A RAG application has two. The second is every document the retriever can return, and that content reaches the model with the same authority as the system prompt unless the application separates them. Email, ticketing systems, shared drives, internal wikis, and product feedback all feed real corpora. Anyone who can write to one of those sources can write to the model's context.
This is why RAG security is not a subset of prompt-injection testing. Direct prompt injection tests the user channel. RAG testing has to cover the retrieval channel, the access rules on the store, and the path from retrieved text to a downstream action. The four surfaces below are ordered the way an attack moves through the pipeline.
Surface 1 - Corpus poisoning, before retrieval
The first surface is the content that enters the store. Two techniques matter.
The first is planted indirect injection: an instruction hidden in a document that a future query will retrieve. The payload sits in the corpus in advance and executes in another user's context when their query pulls it back. Markup carriers make this cheap - hidden HTML spans, white-on-white text, alt attributes, and metadata fields that the ingester keeps but a human reviewer never sees.
The second is the adversarial passage: content engineered so its embedding ranks highly for a target query without matching it semantically. The attacker does not need to guess wording. They shape the vector so the retriever selects their document, then use that selection to override the correct answer or to smuggle in an instruction.
How to test it. Seed the corpus through the same ingestion path a real contributor would use - the ticket form, the upload endpoint, the connector - not by writing to the database directly. Plant a benign canary instruction inside otherwise ordinary content, including a copy inside a hidden markup carrier. Then run unrelated user queries and check whether the canary is retrieved and whether the model acts on it. The evidence an auditor wants is the ingestion path used, the retrieval rank the planted document reached, and the model output. A finding here is not "the store accepted a document." It is "planted content changed a later answer."
Surface 2 - Retrieval authorization, during retrieval
The second surface is who is allowed to retrieve what. This is the failure mode we find in nearly every deployment we scan, and it is almost never the vector store's fault. The store returns what it is asked for. The defect is in the application code that builds the query and forgets to constrain it by tenant, by role, or by document classification.
The result is cross-tenant retrieval - one customer's query returning another customer's content - or cross-classification retrieval, where an unprivileged user pulls back restricted material because the filter lived in the UI and not in the query. We wrote about the specific mechanism in vector database tenant isolation; the short version is that namespace separation alone does not enforce authorization if the code can be made to query the wrong namespace.
How to test it. Issue retrievals as one principal for content that belongs to another. Vary the axis: tenant against tenant, role against role, classification against classification. Confirm the filter is applied inside the retrieval query and not in a layer the attacker can skip. The evidence is a matched pair - a query that should have returned nothing and the document it actually returned - with the effective identity of the caller recorded. This maps directly to OWASP LLM08 permission bypass.
Surface 3 - Context-to-action, after retrieval
The third surface is what the application does with retrieved text. In a plain question-answering app the blast radius is a wrong answer. In an application that also calls tools or drives an agent, retrieved content becomes the thing that decides which tool runs and with what arguments. That is the path from a poisoned document to a real operation - a ticket that gets closed, a record that gets written, a message that gets sent.
The lethal trifecta applies here in full: private data in the context, untrusted content in the same context, and a way out through a tool. RAG supplies the first two. An agent supplies the third.
How to test it. Combine surface 1 with the tool layer. Plant retrievable content that instructs the model to invoke a tool, then run a query that retrieves it, and observe whether the tool fires. Test the safe operations first - read-only tool calls - before anything with side effects, and never point this class of probe at a production system with live write access. The evidence is the retrieved passage, the tool call it induced, and the identity the tool executed as. This is the join between RAG testing and indirect prompt-injection testing, and it is where the highest-severity findings live.
Surface 4 - Knowledge extraction, out of the store
The fourth surface is data leaving the store through the retrieval interface itself. Two mechanisms are worth a probe. Embedding inversion recovers source text from stored vectors, which matters when the embeddings hold personal or regulated data and the store is reachable by more parties than the source documents were. Membership and extraction probes ask whether an outsider can confirm that a specific record is in the corpus, or reconstruct chunks of it through repeated targeted queries.
How to test it. Where the vector store is directly reachable, test whether its contents can be read or its vectors exported. Where only the retrieval interface is reachable, run extraction queries that try to reassemble a known document from its returned chunks. The evidence is the reachability of the store and a sample of what came back. For regulated corpora this surface is where a retrieval defect becomes a data-protection finding, so redaction of any recovered personal data belongs in the test harness, not after it.
Why a one-time pentest ages badly here
Every surface above depends on state that changes. The corpus grows daily. The retrieval code ships weekly. The tool set an agent can reach expands as the product does. A point-in-time report certifies none of that a month later. The auditor question that follows a RAG pentest is the one it cannot answer: what has entered the corpus since, and has anyone retested retrieval authorization after the last release?
That is the case for testing RAG on a schedule rather than once. The value is not a single higher number. It is the trend, the disagreement rate between independent judges, and a dated record that the four surfaces were exercised after the corpus and the code last changed.
Where this maps in the frameworks
RAG findings do not sit in one control. Corpus poisoning and knowledge extraction map to OWASP LLM08 (Vector and Embedding Weaknesses) and, for planted content, to LLM04 (Data and Model Poisoning). Context-to-action maps to LLM01 (Prompt Injection). Retrieval authorization maps to LLM08 permission bypass and to the access-control expectations in the NIST AI 600-1 profile. We keep the mapping explicit because a regulated customer needs the finding to arrive pre-attached to the control it evidences, not as a loose observation. The measurement model behind this - how each RAG probe becomes an assessment record with a framework reference - is written up in our NIST AI RMF implementation model.
What Penaxtra does
Penaxtra brings continuous security posture management to the retrieval layer. It ships probe families across the OWASP LLM Top 10, including LLM08 and the indirect-injection cases under LLM01, and runs them on a schedule against a customer endpoint rather than once. Retrieval-authorization probes exercise cross-tenant and cross-classification access; context-to-action probes join the retrieval surface to the tool layer with read-only operations by default. Every result is scored by three independent judges plus a meta-judge to keep a single model's blind spot from becoming the verdict, and personal data recovered during a knowledge-extraction probe is redacted before anything is stored. Findings arrive mapped to OWASP, NIST AI 600-1, the EU AI Act, and ISO 42001.
If you run RAG over private content and have an audit ahead, the adversarial scan documentation shows the probe flow, or request an architecture review and we will walk the four surfaces against your pipeline.
Questions we get
Is RAG security testing the same as prompt-injection testing? No. Prompt-injection testing covers the user channel. RAG testing adds the retrieval channel, the access rules on the store, and the path from retrieved text to a downstream action. Indirect injection is the overlap between them, not the whole of either.
What is the most common RAG finding? Retrieval authorization. The store returns what the application asks for, and the application forgets to constrain the query by tenant, role, or classification. It is also the cheapest to fix once found.
Which OWASP entry covers RAG? LLM08, Vector and Embedding Weaknesses, added in the 2025 edition. It covers poisoned embeddings, cross-context leakage, permission bypass, and embedding inversion. Planted-content cases also touch LLM04, and context-to-action cases touch LLM01.
Can you test RAG without touching production data? Yes for three of the four surfaces. Corpus poisoning uses planted canaries through the normal ingestion path, retrieval authorization uses controlled principals, and context-to-action uses read-only tools. Only knowledge extraction needs care around real corpus content, which is why redaction is part of the harness.
The close
RAG did not add a new class of vulnerability so much as move an old one - untrusted input reaching a trusted context - into a place most reviews do not look. Test the corpus, the retriever, the path to a tool, and the way out of the store, on a schedule, with the evidence an auditor can read. That is the whole of it.