RAG Security Assessment: How to Test Retrieval, Indexing and Model Answers

Consider an invented but plausible situation. A law firm rolls out an internal assistant: it answers staff questions from a base of contracts, policies and internal memos, and attaches source links to every answer. The pilot goes smoothly and the lawyers are happy with the accuracy. A month later a junior associate asks how bonuses are calculated at the firm and receives a polite, well-formatted answer quoting a restricted partners' memo on profit distribution.

Nobody hacked anything. Permissions on the folder containing the memo were checked once, when the document was loaded into the index. Later the associate was moved to a different group, the source permissions changed, and the retriever never re-checked permissions at query time. The assistant simply found the most relevant fragment and honestly cited it.

This is an illustration, not a description of a real incident, but the mechanism is entirely realistic for any retrieval-augmented generation (RAG) system. Products like this are often tested as a "chat with a model": run a set of dangerous prompts, look at the refusals and call it done. Yet a large share of the risk lives in the data flow around the model: who can write to indexed sources, how results are filtered, where answers end up and what happens to deleted documents. Below we cover how a RAG security assessment works, which trust boundaries it tests, how to collect evidence and how to choose the depth of the engagement.

What a RAG security assessment covers

A RAG security assessment is an authorized, structured test of the entire pipeline, not just the chat interface. The system ingests documents and builds searchable representations: vector-based designs use embeddings, while lexical and hybrid systems may also use other indexes. For each question, it retrieves relevant fragments, assembles them into a prompt and returns the model's answer. The goal is the usual one: find weaknesses, confirm that protections work as intended and deliver findings that can be fixed. What differs is the attack surface: untrusted content reaches the model's instructions, and the model's answer flows on to web pages, APIs and sometimes tools.

Scope follows the actual architecture. It can include ingestion connectors and file parsers; lexical indexing and, where used, embedding generation and a vector store; the retriever and permission filtering; prompt assembly, system instructions and context templates; the model gateway or API with authentication and rate limits; rendering of answers in web, chat and mobile clients; tools the model can invoke; and logging, caching and monitoring.

Components can be excluded from scope, but that must be a deliberate, documented decision. If a hosted search or vector store is run by an external provider and is out of scope, the report should say plainly that data isolation inside it was not tested.

It helps to treat a RAG assessment as an extension of familiar application security testing. The lifecycle and web-layer guides chosen here do not define test cases for retrieval and prompt assembly: the tester designs that part from the architecture of the specific system.

Method: lifecycle, web layer and verifiable requirements

The planning frame comes from NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, published in September 2008 as the replacement for SP 800-42. It helps organizations plan and conduct technical tests, analyze findings and develop mitigation strategies; it walks through techniques with their advantages and limitations and states explicitly that it is not a comprehensive testing program. Formally, an assessment under this guide runs through planning, execution and post-execution phases, the last covering analysis and recommendations. The practical "find, fix, retest" cycle is the working logic of a project, not wording from the standard. The document's age is no obstacle: the discipline of planning and agreeing rules of engagement applies to architectures that did not exist in 2008.

For the web and API layer of a RAG product it makes sense to fix a methodological baseline, for example the OWASP Web Security Testing Guide version 4.2, and OWASP ASVS 5.0.0 as the set of verifiable requirements. The key is to "choose and pin": editions change, and the report should state which one the test followed.

On top of that baseline the tester defines RAG-specific objectives: retrieval authorization, containment of retrieved text, output handling and index freshness. For conversations with leadership, results are conveniently translated into the language of NIST CSF 2.0 so that RAG risks can be compared with the rest of the organization's risks.

Another useful vocabulary is the 2026 edition of the OWASP Top 10 for LLM Applications, released in August 2026. For RAG the closest entries are vector and embedding weaknesses, hidden context exposure, prompt injection and improper output handling. It is a list of risks for scoping discussions, not a certification scheme. We covered how to build a test around it in our article on OWASP LLM Top 10 assessment.

Threat model: who actually writes into the model's context

The defining feature of RAG is that a single model context mixes the developer's trusted instructions with retrieved content of varying trustworthiness. The model can mistake retrieved content for instructions and should not be treated as an authorization boundary. So anyone who can influence indexed documents can potentially influence what it reads: the author of an external web page, the sender of an email, an employee with edit rights on a shared drive, a customer who opened a support ticket.

The first practical task is therefore a map of sources: who can write to them, how quickly changes reach the index and whether the original permissions are preserved. This is exactly where you may discover that the "internal knowledge base" is half made up of exported tickets whose text is written by external users.

