RAG pipeline security testing

Why RAG pipeline security testing matters before launch

A retrieval-augmented generation (RAG) test checks whether the retrieval layer of an AI application keeps content away from people who should not see it. In scope are document ingestion, indirect prompt injection through retrieved content, access control on the vector store, tenant isolation between customers or business units, and weaknesses in embeddings that allow retrieved content to leak. Buyers usually commission this work because a launch date is approaching, a customer security questionnaire asks whether the retrieval layer has been tested, an insurer wants evidence of testing, or a compliance program requires it. The test is measured against the OWASP Top 10 for LLM Applications 2026 and MITRE ATLAS, so the findings can be traced to recognized risk categories and techniques.

Retrieval is a distinct attack surface because the model answers from whatever the pipeline hands it, and that content is often broader than what the user is allowed to see. Hidden Context Exposure (LLM08) covers cases where context the application injects into prompts, such as system instructions, metadata or chunks from restricted sources, reaches users through answers. Vector and Embedding Weaknesses (LLM09) covers the vector store, its index partitioning and the embeddings themselves, where a missing filter on a tenant identifier or a shared namespace can expose documents across customers. Prompt Injection (LLM01) matters here because a document or web page loaded into the index can carry instructions that the model follows once it is retrieved. Each of these is tested separately, since a clean result for one does not show the others are safe.

What can be in scope for a RAG pipeline test

A RAG pipeline is a chain of components, and a test is only as useful as the boundary drawn around it. The cards below cover what can be tested, the scoping decisions that shape the test, and the rules that should be written down before any document is uploaded or any query is sent. All scope is agreed in writing before work starts.

Document sources and ingestion connectors

Connectors pull content from file shares, wikis, ticketing systems, mailboxes and web sources, often with service accounts that hold broad read rights. Testing checks which sources are allowed, how credentials are stored and rotated, whether permissions from the source system are carried into the index, and how a poisoned or hostile document entering through a connector is handled. Confirm which connectors are live and who owns each one.

Parsers and chunking logic

Parsers convert PDFs, office files, HTML and images into text, and chunking decides what passes into retrieval. Testing examines how malformed files, embedded objects, hidden text and metadata are handled, and whether content that a reviewer would never see still reaches the model. Ask for the list of file types accepted and whether parsing runs in an isolated process.

Embedding model and service

The embedding model turns documents and queries into vectors and may be hosted by a third party or run inside your environment. Testing covers where content is sent, how the service authenticates, whether logs retain inputs, and whether vectors can be inverted to recover source text. Confirm the provider's data handling terms and whether the model is pinned to a version you have reviewed.

Vector store and access control

The vector store is where tenant isolation most often fails. Testing checks whether queries are filtered by tenant, role and classification at retrieval time rather than only in the user interface, whether namespaces or collections are separated, and whether administrative interfaces and backups are exposed. Vendor-specific configuration keys should be confirmed against the product documentation for the version in use.

Retrieval, reranking and orchestration

Retrieval and reranking decide which chunks reach the model, and orchestration decides which tools and prompts surround them. Testing checks that permission filters are applied before ranking, that retrieved content cannot override system instructions, and that the orchestration layer does not pass hidden context or credentials to the model. Include any agent tools the pipeline can call, since those expand the impact of a retrieval flaw.

Scoping decisions and rules of engagement

Agree which tenants, user roles and data classifications are in scope, and whether testing runs against production or a staging copy with representative but non-sensitive data. Set rules for document uploads, including who may upload test files, which sources may be contacted and how hostile content is labeled and removed afterward. Written rules protect both the client and the tester, and they should name an escalation contact.

How a RAG pipeline engagement runs, phase by phase

The sequence moves from agreed scope and architecture to threat modelling, controlled testing of each retrieval path, evidence-backed reporting and a retest, so that the client ends with verified results rather than a list of suspicions.

