Retrieval-Augmented Generation has become one of the most practical ways to connect large language models with private or frequently changing information. Instead of relying only on what a model learned during training, a RAG application searches an external knowledge source, retrieves information relevant to the current request and places that information into the model’s context before generating an answer. NIST describes RAG in essentially this way: a generative AI model is paired with a separate information-retrieval system so relevant external information can be added at runtime.

That architecture solves an important product problem, but it also introduces a new security boundary.

The knowledge base may contain customer records, company documents, internal procedures, legal information, source code or proprietary research. Retrieved content may also originate from sources that cannot be fully trusted. If access control, document provenance or context handling is weak, an AI assistant can become an interface for unauthorized data retrieval or a channel through which malicious content manipulates model behavior.

OWASP classifies Vector and Embedding Weaknesses as LLM08:2025 and specifically highlights risks affecting RAG systems, including malicious content injection, manipulated model output and unauthorized access to sensitive information.

This means securing RAG requires more than securing the vector database.

The complete pipeline matters.

What Is RAG Security?

RAG security is the practice of protecting the retrieval pipeline, knowledge sources, embeddings, access controls and model interactions that make Retrieval-Augmented Generation possible.

A typical RAG application follows a relatively simple conceptual flow.

The user provides a request. The application transforms that request into a retrieval query. Relevant information is selected from a knowledge source. That content is inserted into model context, and the LLM generates a response based partly on the retrieved information.

The security problem is that every stage introduces assumptions.

The system assumes the user should be able to retrieve the selected information.

It assumes the knowledge source has not been maliciously manipulated.

It assumes retrieved content should be treated as information rather than trusted instructions.

It assumes information from different users or tenants remains isolated.

And it assumes the model will not reveal more of the retrieved context than the application intended.

OWASP notes that weaknesses in how vectors and embeddings are generated, stored or retrieved can affect confidentiality, integrity and model behavior in RAG environments.

A secure implementation therefore needs controls around both what is retrieved and what happens after retrieval.

How Retrieval Changes the LLM Attack Surface

Without retrieval, a model primarily works with information already contained in its parameters and the context supplied directly by the application.

RAG introduces external data at runtime.

That distinction is critical because the information source may now be partially controlled by users, employees, customers, external websites or other systems.

NIST’s current adversarial machine-learning taxonomy explicitly recognizes this attack surface. It describes indirect prompt injection in RAG and other GenAI applications as attacks where an adversary modifies external resources that will later be ingested into model context.

The person manipulating the content does not necessarily need access to the AI interface.

They may only need control over something the AI will eventually read.

This creates a new threat model for enterprise AI systems.

A malicious document uploaded today could potentially influence an AI assistant tomorrow when another user retrieves it.

A compromised knowledge source could affect thousands of later responses.

An external webpage could contain content that changes an agent’s behavior when that page enters context.

RAG therefore converts the knowledge layer itself into part of the application attack surface.

Security Risks Inside the RAG Pipeline

A useful RAG threat model should follow information from its origin all the way to the final response.

The security team needs to know who can add information, how that information is transformed, where it is stored, how retrieval works and which user is allowed to receive it.

Weaknesses often appear between these components rather than inside the model itself.

Untrusted Documents

One of the most important mistakes in RAG architecture is assuming that because a document exists inside an approved knowledge base, its contents are trustworthy.

The document may have been uploaded by a customer.

It may have been imported automatically.

It may originate from a third-party website.

It may have been written by an employee whose account was compromised.

Even legitimate content can contain text that the LLM interprets differently from the application developer’s intention.

NIST specifically notes that indirect prompt injection can arise when an attacker has control over documents, webpages or other resources later ingested into a GenAI system.

A secure RAG system should therefore distinguish between trusted application instructions and retrieved data that may contain adversarial content.

That distinction needs to exist architecturally, not only linguistically.

Poisoned Knowledge Sources

Knowledge-base poisoning occurs when malicious or misleading material is introduced into information the RAG system may later retrieve.