For scoping it is convenient to think in several threat categories; this is an analytical model, not a prevalence ranking. Indirect prompt injection: instructions in retrieved documents try to override the system's behavior. Retrieval authorization bypass: fragments reach users without rights to the source. Corpus poisoning: planted content wins retrieval. Sensitive data leakage: secrets and personal data end up in answers, citations, logs or caches. Insecure output handling: the answer is rendered as HTML or passed into commands without encoding. Excessive agency: tools are triggered by model output without permission checks.

Many of these threats are old vulnerabilities in a new form: insecure output handling turns out to be cross-site scripting or injection, and retrieval authorization bypass is an access control problem. The table below shows where the main boundaries lie.

Retrieval authorization and tenant isolation

For systems where documents are permission-scoped, this is usually the central test: are permissions enforced at query time, not only at ingestion? The answer is not obvious even to the team itself, because permissions pass through several layers: the source, the connector, index metadata and the retriever filter.

The method relies on several authorized accounts with different rights and clearly labeled canary documents in a test tenant. A canary contains a unique string that cannot be obtained from anywhere except that document. Acting as each role, the tester asks questions for which the canary would be the perfect answer and looks not only at the text but also at citations, snippets, titles, file paths, author names and the number of results. Leakage through metadata can be as consequential as text leakage. Repeat the query under recorded conditions: one confirmed disclosure proves the path is possible, not how often it occurs, while one clean run does not prove the control effective.

Where the filter sits and why it matters

The permission filter can be applied before retrieval, restricting the search to accessible documents, or after it, discarding what should not be shown from the results. Retrieving a broad candidate set and then fully filtering it before prompt assembly and before any user-visible metadata is produced is not inherently an authorization flaw. The flaw appears when filtering is absent or too late: restricted documents may then leak through titles or counts, enter the prompt, or be returned to the user. Even a correctly placed post-retrieval filter can let inaccessible candidates crowd out accessible ones, so relevance and denial-of-service effects still need testing. A separate problem is the permission snapshot taken at indexing time: permissions in the source change while the index keeps living by outdated rules. That is exactly what the scenario at the start of this article shows.

1. Document restricted at sourceA partner restricts access to the memo, but the permission snapshot in index metadata stays unchanged
2. Query from another roleAn employee asks a question for which the restricted fragment is the most relevant answer
3. Retrieval without permission checkThe retriever relies on stale metadata and returns the fragment among the top results
4. Prompt assembly and answerThe fragment enters the context; the model paraphrases it and attaches a source link
5. Cache locks in the leakThe answer is cached by question text and served to subsequent users

Multi-tenancy

In customer-facing SaaS products the same question arises at the tenant level: a separate namespace per customer, or a shared index filtered by tenant identifier. The second option demands particular care: the tester substitutes the identifier in API parameters, looks for requests that carry no filter and checks shared components such as the semantic cache, embedding cache and indexing queues. We discussed customer isolation principles in our piece on penetration testing for SaaS companies, and they apply fully to RAG.

If your system already has permission scoping or several customers in one index, you can discuss with Pentest.red in advance the set of test roles, the test tenant, the canary documents and the evidence your team will need to fix issues. A convenient starting point is the pentest scope description.

Indirect injection and corpus poisoning

The second big area is containing the influence of retrieved text. Benign, clearly labeled test documents with noticeable instructions are placed into a non-production index: add a code word, cite a non-existent source, list neighboring fragments of the context or call an available tool. The goal is to measure whether the architecture contains the influence of retrieved text, not to create malicious content.

The result of such tests is rarely binary: the model may ignore one phrasing and follow another. One confirmed bypass proves that the observed outcome is possible under the recorded conditions, but not its frequency. Its consequence still determines priority. Distorting the wording of an answer is one degree of risk; calling a tool on the user's behalf or leaking data from a neighboring fragment is quite another.

Corpus poisoning is tested from a different angle: can an author with write access to a source make their document win retrieval for important queries? A hypothetical example: a document stuffed with the words "supplier payment details" appears on a shared drive, and the assistant answers from it instead of the official procedure. Testers check write rights, visibility of fragment provenance and whether the system distinguishes sources of different trust levels.

Protection here is built through architecture, not a single filter: retrieved text is treated as data, sources of different trust are separated and labeled, and the provenance of a fragment is visible to the user. Changing the system prompt lowers the success of known phrasings but does not eliminate the risk class.

Model output, caching and transport

Output handling

The model's answer is untrusted data for every component that receives it. Rendered as active HTML without context-appropriate handling, it can yield cross-site scripting. Passed to SQL, a shell or an API, it becomes dangerous when the receiver interprets it as syntax or trusts model-chosen operations without server-side validation and authorization; an API call is not automatically an injection. ASVS 5.0.0, for example, has a requirement in its injection prevention section: protection against OS command injection through parameterized calls or contextual command-line output encoding. For RAG it is relevant wherever an answer or fragment can reach an interpreter. Prefer a dedicated safe API and avoid a shell; if process launch is unavoidable, fix the executable and options and allowlist each argument, because placing a value in a separate argv element does not by itself prevent argument injection.