Agree scope and review the architecture
The testers map the RAG pipeline end to end: document sources, ingestion jobs, parsers, embedding model, vector store, retrieval logic, the prompt assembly step, the LLM and the user-facing application. They agree in writing which tenants, data classes, user roles and environments are in scope, and which test data may be used. The step closes with a data flow diagram and a scope document that the client has approved, so that every later test traces back to an agreed boundary.
Threat model against OWASP and MITRE ATLAS
Working from the architecture, the team maps likely threats to the OWASP Top 10 for LLM Applications 2026, focusing on LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM08 Hidden Context Exposure and LLM09 Vector and Embedding Weaknesses, and to the relevant MITRE ATLAS tactics and techniques, including indirect prompt injection (AML.T0051.001). They use the NIST AI 100-2 E2025 taxonomy to classify attacks by goal and capability. The output is a ranked test plan that names the trust boundaries to cross and the controls expected to hold.
Test ingestion and indirect injection paths
Testers examine how documents enter the corpus: upload endpoints, connectors to file shares or wikis, parsers, and metadata handling. Using controlled, clearly labelled test documents, they check whether instructions embedded in content can alter retrieval or model behavior, and whether ingestion accepts content from untrusted sources without review. The step closes with a record of which ingestion sources were tested, what each test document contained, and whether the pipeline isolated retrieved text from instructions.
Test retrieval authorization and tenant isolation
This is the core access control test. Testers use accounts with different roles and tenants to check whether a query can return chunks the requesting user is not entitled to see, whether filters are enforced in the vector store query or only in the application layer, and whether cached embeddings, namespaces or collections keep tenants separate. They also check administrative and bulk export paths. The step closes with a matrix of identity, query and returned content, showing each authorization decision that held or failed.
Test leakage paths in outputs and logs
Testers look for routes by which retrieved content reaches people who should not see it: model responses that quote restricted passages, system prompts or hidden context exposed to users, conversation histories shared across sessions, and logs, traces or analytics that store full chunks. They also assess whether the embedding service and vector store are exposed beyond their intended network. Each confirmed leak is recorded with the request, the retrieved source identifier and the affected data class, so the client can reproduce the check in its own environment.
Report findings with severity and evidence
Each finding is written with a description, the affected component, the OWASP or ATLAS reference, a severity rating that the client can calibrate against its own risk model, reproduction steps at a defensive level of detail, evidence such as redacted request and response records, and specific remediation guidance. The report separates confirmed issues from observations and lists tests that found no weakness. The client receives a debrief so engineering teams can act on it. The step closes when the client accepts the report as the baseline for remediation.
Retest fixed findings and confirm closure
After the client has remediated findings, testers repeat the original tests against the changed system to confirm that each fix holds and does not open a new path. Findings that are accepted as risk stay open with a documented owner and rationale. The output is a retest report that lists each original finding with its status. Retesting is usually agreed as part of the original scope, and the client should confirm its terms in the written proposal.

How indirect prompt injection enters through retrieved documents

Indirect prompt injection enters a RAG system as ordinary content. An attacker does not need access to the chat interface. They need a way to place text into something the pipeline ingests: an uploaded file, a wiki page, a support ticket, a web page the crawler fetches or an email attachment. When a user later asks a question that retrieves that content, the model receives the attacker's text inside the same context window as the system prompt and the user's request. The MITRE ATLAS technique AML.T0051.001 (LLM Prompt Injection: Indirect), updated in the v2026.09 data release, describes this pattern. The retrieval layer is what turns a stored document into a live instruction source, which makes it a trust-boundary problem rather than a model quirk.

The trust boundary sits between the document store and the prompt assembly step. Testers start by mapping every source that feeds the index and asking who can write to each one, whether that writer is an employee, a customer, a partner or an anonymous visitor. They then check how retrieved chunks are labeled and delimited before they reach the model, whether the application tells the model that retrieved text is data, and whether any tool the model can call acts on instructions found in that text. Confirm with your platform team which connectors run unattended, because scheduled crawls and sync jobs widen the set of writers without anyone reviewing new content.

A useful test records which guardrails held and which did not, not only whether the model was fooled once. Ask the provider to show the ingestion-time controls (content filtering, source allowlists, provenance metadata), the prompt-assembly controls (delimiters, role separation, retrieval instructions) and the output and action controls that limit what a poisoned answer can cause. Treat any result that depends on the model politely refusing as a weak control. Ask for a written list of trusted and untrusted sources as part of the scope, because the test cannot judge trust until the client has decided it.

Weakness categories tested in RAG pipelines