This is particularly dangerous because the attack can become persistent.

Instead of manipulating one conversation, the attacker modifies the underlying knowledge source so future queries repeatedly retrieve adversarial content.

NIST’s adversarial AI taxonomy discusses knowledge-base poisoning in RAG systems and notes research showing that poisoned documents can be crafted to influence generated outputs for targeted queries.

For security teams, the practical concern is not limited to malicious instructions.

Poisoned data can also affect information integrity.

An AI assistant may confidently provide inaccurate internal guidance because the knowledge source it trusts has been modified.

This makes document provenance, publishing permissions and change monitoring important parts of RAG security.

Cross-User Data Exposure

A RAG system can retrieve the correct document and still be insecure.

The document may be relevant to the query while remaining unauthorized for the requesting user.

This distinction between relevance and authorization is one of the most important principles in RAG architecture.

A vector database is designed to identify semantically relevant information.

It is not automatically an access-control system.

If a user asks a question about a customer account, the retrieval layer may find several highly relevant records. Security depends on whether those records belong to the user’s authorized scope.

This becomes particularly serious in multi-user and multi-tenant SaaS applications, where a single shared knowledge layer may contain information from multiple customers.

NIST recognizes access to a RAG knowledge base as a potential privacy target and discusses privacy-compromise attacks aimed at restricted or proprietary information available to generative AI systems.

The correct boundary is clear:

authorization should determine which documents are eligible for retrieval before similarity determines which eligible documents are most relevant.

Retrieval Permission Failures

Many insecure RAG architectures apply permissions too late.

The system searches broadly, retrieves several documents and then expects the model to avoid mentioning content that the user should not see.

That design gives the model responsibility for confidentiality.

A stronger architecture filters the retrieval universe according to the authenticated identity before documents enter model context.

If User A does not have permission to access a document, that document should ideally never become part of User A’s LLM context.

This follows the same principle discussed in our article on sensitive data leakage in AI systems: deterministic access control should decide what the AI can know.

The LLM should not become the organization’s document-permission engine.

Indirect Prompt Injection Through Retrieved Content

Indirect prompt injection is one of the most distinctive RAG security problems.

The primary user may ask a completely legitimate question.

The retrieved document contains adversarial instructions.

The model processes both the user’s legitimate request and the hostile content inside the retrieved resource.

NIST explains that GenAI applications combine data and instruction channels in ways that can allow attackers controlling external resources to influence system operation indirectly. It identifies possible consequences across availability, integrity and privacy.

This is fundamentally different from ordinary direct prompt injection.

The legitimate user may not be the attacker at all.

In some scenarios, the user is the victim.

A researcher asks an AI assistant to summarize an external source, and malicious content inside that source attempts to redirect the assistant toward another objective.

A customer-support agent retrieves a ticket containing adversarial instructions.

An enterprise copilot searches a shared document repository containing compromised content.

The attacker is exploiting the AI’s willingness to interpret language wherever that language appears.

Why Retrieved Content Must Be Treated as Untrusted Input

Traditional web applications already teach developers not to trust user input.

RAG extends that principle.

Retrieved content should not become trusted simply because it passed through a vector search.

Similarity is not trust.

Indexing is not security validation.

A document’s presence inside the knowledge base does not guarantee that its content should influence agent behavior.

This leads to a useful architectural rule:

RAG content can inform the model, but it should not automatically control the system.

The application may reinforce separation between trusted instructions and retrieved data, apply content processing or filtering, constrain tool access and keep important authorization decisions outside the LLM.

NIST notes that several mitigation approaches have been explored for indirect prompt injection, including distinguishing trusted from untrusted data, filtering instructions from third-party sources and using well-defined interfaces around potentially untrustworthy information. NIST also cautions that current mitigations do not provide complete protection against every attacker technique.

That last point is critical.

If prompt-injection defenses can fail, architecture needs to limit what failure can cause.

Vector and Embedding Security Risks