Markdown rendering deserves a separate check: if the client automatically loads images from links in the answer, the image URL can carry fragments of the context away. Content Security Policy helps — as MDN describes it, a response header that lets administrators control which resources the client may load and that helps detect and mitigate attacks including cross-site scripting and data injection. When the model also acts, tool permissions become a topic of their own — see our article on excessive agency security testing.

Sessions, CORS and caching

At the protocol level HTTP does not keep state between requests, but cookies and server-side sessions are an ordinary and correct way to add it. When answers contain user-specific data, cache keys and response headers must prevent cross-user disclosure; shared caching can still be appropriate for identical public data returned under the same authorization conditions. CORS controls whether a browser script from another origin can read a response, but it is not API authentication or authorization. Protect session tokens and enforce server-side access checks for every endpoint. For SSE, test those checks together with CORS. WebSocket does not use CORS as its access mechanism, so validate authentication and authorization during and after the upgrade and assess the Origin header separately.

The application-level answer cache deserves special attention: if the key is only the question text and the answer depends on user or tenant permissions, the cache can hand an authorized answer to an unauthorized requester. A shared result is acceptable only when the underlying data is intentionally public or identically authorized and the cache key captures every relevant security condition. These checks follow WSTG, and techniques for testing the API itself are described in our piece on REST API security assessment.

Ingestion, deletion and index freshness

The ingestion pipeline is a full part of the attack surface. Parsers for PDF, office formats, HTML and archives process untrusted files: testers check handling of malformed files, directory traversal during archive extraction and extraction of hidden text that the user does not see but the index does. Connector credentials are service credentials, and the question for them is not MFA but scope, storage, rotation and excess privilege. Separately, testers establish who can write to the index bypassing the sources.

A check that is easy to overlook — deletion propagation — deserves to be singled out. A document deleted or restricted at the source must disappear from answers within a period the team has defined and written down. The test: revoke access to a canary, wait the agreed time and repeat queries from different roles, also checking answer and embedding caches, derived summaries and index copies. Without a defined period the check loses its meaning: "it will be deleted eventually" can be neither accepted nor refuted.

Why the classic application layer cannot be skipped

The components around the model are ordinary software: web interfaces, APIs, connectors, parsers, admin consoles. MITRE characterizes the weaknesses in its 2025 CWE Top 25 list as often easy to find and exploit and capable of leading to system takeover, data theft or disruption, and singles out command injection as particularly attractive to adversaries. Note, however, that a CWE identifies a weakness class, not the probability that a specific vulnerability will be exploited.

CISA alerts under the Secure by Design initiative on eliminating cross-site scripting, OS command injection and directory traversal show that the same weakness classes come up again and again. If an assessment looks only at model behavior, they stay untested — and the model's answers and retrieved content open precisely new paths to old interpreters.

There is also a gap in the source pack reviewed for this article: it contains no reliable measurement of how often RAG systems are compromised or which RAG-specific attack occurs most often. This is a limit of the reviewed material, not an exhaustive claim about all publications. Vendor statistics on the "prevalence of RAG attacks" should therefore be treated with caution, and buyers should ask for the underlying data and method.

Trade-offs: access, non-determinism and environment

Testing only through the chat interface reproduces an external user's view, but then it is hard to tell where an authorization failure occurred: in the index, the permission filter or prompt assembly. Access to architecture and index schemas and to the permission-mapping logic shortens the work and increases confidence in the conclusions, which echoes NIST SP 800-115's emphasis on the limitations of each technique. The price is more preparation on the client's side.

Model answers vary from run to run, so a single successful or failed test may not generalize. Key tests should be repeated while recording the model version, generation parameters, retriever configuration and retrieved fragments. The result is described as behavior observed under stated conditions, not as a guarantee.

Testing in production offers realism but risks polluting the live index or exposing real data. A staging environment with synthetic or approved data is safer, but its results cannot be carried over to production without caveats: permission synchronization, sources and caches may differ there. A reasonable compromise is to do the main work in staging and confirm key findings in production to a limited extent under agreed rules. Any test that writes to the index requires documented permission from every party empowered to authorize work on the affected assets and environments, plus a cleanup plan.

Finally, indexed content can change daily, so a clean result today says nothing about tomorrow's documents. Periodic assessments are best complemented by automated regression tests for retrieval authorization and output encoding.

Evidence, retesting and operations