This table maps each weakness category in a retrieval-augmented generation pipeline to what it looks like in the target and why it matters to the buyer. Read each row as a question the test must answer, with the buyer's exposure stated in the final column. The main takeaway is that most RAG failures are authorization failures at retrieval time, not model failures, so the test must follow data from source to answer.

Weakness category	What it looks like in a RAG pipeline	Why it matters to the buyer
Ingestion trust and source validation	Documents enter the index from shared drives, wikis, ticket systems or web crawls without checks on who authored or changed them	Anyone who can edit a source document can influence what the model later retrieves and repeats, so the buyer needs to know which sources are trusted
Indirect prompt injection via documents	Instructions hidden in retrieved text, such as an uploaded file or web page, are treated by the model as commands to follow	Maps to LLM01 Prompt Injection and the indirect variant ATLAS technique AML.T0051.001, and can cause actions or disclosures the user never requested
Missing or late authorization at retrieval time	Access checks run after chunks are retrieved and ranked, or are skipped for some query paths such as summaries or follow-up questions	Users may receive content they could never open directly, which is a common finding in internal assistant reviews
Cross-tenant leakage through shared indexes or metadata filters	One vector index serves several customers or business units, and filters on tenant or department fields can be bypassed, omitted or misapplied	A single filter defect can expose one client's documents to another, with consequences under contractual and data protection obligations
Embedding and vector store exposure	The vector database, its admin API or its embedding service is reachable from untrusted networks or runs with default credentials, as covered by ATLAS technique AML.T0132 Misconfigured or Publicly Exposed AI Services	Whoever reaches the store can read, copy or alter the entire corpus, and embeddings can still reveal content, so the store needs the same controls as a database
Hidden context and system prompt exposure	Retrieval adds hidden instructions, internal metadata or system prompt text that the model can be induced to reveal, matching LLM08 Hidden Context Exposure	Reveals internal logic, document paths or security rules that help an attacker plan further attacks
Over-broad retrieval returning sensitive chunks	Top-k settings or chunking pull in neighboring passages containing personal data, credentials or restricted material that the question did not need	Sensitive data reaches the model and the answer even when each source is permitted, so the buyer should confirm minimization rules and logging of retrieved chunks

How tenant isolation changes the test by architecture

A single vector index holds embeddings for all tenants, and each chunk carries metadata such as a tenant or access-group identifier. The application adds a filter to every similarity query, so isolation depends on that filter being present, correctly scoped and impossible to remove from the request path. The tester's first question is where the filter is applied: in the application, in a retrieval service, or in the vector store itself. Filters applied only in application code are the most common point of failure, because one unfiltered code path, a debugging endpoint, or a background re-indexing job can return chunks from every tenant.

Filter placement: Confirm whether the tenant constraint is enforced server-side from the authenticated identity, never from a client-supplied parameter.
Unfiltered paths: Enumerate every route that calls the index, including admin, export, summarization and re-ranking steps.
Metadata integrity: Test how chunks get their tenant tags during ingestion, and whether a malformed or mislabeled document can carry another tenant's tag.
Cross-tenant ranking: Check whether similarity scores, counts or cache keys reveal the existence of another tenant's content.
Deletion and re-indexing: Verify that removed or reassigned documents disappear from retrieval results and caches.

Check that the test covers every retrieval path, not only the main chat interface, and that the evidence names each path it exercised.

What drives the cost and duration of a RAG pipeline test

This table compares the components of a RAG pipeline test that move the quote and schedule, who is paid for each one, and whether it is a one-time or recurring cost. Read it as a checklist for the written scope: the more sources, roles, tenants and connected agent tools in play, the more testing time the scope will need. No prices or durations are given because they follow from the agreed scope, not from a published rate.