RAG security is often discussed only at the prompt layer, but the retrieval mechanism itself deserves attention.

Embeddings transform content into representations that allow semantic similarity search.

Those representations and the systems storing them become part of the security architecture.

OWASP’s LLM08:2025 specifically identifies weaknesses in vectors and embeddings as significant risks in RAG applications and warns that problems in generation, storage or retrieval can be abused to manipulate outputs or access information.

The main lesson is not that embeddings are inherently insecure.

It is that teams sometimes treat the vector store as a neutral technical component while ignoring the security properties of the data inside it.

A production vector database may hold representations of confidential corporate information.

It therefore needs the same security thinking applied to other sensitive data stores.

Authentication matters.

Authorization matters.

Tenant isolation matters.

Data provenance matters.

Monitoring matters.

The fact that information is stored as embeddings rather than plain relational rows does not remove confidentiality requirements.

Tenant Isolation Must Exist Before Model Generation

Multi-tenant RAG presents one of the clearest commercial security risks.

Imagine a SaaS platform where every customer’s documents are stored in one retrieval infrastructure.

Customer A asks a question.

The vector search identifies a highly similar document belonging to Customer B.

If tenant filtering is missing or incorrectly implemented, the document may enter Customer A’s model context.

At that point, the application is already in a dangerous state.

Even if the model usually refuses to disclose the content, the confidentiality boundary is now probabilistic.

A stronger architecture makes tenant identity part of retrieval authorization.

The retrieval service should determine which records are available to the current tenant before ranking relevant results.

The principle is identical to ordinary API security.

A user should not be able to retrieve another tenant’s database object simply because they know the right identifier.

An AI user should not be able to retrieve another tenant’s document simply because their query is semantically similar.

RAG Permissions Need to Match the Source System

Enterprise organizations often already have sophisticated document permissions.

The problem appears when AI indexing silently removes them.

An employee may have access to one project folder but not another.

A legal repository may contain restricted material.

An HR system may enforce access based on role.

If a RAG pipeline copies all of those documents into one unrestricted knowledge base, the AI layer effectively flattens the organization’s existing permission model.

That is a security regression.

The safer approach is to preserve source permissions or create an equivalent authorization layer during retrieval.

A document should not become more accessible merely because it has been embedded.

This consideration becomes even more important when data sources change over time.

If an employee loses access to a source document, the RAG layer should not continue exposing an outdated indexed copy indefinitely.

Data Freshness Can Become a Security Issue

RAG is often introduced partly because organizations want models to work with current information.

But stale data can also create security problems.

Permissions change.

Documents are reclassified.

Accounts are disabled.

Contracts expire.

Security procedures are updated.

If the retrieval index does not reflect those changes, an AI assistant can continue exposing information that the source system no longer allows.

This is not a model vulnerability.

It is a synchronization and access-control vulnerability in the RAG architecture.

Security teams should therefore understand how quickly changes in the authoritative data source propagate into retrieval infrastructure.

Deletion is particularly important.

Removing a confidential document from the source system should not leave forgotten copies available through the AI layer.

Chunking Does Not Neutralize Malicious Content

RAG pipelines often split documents into smaller chunks before storing or retrieving them.

This improves search and context management.

It should not be assumed to remove adversarial instructions.

NIST notes research in which malicious execution triggers remained effective through RAG processing stages that included chunking and contextual filtering.

This is a useful reminder that security should not depend on incidental transformations of hostile content.

A malicious instruction may survive formatting changes.

The application needs explicit trust boundaries regardless of how the document is processed.

RAG Security Becomes More Serious When Agents Have Tools

A RAG chatbot that retrieves an adversarial document may produce incorrect information.

A RAG-enabled agent with tools can create a more serious security path.

The malicious document influences model reasoning.

The model chooses a tool.

The tool performs an action.

At that point, a document stored inside the knowledge base has indirectly affected application behavior.

NIST’s adversarial AI taxonomy describes integrity attacks where indirect prompt injection can hijack GenAI agents and redirect them toward attacker-specified objectives.