Findings should be tied to stable, version-qualified requirement identifiers. ASVS recommends the format v{version}-{chapter}.{section}.{requirement}, for example v5.0.0-1.2.5, because numbering changes between versions. Mapping to ASVS or CWE makes sense only where a requirement actually describes the issue found; the mapping itself does not prove conformity with the standard. RAG-specific findings with no matching ASVS requirement can be kept in an internal catalog under the same versioning rule.

Logging should make it possible to reconstruct which documents were retrieved for which user and which tools were called, without becoming a second copy of the sensitive corpus: secrets are redacted, fragment content is minimized, access to logs is restricted and retention periods are set deliberately. CISA's Secure by Design guidance says products should be secure by default and that features such as multi-factor authentication, logging and single sign-on should be provided at no extra charge. MFA, however, applies to people; connections between pipeline services need service identities, short-lived tokens and narrow access scopes.

Typical remediation measures we recommend considering: authorization inside the retriever, retrieved text treated as data, output encoding for the rendering context, least privilege for tools and human confirmation for high-impact actions. Retest conclusions apply only to the scenarios and conditions examined; how to make a retest provable is covered in our article on penetration test remediation validation.

Assessment depth: from pilot to agent

The depth of an assessment should match exposure and potential impact. The tiers below are our practical model, not a scheme from a standard; they rest on four questions: what data is indexed, who sends queries, who creates indexed content and what the model can do beyond answering.

Internal pilot

Public or low-sensitivity documents, internal users, no tools. Start with architecture review, targeted web/API testing and output handling. Add indirect-prompt-injection checks whenever untrusted authors can influence the corpus or an answer can materially affect a decision; the labels "internal" and "no tools" do not make that path low risk by themselves.

Internal production with permission scoping

Documents with different access levels change the picture. Add full retrieval authorization testing with several roles and canaries, an ingestion pipeline review, and checks of deletion propagation and logging.

Customer-facing and multi-tenant systems

If customers use the assistant, the index holds data from different organizations or the system indexes external content, a full assessment is needed: resilience to indirect injection, tenant isolation and caching, browser cross-origin behavior tested separately from server-side API authorization, plus automated regression tests.

Systems that act through tools

When the model can call APIs, change records or send messages, add a least-privilege review of each tool, confirmation of high-impact actions and retesting after capability changes. Prefer dedicated safe APIs; avoid shell execution, or fix the executable and options and allowlist every argument when a process must be launched.

Repeat the assessment when a new source is connected, a tool is added, the model or embedding provider changes, the permission model changes or the interface gets a major update. Between assessments, regression tests keep working.

How to choose a provider for RAG testing

CISA's Secure by Demand guide is aimed at software customers and designed for procurement negotiations with suppliers. Its questions are useful to put to RAG product vendors, but that conversation does not replace an independent assessment of your integration.

When comparing offers for a RAG security assessment or an LLM application audit, find out: whether the work covers ingestion, the index, the retriever, prompt assembly, the model gateway, output rendering, tools and the web and API layer; which methodologies the provider references and how it ties findings to versioned requirements; how many roles and canaries the authorization tests use and whether tenant isolation is tested; how non-determinism is handled; what the rules of engagement, test-data handling and index cleanup commitments are; and whether a retest is included and what evidence accompanies each finding. If tests touch third-party services, such as a cloud model API, check their terms of use: obtain documented approval from every party empowered to authorize work on the affected assets and environments, and check the provider's applicable terms before sending test traffic to its endpoints.

Be wary of claims that cannot be verified: proprietary risk scores without a published method, promises of being "unhackable", prevalence statistics without data. The standards we reviewed do not describe a certification specifically for RAG testing, so ask what a claimed qualification actually covers. A pentest is a snapshot at the time of testing, not a certification or conformity opinion. Its report can inform a broader conformity evaluation, whose scope and qualified decision-maker are separate.

If you are preparing such a procurement, you can discuss with the Pentest.red team the architecture of your RAG system, the components in scope, staging requirements and the form of evidence in the report. The general engagement process is described on the penetration testing services page, and the input for that discussion is easy to gather through the scope description form.

Conclusion

A RAG security assessment should be scoped as an application test, with architecture-driven depth where untrusted content meets the model's instructions: NIST SP 800-115 provides the lifecycle, WSTG the web-layer methodology, ASVS in a pinned version the requirements, CWE classes the prioritization of application weaknesses, and NIST CSF 2.0 the language for leadership.

For RAG, this article's practical priorities are: retrieval authorization together with index freshness, containment of instructions in retrieved content, and safe handling of model output. Any result is a snapshot at the time of testing and should be backed by regression tests. Choose providers with a transparent methodology, permission discipline and versioned reporting, and test only with documented authorization from every party empowered for the affected assets and environments.