Cost component	Who is paid for it	What drives it up or down
Document sources and ingestion paths	Tester time to map each source (file shares, wikis, ticketing, web crawlers, uploads) and trace how content reaches the index	More source types and ingestion routes mean more indirect prompt injection scenarios to build. Fewer, well-documented pipelines keep this down
User roles and tenants	Tester time to create accounts per role and tenant and compare what each one retrieves	Each additional role or tenant adds a comparison matrix. Agreeing a short list of representative roles in the scope keeps this bounded
Depth of retrieval authorization testing	Tester time to check whether access controls are enforced at query time, at index level, and in metadata filters	Testing only the chat interface is cheaper than testing the retrieval API directly and the filter logic behind it. Ask which layers are in scope
Agentic tool access behind the RAG layer	Tester time to assess what actions retrieved content can trigger through tools, and to run those tests in a controlled environment	Read-only retrieval is the lighter case. Write actions, email, ticketing or code execution add scenarios and sometimes a separate agent test
Environment access (staging versus production)	Tester time for environment setup, plus the client's time for providing accounts, sample data and change windows	Testing in a production-like staging environment with representative data is usually simpler to schedule. Production testing needs extra coordination and safeguards
Test data and corpus preparation	Client time to supply or approve synthetic documents, and tester time to seed canary content for leakage checks	Existing test corpora and clear labeling of sensitive documents reduce effort. Real customer records in the corpus add handling constraints
Initial test and reporting	Tester time for execution, evidence capture and a report mapped to the agreed framework references	Mapping findings to a specific framework or customer questionnaire adds reporting work. Ask for the report structure in the quote
Retest scope (one-time or retainer)	Tester time to verify fixes against the original findings, typically as a separate, defined item	Retests of a few findings cost less than full re-execution. Retainers suit teams that change the pipeline often and want continuous checks

Frameworks and customer reviews that expect this testing

Customers, regulators and certification programs now ask for evidence that a RAG pipeline resists poisoned documents, cross-tenant leakage and unauthorized disclosure. The cards below map the frameworks most often cited in these reviews to the test evidence each one tends to expect. Confirm the exact requirements with your auditor, regulator or customer before scoping.

EU AI Act Article 15(5) resilience

Article 15(5) asks providers of high-risk AI systems to build in resilience against attempts to exploit vulnerabilities, including data poisoning and confidentiality attacks. For a RAG system, that points toward testing whether poisoned or malicious documents in the corpus can alter answers, and whether retrieval can be steered to expose data the system should protect. Confirm with counsel whether your use case is high-risk under the Act and what evidence your provider expects.

EU AI Act Article 55(1) scope

Article 55(1) requires providers of general-purpose AI models with systemic risk to perform documented adversarial testing. Most RAG deployers are not that provider. They build on a model someone else trained, so this duty usually falls on the model vendor, not on the team running the pipeline. Ask your model provider for their adversarial testing documentation, and scope your own test to the retrieval layer, ingestion path and access controls you control.

NIST AI 600-1 as a voluntary profile

NIST AI 600-1 is the Generative AI Profile of the AI Risk Management Framework, published for voluntary use. It gives a shared vocabulary for trustworthiness risks in generative systems, including information security and data privacy concerns that apply to retrieval. Many procurement teams reference it without requiring certification against it. Use it to structure the risk register for your RAG pipeline, then ask testers to map each finding to the profile's risk areas in the report.

OWASP LLM Top 10 2026 checklist

The OWASP Top 10 for LLM Applications 2026 is the checklist most customer security questionnaires now borrow from. For RAG, the relevant entries include LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM08 Hidden Context Exposure and LLM09 Vector and Embedding Weaknesses. Expect reviewers to ask which of these you tested, with what scenarios, and which were out of scope. A test plan that names each entry, even when marked not applicable, answers that question directly.

HITRUST AI Security mappings

HITRUST added an Agentic AI selectable factor to its AI Security Certification and mapped it to the OWASP Top 10 for Agentic Applications 2026. Where a RAG system feeds an agent that calls tools, reviewers may ask how memory and context poisoning, identity and privilege abuse, and tool misuse were tested. Confirm with HITRUST and your assessor which factors apply to your scope. DeployOpen prepares test evidence for that assessment. It does not issue the certification.

What your team prepares before testing starts

Before a RAG pipeline test starts, your team needs to hand over the material that lets testers map where retrieved content can travel. The most useful first item is an architecture diagram showing the ingestion path (connectors, parsers, chunking, embedding service), the vector store, the retrieval and reranking layer, the generation model and every point where retrieved text reaches a user or a tool. Pair it with a data flow document and a tenant model that states how tenants are separated: by collection, by namespace or metadata filter, by index, or by separate deployment. Testers need to know which of these boundaries are enforced in the database or service layer and which depend on the application passing the right filter. Ask for the document classification scheme too, so sample content can be matched to each data class.