This is why RAG security and AI agent security increasingly overlap.

The more authority available downstream from retrieval, the more aggressively untrusted content must be contained.

An internal knowledge assistant with no write capability presents one risk profile.

An autonomous agent using the same knowledge base to make operational changes presents another.

Retrieval Should Not Automatically Trigger Action

One useful architectural separation is keeping retrieval and execution distinct.

The model may retrieve information explaining that a certain operation is needed.

That does not mean the operation should automatically happen.

High-impact actions should remain subject to independent validation.

This prevents malicious or corrupted knowledge content from becoming a direct control channel for production systems.

The model can use retrieval to reason.

The application remains responsible for authorization.

This distinction becomes increasingly important as companies build agents around internal documentation.

Documentation can describe what administrators normally do.

It should not automatically become executable policy.

RAG Security and Sensitive Data Leakage

RAG often gives models access to exactly the information companies care most about protecting.

That may include internal documents, customer records or proprietary knowledge.

NIST specifically identifies privacy-compromise attacks in which adversaries attempt to obtain restricted information available to a GenAI system, including knowledge bases used by RAG applications.

The security objective should therefore be more precise than “prevent data leakage.”

Teams need to know which identities may access which knowledge.

A retrieval request should inherit the user’s authorization context.

The model should receive only the information necessary for the current task.

And downstream outputs should avoid exposing unnecessary source material.

This follows a simple principle:

RAG should improve access to authorized knowledge, not broaden authorization to knowledge.

RAG Knowledge-Base Poisoning Is an Integrity Problem

Confidentiality receives significant attention in AI security, but RAG also creates integrity concerns.

If an attacker can influence trusted knowledge, they can potentially influence answers generated for legitimate users.

NIST’s adversarial AI taxonomy describes knowledge-base poisoning techniques in which malicious documents are introduced into RAG systems to cause targeted changes to model output.

For businesses, the consequence can extend beyond an incorrect chatbot answer.

AI systems are increasingly used to assist customer support, technical operations, decision-making and automated workflows.

If the retrieved information becomes maliciously manipulated, the AI may amplify that manipulation.

Security controls should therefore govern who can publish, modify and approve knowledge sources used by production AI.

Document Provenance Matters

A secure RAG system should be able to answer a basic question:

Where did this information come from?

Source provenance allows an application to distinguish internal documentation from external content, approved knowledge from user uploads and authoritative information from lower-trust material.

This does not automatically solve injection or poisoning.

It gives the system information needed to apply different controls.

A trusted internal procedure may be handled differently from a webpage retrieved from the public internet.

A customer-uploaded file may be valid input while remaining untrusted for operational decision-making.

NIST’s Generative AI Profile recommends documenting the origins and sources of data and documenting how retrieval augmentation has been applied to the system.

For security engineering, provenance is useful because trust becomes explicit instead of implicit.

How to Penetration Test a RAG Application

A meaningful RAG penetration test should begin with architecture mapping rather than random prompt attacks.

Researchers first need to identify the data sources feeding the system.

Which repositories are indexed?

Who can place information into those repositories?

Which users can search them?

How are permissions preserved?

Does the vector database serve several tenants?

Can the application retrieve public external content?

Which tools or agents consume the retrieved results?

Once those relationships are understood, security testing can target actual trust boundaries.

Test Retrieval Authorization First

One of the highest-value RAG security tests is straightforward: verify whether users can retrieve only information they are legitimately authorized to access.

Security researchers can use different test users, roles or tenants to compare retrieval behavior.

The objective is not to trick the model into revealing a large amount of confidential information.

A minimal controlled demonstration is enough to establish that the access boundary has failed.

This is important because authorization weaknesses should not be misclassified as “hallucination” or “AI weirdness.”

If the wrong document entered context, the model may simply be exposing an upstream retrieval-security problem.

Test Indirect Prompt Injection Through Controlled Documents

