RAG Penetration Testing: How to Test Data Leakage, Poisoning and Tenant Isolation

A practical security-testing guide for RAG pipelines covering authorization, ingestion, indirect prompt injection, vector stores, poisoning, deletion, provenance and cross-tenant retrieval.

Retrieval-augmented generation (RAG) moves enterprise data into the AI request path. That gives users better answers, but it also introduces a security layer that conventional chatbot testing can miss: the system has to decide which documents a caller may retrieve, which sources it should trust and what the model may do with retrieved content.

The security boundary is the retrieval decision

A model should never be responsible for deciding whether a user is entitled to a document. Authorization should be enforced before sensitive content enters model context. If the application retrieves another tenant's record and relies on the prompt to tell the model not to reveal it, the data has already crossed the wrong boundary.

Where a RAG pipeline can fail

Treat ingestion as an input boundary, not a trusted back office process

RAG security starts before the user sends a prompt. Documents may arrive through uploads, shared drives, web crawlers, ticketing systems, email, connectors or automated sync jobs. Each path can introduce attacker-controlled content into a corpus that later influences trusted users.

Test what the ingestion pipeline actually extracts. PDFs can contain hidden or layered text, HTML can carry content that is not visible in the rendered page, and parsers can disagree about what a document contains. Antivirus scanning and file-type validation solve different problems; neither proves that the text placed into model context is safe to treat as instruction.

Tenant isolation: use canary data, not guesswork

Test authorization at every retrieval path

Do not only test the chat interface. Exercise direct search APIs, document-preview endpoints, query parameters, metadata filters, namespaces, collections and any administrative retrieval functions. A strong UI boundary can still sit on top of a vector or search API that accepts caller-controlled tenant identifiers.

Build a small access matrix before testing: role A may read documents 1 and 2 but not 3; role B may read 3 but not 1; support may see metadata but not content. Canary documents make the result objective and help distinguish true cross-tenant retrieval from a model hallucinating plausible text.

Create unique, harmless canary documents for each tenant or role. Then test through every retrieval interface available to the application: normal prompts, search parameters, conversation context, file references and direct APIs. A successful test should show that the canary from tenant A cannot be retrieved by tenant B even when the attacker knows likely document terms or identifiers.

Also test the data layer directly. If the vector database accepts caller-controlled metadata filters, verify that changing tenant IDs, namespaces or collection names does not bypass the application's access-control decision.

Separate retrieval leakage from model hallucination. A suspicious answer is not proof that a restricted document was actually retrieved. Use canary phrases, retrieval traces, source identifiers or controlled metadata to show what entered context. The distinction matters both ways: a model can invent a secret-looking value, and a system can retrieve a forbidden document without quoting it verbatim.

Indirect prompt injection

The attacker may never talk directly to the model. They can place instructions in a document, support ticket, web page or data feed that a trusted user later retrieves. When that content is inserted into context, the model may treat it as an instruction rather than data.

Test whether retrieved instructions can alter tool calls, change destinations, reveal hidden context or suppress safeguards. Defences should combine source trust, content handling, constrained tool permissions and deterministic authorization rather than assuming the model will always recognise malicious instructions.

Poisoning and retrieval manipulation are different problems

Check ranking, query expansion and provenance

A poisoned document does not need to replace the whole knowledge base. It only needs to be retrieved for the right query. Test whether an attacker can manipulate titles, metadata, repeated keywords, embeddings or document structure so that hostile content outranks the legitimate source.

If the system uses query rewriting, reranking or hybrid search, test those stages separately. Record which source documents were retrieved and in what order. Without retrieval telemetry, it is easy to blame the model for a response that was actually caused by search-layer manipulation.

Applications that display source citations should also be tested for provenance confusion: can a response quote one document while presenting a different source, or can an untrusted source be made to look authoritative?

Poisoning changes the corpus or a trusted source. Retrieval manipulation changes which existing content is selected. Test both. For poisoning, check who can contribute, approve, update and delete knowledge. For retrieval manipulation, test ranking behaviour, metadata controls, namespaces and repeated-query strategies that may expose sensitive fragments over time.

For ranking manipulation, use content that is relevant enough to be selected during normal retrieval, not only an obviously malicious payload. The harder case is a document that looks routine to a reviewer but is consistently ranked into context and influences a later answer or tool action.

Data lifecycle: deletion has to reach the index

Test stale embeddings, caches and derived stores

Deleting the original file is only the first step. Content may remain in chunks, embeddings, caches, conversation history, evaluation datasets or secondary search indexes. A deletion test should confirm that the document stops being retrievable through every path the application uses, not merely that it disappears from the source repository.

The same applies to permission changes. If a user loses access to a document in the source system, verify how quickly that change reaches the retrieval layer and whether old conversations or caches preserve access longer than intended.

A document may be removed from its source while cached chunks, embeddings or summaries remain available to the RAG system. Test revocation and deletion end to end. If a user's access is removed, confirm the retrieval layer stops returning the material. If retention rules require deletion, confirm the index and relevant caches follow the same rule.

Do not stop at the answer

Capture retrieval evidence before interpreting the model response

When possible, record the query sent to the retrieval layer, the documents or chunks returned, their tenant or ACL metadata, reranking output and the final context supplied to the model. That trace separates four very different problems: unauthorized retrieval, poisoned retrieval, unsafe prompt interpretation and ordinary model hallucination.

This is particularly important when the visible answer looks safe. A model may refuse to reveal a confidential document even though the application has already fetched it into context. From an authorization perspective, the data boundary has still failed and another model version, tool or output path may expose it later.

Include abuse cases that do not require prompt injection

RAG assessments should also test direct object references on document APIs, weak upload authorization, insecure sharing links, predictable document identifiers, metadata exposure, over-broad service accounts and administrative search features. The retrieval pipeline still sits inside a normal application, and conventional access-control failures can bypass carefully designed prompt controls entirely.

Retrieved content may feed an agent, workflow or API. A malicious document that changes a sentence is one class of issue; a malicious document that causes a system to call an export tool or send data externally is another. Follow the path into tools and backend actions, and verify that authorization is re-checked at the point of action.

Separate a model failure from a retrieval-control failure

Not every incorrect answer is a security vulnerability. A model may invent text that resembles confidential information without ever retrieving the protected source. Conversely, the model may refuse to display a secret even though the application has already pulled that secret into context, which still represents a control failure if the user was not authorized to retrieve it.

Use retrieval logs, canary values and direct API evidence to establish what entered context. That evidence makes RAG findings defensible and keeps hallucination from being confused with data exposure.

A practical RAG penetration-testing workflow

• Map ingestion sources, parsers, vector stores, metadata, ACLs and retrieval APIs.
• Seed canary documents across users, roles and tenants.
• Test document-level and tenant-level authorization before retrieval.
• Test indirect prompt injection through each trusted ingestion source.
• Test corpus poisoning and ranking/retrieval manipulation separately.
• Verify deletion, revocation, cache expiry and re-indexing behaviour.
• Trace retrieved content into tools, agents and downstream renderers.
• Review logs for ingestion, retrieval, authorization failures and tool actions.
• Repeat material tests because retrieval ranking and model output may vary.

What security leaders should ask for

Test the retrieval layer as part of the AI system

RedSecLabs can assess RAG authorization, tenant isolation, poisoning, prompt injection and downstream tool impact as part of an AI/LLM penetration test. Re-test after material changes to data sources, retrieval logic, vector stores, access-control models, agents/tools or model and orchestration components.

AI & LLM Penetration Testing Services  https://www.redseclabs.com/services/pentesting-services/ai-llm-penetration-testing-services