Access preparation is where most delays come from. Provide test accounts for every role and tenant the design recognizes, including low-privilege users, tenant administrators, and any user whose document permissions differ from their group membership. Testing cross-tenant leakage without a second tenant is not possible, so confirm that a paired tenant exists in the test environment. Then provide sample documents covering each classification, including restricted content that a given role must never see. Under the agreed upload rules, test documents should be synthetic or formally approved for use. Real customer records should not be placed in an embedding index for a test. Confirm with your data protection lead how uploaded test content will be deleted, and whether the vector store will be restored from a snapshot afterward.

Operational readiness closes the gap. Name a technical contact who can answer questions about connectors and index configuration, and an escalation contact with authority to pause testing if a document causes an unexpected effect on a live system. Share change freeze windows so that no index rebuild or model swap lands mid-test. Finally, tell your production monitoring and security operations teams when testing will run and which source addresses and accounts will generate traffic, so that injected documents and unusual retrieval volume are not treated as a live incident. Ask your testing provider to confirm, in the written scope, which of these items it needs before the start date and who on your side owns each one.

What to check when choosing a RAG security testing provider

A RAG security test touches documents, retrieval permissions, embeddings and model output at once, so providers differ most in how they plan and report. The cards below cover the questions that separate a credible proposal from a generic web test with an AI label. Ask for the written items named here before you sign.

Methodology mapped to OWASP and ATLAS

Ask how the provider maps each test to the OWASP Top 10 for LLM Applications 2026, particularly LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM08 Hidden Context Exposure and LLM09 Vector and Embedding Weaknesses, and to MITRE ATLAS techniques such as indirect prompt injection (AML.T0051.001). A good answer names the test cases for each item and explains what evidence proves a control held. A vague reply that only says the provider follows OWASP is a warning sign.

Written scope and rules of engagement

The scope should list the ingestion paths, document stores, vector databases, retrieval APIs, chat interfaces and any agent tools in the test, along with what is excluded. Rules of engagement should state which accounts and tenants are used, which environments are targeted, how test documents are seeded and removed, and who can halt testing. Confirm that the signed scope defines the deliverables and timeline before any work begins.

Handling of tenant data during testing

Retrieval systems often hold several customers' documents in one index, so testers may see data they should not. Ask whether testing uses synthetic documents, how any real tenant content is isolated, where test artifacts are stored, and how they are deleted afterward. Confirm the provider's data handling terms cover screenshots, logs, retrieved passages and captured prompts.

Retrieval architecture experience

Testing a vector store behind a retrieval API requires knowledge of chunking, metadata filters, access-control enforcement at query time, reranking and how a model is prompted with retrieved context. Ask who will run the test, what similar retrieval systems they have assessed, and how they check whether filters are enforced in the database or only in the application layer. Ask for named roles, not only a company description.

Triage of model and infrastructure findings

Some findings are about model behavior, such as an injected instruction in a retrieved document changing the answer, while others are about infrastructure, such as an unauthenticated vector database endpoint. Ask how each type is rated, who fixes it (the model or prompt team, or platform operations), and whether the provider retests model-side findings with the same test cases. Clear ownership in the report speeds remediation.

Report format and retest terms

Request a sample report structure before signing. It should show findings with reproduction conditions described at a defensive level, severity, affected component, remediation guidance and a retest status for each item. Confirm whether one retest round is included, how long after delivery it can be requested, and whether the retest uses the original test cases. This report is what your auditor or customer security review will read, so check that it fits that purpose.

How much effort does RAG pipeline testing take, and what does it need from us?

What drives the cost of a RAG pipeline security test?

The main driver is how much of the pipeline is in scope: the ingestion path, the vector store, the retrieval and access logic, the generation layer, and the application around them. Each additional data source, connector, tenant model and user role adds test cases and setup work. The number of document types the ingestion path accepts, and whether the team needs indirect prompt injection scenarios built from realistic documents, also shape effort. Ask any provider to price each layer separately so you can see what you are paying for. A quote should follow directly from written scope, and DeployOpen does not publish a price list, so the scope document is what you compare.

How long does RAG pipeline testing take, and why does it vary?