Where the engagement permits it, security testing should determine whether controlled untrusted content can alter model behavior after retrieval.

The goal is to understand the trust relationship between external content and model instructions.

Researchers should then follow the resulting behavior to practical impact.

Can the manipulated context influence data access?

Can it affect an agent’s choice of tools?

Can it alter the generated response in a security-sensitive way?

Does a deterministic application control stop the attack before meaningful impact occurs?

Testing should remain defensive and proportionate.

The objective is to validate the boundary, not cause unnecessary damage.

Test Knowledge-Source Permissions

Another important question is who can modify the data used by the AI.

A RAG deployment may have excellent end-user access controls while allowing an overly broad group of users to publish documents into a trusted knowledge source.

That creates an integrity attack surface.

Security testing should examine the process by which information enters the index, including whether content from less-trusted sources becomes indistinguishable from approved internal knowledge.

This is especially relevant when indexing occurs automatically.

Automated ingestion improves scale.

It also means compromised source content can propagate into the AI system without manual review.

Test Cross-Tenant Isolation at Every Layer

In multi-tenant systems, isolation should be evaluated beyond the frontend.

The application layer may correctly identify the tenant while the vector store uses insufficient metadata filtering.

Conversation memory may mix context.

A caching layer may return retrieval results generated under a different identity.

A tool connected after the LLM may use broad service credentials.

Security researchers should therefore follow tenant identity through the complete workflow.

The critical question is whether the isolation property survives from authentication all the way through retrieval and generation.

Test What Happens After Retrieval

Some RAG assessments stop after confirming that the correct documents are selected.

That misses much of the real attack surface.

Researchers should also examine how retrieved information affects subsequent application behavior.

Does the model simply generate text?

Can it select another tool?

Can retrieved data change a business decision?

Can generated output be consumed programmatically?

Can the agent transmit retrieved information to an external system?

Security impact often exists after retrieval rather than during retrieval.

This is why ShabuShabu’s LLM security testing methodology follows complete attack paths rather than evaluating components independently.

Building a Secure RAG Architecture

There is no single control that makes RAG secure.

The strongest designs combine several independent boundaries.

User identity should be established before retrieval.

Permissions should limit the eligible knowledge set.

Tenant separation should be preserved.

Knowledge sources should have clear provenance.

Untrusted documents should remain untrusted after retrieval.

Sensitive information should be minimized before entering model context.

Tools should independently enforce authorization.

High-impact actions should not execute solely because retrieved text influenced model reasoning.

These controls work together because they do not assume any one component will behave perfectly.

Secure Retrieval Starts Before Vector Search

One of the strongest architectural patterns is conceptually simple.

First determine what the user is permitted to access.

Then search within that authorized set.

This is safer than searching everything and attempting to filter afterward.

It also makes the security model easier to reason about.

The vector system becomes responsible for relevance.

The authorization system remains responsible for permission.

Each component performs the job it is designed to perform.

Separate Knowledge Trust From Knowledge Relevance

A result can be highly relevant and still be untrusted.

This matters especially in systems combining internal documents with public internet retrieval.

The AI may need both.

But they should not automatically receive identical authority.

An internal approved policy may be considered a strong source of business information.

A public webpage may be useful research material while remaining attacker-controlled input from a security perspective.

The model should be able to use different sources without the application silently treating all retrieved text as equally trustworthy.

This separation becomes essential when RAG is connected to autonomous actions.

Monitor Changes to High-Value Knowledge Sources

If an AI system depends on a knowledge base for important decisions, changes to that knowledge base become security-relevant events.

Organizations should understand who modified important content and when.

The appropriate level of monitoring depends on the application, but high-impact sources deserve stronger governance than ordinary low-risk documents.

This is analogous to configuration management in conventional infrastructure.

If changing one file can materially change production behavior, access to that file matters.

If changing one document can materially change an AI workflow, access to that document also matters.

RAG Security Should Be Reassessed When the Data Changes

Organizations frequently retest applications after major software releases.

RAG systems introduce another trigger: significant changes to information architecture.

Adding a new document source can create a new trust boundary.

Connecting HR records introduces different privacy requirements from public documentation.

Combining several tenant repositories changes isolation complexity.

Allowing automatic web retrieval introduces externally controlled content.

Connecting the RAG system to an autonomous agent changes the impact of malicious retrieval entirely.

NIST’s Generative AI Profile recommends reassessing model risks after system adaptations including retrieval-augmented generation.

In practical product security, every meaningful expansion of retrieval access should therefore trigger a new threat-model discussion.

Fix the Retrieval Boundary, Not One Bad Prompt

When teams discover a RAG vulnerability, it is tempting to fix the exact conversation that demonstrated it.

A new prompt instruction is added.

One document is blocked.

One suspicious phrase is filtered.

The original test stops working.

That can create false confidence.

The stronger question is what architectural condition enabled the problem.

If the wrong tenant’s document entered context, fix retrieval authorization.

If malicious content from user uploads could control an agent, fix the trust boundary between retrieval and action.

If too many users could publish trusted knowledge, fix ingestion permissions.

If sensitive source material remained indexed after access was revoked, fix synchronization and lifecycle handling.

Security remediation should remove the vulnerable property rather than one visible symptom.

RAG Security Is Ultimately About Controlling Knowledge

RAG makes AI systems valuable because it gives models access to information they otherwise would not have.

That means the security model needs to control that access with the same seriousness applied to APIs and databases.

Who can place information into the knowledge system?

Who can retrieve it?

Which tenant owns it?

Where did it originate?

Should the AI trust it?

Can it influence an action?

What happens when it is deleted or reclassified?

Those questions define the real RAG attack surface.

A vector database does not remove the need for authorization.

An embedding does not make information safe.

Retrieval relevance does not establish trust.

And a model instruction cannot replace deterministic security controls.

A secure RAG architecture allows AI to find the knowledge it needs while preserving the boundaries that determine who is allowed to know what.

Frequently Asked Questions About RAG Security

What is RAG security?

RAG security is the protection of Retrieval-Augmented Generation systems against unauthorized data access, knowledge-base poisoning, indirect prompt injection, cross-tenant leakage and weaknesses in vector or embedding infrastructure. OWASP specifically identifies Vector and Embedding Weaknesses as an LLM application risk affecting RAG systems.

Can RAG systems leak sensitive data?

Yes. A RAG system may expose confidential information when retrieval permissions are weak or when protected knowledge enters a model context available to an unauthorized user. NIST includes RAG knowledge bases among the restricted information sources that may be targeted in GenAI privacy-compromise attacks.

What is RAG prompt injection?

RAG prompt injection usually refers to adversarial instructions contained in information retrieved into model context. In an indirect prompt-injection scenario, the attacker may manipulate an external resource rather than communicating directly with the AI application.

What is knowledge-base poisoning?

Knowledge-base poisoning occurs when malicious or misleading information is introduced into a RAG knowledge source with the intention of influencing later model responses or system behavior. NIST documents this as a demonstrated class of attack against RAG systems.

Is a vector database an access-control system?

Semantic retrieval and authorization solve different problems. The vector system determines which content is relevant, while the application should independently determine which content the current identity is permitted to access.

How do you secure a multi-tenant RAG application?

Tenant identity should remain part of the retrieval authorization process so documents belonging to another tenant are not eligible to enter the current user’s model context. Security testing should also verify isolation in caching, memory, tools and other downstream components.

How do you penetration test a RAG application?

A RAG penetration test should map knowledge sources, test user and tenant authorization, evaluate indirect prompt injection through controlled content, review ingestion permissions and follow retrieved information into downstream tools or agent actions.

When should RAG security be retested?

RAG security should be reconsidered when new knowledge sources are connected, permissions change significantly, multi-tenant functionality expands, external retrieval is introduced or the RAG system is connected to more powerful AI agents or tools.