Duration depends on scope rather than on a fixed template. A pipeline with one corpus, one tenant model and a single retrieval path takes far less time than one with multiple ingestion sources, per-tenant namespaces, role-based filters and agent tools that read retrieved content. Test environment readiness matters too: if the team must first provision a staging copy with representative data, that time comes before any testing starts. Ask the provider to state the phases in the written plan, including setup, testing, reporting and the retest window, so you can see which parts depend on your environment.

What does the client team need to provide for a RAG pipeline test?

Testers need enough access and context to reproduce how the system really behaves. Typical inputs include:

A architecture diagram showing ingestion sources, the embedding and vector store components, retrieval filters and the model endpoints
Test accounts for each user role and tenant, plus the expected access rules for each
A non-production environment loaded with representative but non-sensitive documents, or agreed rules for using sanitized production data
Logs or traces that show which chunks were retrieved and passed to the model
A named contact who can approve tests against shared components and respond during the engagement

Confirm the rules of engagement in writing before work begins, including any testing limits on live systems.

Can our own engineers test a RAG pipeline in-house?

Yes, many internal teams can run basic checks, such as reviewing access filters, testing whether documents from one tenant appear in another tenant's answers, and reviewing how ingestion handles untrusted files. The gap is usually independent coverage and depth. Teams that built the pipeline tend to test the assumptions they designed around, and they may lack time to build adversarial document sets or to test every layer together. A useful split is internal regression checks for routine changes, with an external test at launch or when the architecture changes. Your own team can prepare the scenarios and environment either way, which reduces external effort.

Does RAG pipeline testing cover production systems?

It can, but only under explicit rules agreed in writing before work starts. Many engagements run against a staging environment that mirrors production configuration, because tests such as planting crafted documents in an ingestion queue or sending high volumes of queries can affect real users and data. If production testing is required, the plan should name the permitted time windows, the accounts used, the data classes that must not be exposed, and the stop conditions. Confirm with the provider how they will handle any real personal or regulated data that a test could touch.

How does retesting work after the team fixes RAG findings?

Retesting checks whether each reported issue is closed, and it should be scoped and priced separately from the original test. The usual approach is to fix the findings, document what changed in the ingestion filters, retrieval rules or prompts, and then re-run the affected test cases in the same environment. Ask the provider how retest results will be recorded, whether changed components need a fresh look for new weaknesses, and how long the retest window stays open. Retesting confirms that the specific weaknesses were addressed. It does not certify the whole system, and an independent auditor decides how any compliance assessment treats those results.

Which recurring costs should we expect after the first RAG test?

The one-time cost is the initial assessment. Recurring costs come from change: new document sources, model upgrades, new agent tools, and new tenants all alter the attack surface and may need targeted tests. Some organizations add a lightweight regression set that runs with each release, while a deeper test happens on a schedule or after significant architectural change. Ongoing support, upgrades and continuous testing can be arranged as retainers, and those terms should be written separately from the initial scope so you can see what recurs and what triggers new work.

How DeployOpen scopes, tests, reports and retests RAG systems

DeployOpen scopes RAG pipeline security testing as a fixed-scope engagement agreed in writing before work starts. We test the ingestion path, the vector store and the answer layer against the same access rules your users operate under, then hand over evidence your team and your assessors can reuse.

How we scope

Written scope names the ingestion sources, vector stores, retrieval services and chat interfaces in the test.
Scope records which user roles, tenants and document classifications must be kept apart during testing.
Test accounts, seeded documents and any agreed test data are listed so results can be reproduced later.

How we build

Testing runs in a controlled copy or staging environment inside your infrastructure, using documents we place for that purpose.
Indirect prompt injection scenarios use planted content in documents and web pages to check what the model does with it.
Access tests compare what each identity can retrieve directly against what the assistant returns to that identity.

How we hand over

Each finding names the affected component, the weakness category, the evidence captured and the access rule that failed.
Remediation guidance is written for the engineers who own ingestion, indexing, retrieval and prompt construction.
Reports map findings to the OWASP LLM Top 10 2026 entries for vector and embedding weaknesses and sensitive information disclosure, so your auditor can trace them.

How we support

Retesting after fixes confirms which findings are closed and records any that remain open.
Ongoing support is available as a retainer for changes to corpora, embedding models and retrieval logic.
Continuous testing can be added to the retainer if your RAG system changes often enough to need it.