What is RAG security?

Summary slides

Why RAG introduces a distinct security surface beyond a model’s training

A model’s training data is fixed at the exact point training completes, and whatever risk it carries was, at least in principle, reviewable well before the model was ever, formally deployed to users. A RAG system breaks this static picture entirely, since its actual behavior at any moment depends on whatever’s currently sitting in its retrieval index, content that can change well after deployment, content that often comes from sources the organization doesn’t fully control, and content that a model will treat with a level of implicit trust that a purely external, unvetted input wouldn’t receive, precisely because retrieval is a mechanism the system itself deliberately built and relies on.

This shift means RAG security simply can’t inherit the practices built around securing a model’s training process alone, since the actual attack surface here isn’t the training pipeline at all, it’s the ongoing, live pipeline that determines what gets indexed, what gets retrieved for a query, and how that retrieved content gets woven into the model’s context. An organization that’s carefully secured its model training and carefully secured its deployment infrastructure can still have a serious RAG-vulnerability if the retrieval pipeline itself, sitting quietly between those two carefully secured pieces, was never specifically evaluated with its distinct risks in mind at all.

How indirect prompt injection works specifically through retrieved content

Indirect prompt injection, where an instruction embedded in content the model processes gets treated as though it came from a legitimate, authorized source finds its cleanest and most common real-world expression in RAG systems specifically and directly, since retrieval is, by design, a mechanism for pulling external content directly into a model’s context, exactly the pathway indirect injection needs to work. A document sitting in a retrieval index, written by someone with no legitimate relationship to the system at all, can contain text specifically, deliberately crafted to look like an actual instruction, and once that document gets retrieved for a relevant query, the model encounters that embedded instruction sitting right alongside authorized content, with no structural signal distinguishing the two at all.

This particular risk is considerably harder to defend against in a RAG context than in a system with a small, tightly controlled set of inputs, precisely because a retrieval index often needs to be considerably broad to be useful in practice, pulling in documents from many different sources, many different authors, many different levels of trustworthiness, and a defense that simply refuses to retrieve anything from a source that hasn’t been individually, manually vetted defeats much of what makes retrieval valuable in the first place. Effective defense here means treating retrieved content as untrusted input by default, applying the exact same scrutiny to it that a system would apply to raw user input, rather than extending it the kind of implicit, unearned trust that comes naturally from the mere fact that the system itself chose to retrieve it in the first place.

How retrieval poisoning attacks work

Retrieval poisoning refers to the deliberate, calculated act of introducing content into a system’s retrieval index specifically, deliberately to influence future retrievals in a way that benefits the attacker, a considerably more targeted and premeditated version of the indirect injection risk already described above. An attacker who can get content into an index that a legitimate system will later retrieve, through a public wiki the system indexes, a submitted support ticket that becomes part of a knowledge base, a document uploaded through some legitimate-looking channel, gains a persistent foothold that doesn’t require compromising the model or the retrieval infrastructure itself at all, merely getting content past whatever gate governs what’s allowed into the index in the first place.

This particular attack is especially effective precisely because it can be crafted to activate only under deliberately chosen conditions, embedding content that stays dormant and unretrieved for most ordinary queries but that surfaces, and does its intended damage, only when a query happens to match whatever the attacker specifically, deliberately engineered the poisoned document to be retrieved for. This selective activation makes retrieval poisoning considerably harder to catch through ordinary testing than a vulnerability that manifests consistently, since a security review that tests the system against a representative sample of queries can miss a poisoned document that was specifically designed to activate only under a narrow, deliberately chosen condition the review never happened to test.

Defending against retrieval poisoning starts with control over what gets into the index in the first place, treating ingestion as a security-relevant gate rather than a purely functional pipeline step with no scrutiny attached, but it also requires ongoing monitoring of the index’s actual contents, since a system that only screens content at the moment of ingestion but never revisits what’s sitting in the index over real time can miss content that was legitimate when it was first, originally added but has since been edited, at a source the system doesn’t fully control, into something considerably more dangerous than it originally was.

How embedding-space manipulation can distort what gets retrieved

Beyond simply manipulating the actual textual content that gets retrieved, an adversarial actor can attempt to manipulate the embeddings themselves, crafting a document specifically, deliberately designed to embed close to queries it has no topical relationship to whatsoever, ensuring it gets retrieved for queries an honest, naturally written document covering the same actual subject matter never would. This particular kind of embedding-space manipulation exploits the fact that semantic similarity, the entire basis retrieval systems use to decide what’s relevant at all, is a learned, imperfect approximation of relevance, one that a sufficiently motivated attacker with some understanding of how the underlying embedding model works can potentially game to effect.

Defending against this risk is considerably harder than defending against more straightforward, ordinary content-based poisoning alone, since a document crafted for embedding-space manipulation can look entirely unremarkable to a human reviewer while still being engineered to retrieve for queries that have nothing to do at all with its actual, surface-level content. This means defense here benefits considerably less from mere content review alone and more from actively monitoring retrieval patterns themselves tracking whether a document is being retrieved for a set of queries that don’t make intuitive, topical sense together at all, a signal that something about how that document is being retrieved deserves closer investigation regardless of how ordinary its content looks on the surface.

How source trust and provenance should shape how retrieved content is treated

Not every single document sitting in a retrieval index carries the exact same trustworthiness, and a mature RAG security practice tracks this distinction explicitly rather than simply treating every retrieved document as equally, uniformly reliable purely because it happened to make it into the index at all. A document from an internal, carefully reviewed knowledge base deserves considerably different treatment than a document scraped from an open, publicly editable source, and a system that doesn’t preserve this distinction through to the actual point of retrieval is discarding useful risk information that was available all the way back at ingestion time.

This provenance information can shape system behavior in several considerably useful ways worth naming here: weighting retrieval to favor higher-trust sources when a query could plausibly be answered from either a high-trust or low-trust document, applying additional scrutiny specifically to content retrieved from lower-trust sources before it’s allowed to shape a response at all, or simply surfacing the source’s trust level directly alongside the retrieved content so that whoever ultimately reviews an output, human or automated, has the actual context needed to weigh that content appropriately, rather than treating it identically to content that came from a considerably more reliable, trustworthy source.

How per-user and per-tenant retrieval scoping prevents cross-boundary leakage

A retrieval index serving multiple separate users or multiple separate tenants needs its actual retrieval logic to respect the exact same access boundaries that would apply if those users were querying the underlying documents directly and manually, and getting this wrong is one of the most consequential, common failure modes in RAG deployments, since a retrieval system that returns the most semantically relevant documents without checking whether the requesting user is authorized to see them effectively bypasses whatever access control exists on the underlying content, silently, regardless of how carefully that access control was designed at the source.

This particular scoping needs to be enforced at the actual retrieval layer itself, filtering candidate documents against the requesting user’s permissions well before they’re ever passed into the model’s context, rather than relying on the model’s instructions to simply avoid revealing content it was permitted to see but shouldn’t have shared, since a model that already has unauthorized content sitting in its context can be manipulated, through the same indirect injection techniques discussed earlier, into revealing that content despite an instruction telling it not to. Enforcing the boundary before retrieval, not merely instructing the model to respect it after the fact, is what closes this risk rather than merely reducing it.

How stale or outdated retrieved content becomes its security risk

Content that was accurate and safe to retrieve when it was first, originally indexed doesn’t necessarily stay that way over real time, and a retrieval index that never revisits its content for staleness carries a quiet, accumulating risk entirely distinct from the deliberate poisoning attacks already discussed earlier in this article, a security concern in its own right when the outdated content in question involves something like a since-revoked policy, a superseded security procedure, or credentials and configuration details that were valid when indexed but have since been rotated or deprecated for good reason.

Defending against this risk means building content lifecycle management directly into the retrieval pipeline itself tracking when content was last verified as current, actively flagging or deprioritizing content that’s aged past some reasonable, defined threshold, and specifically, deliberately re-reviewing content whose underlying source has meaningfully changed since it was last indexed, rather than treating ingestion as a one-time event after which content simply persists in the index indefinitely with no further scrutiny applied to whether it’s still accurate or still safe to surface.

How to secure the ingestion pipeline that builds the retrieval index

Everything the retrieval system can potentially surface passes through the ingestion pipeline at some point, and this pipeline deserves the exact same security attention as any other system component that determines what an AI system can ultimately do, since a compromise at ingestion propagates directly into every single future retrieval that touches the affected content going forward. This means the ingestion pipeline needs actual access control over exactly who and what can add content to the index at all, actual validation of that content before it’s ever accepted, and a fully auditable record of what was added, when, and by what process giving an organization the actual ability to trace a problematic piece of retrieved content back to its point of origin when an incident does occur.

Automated ingestion sources deserve particular scrutiny here specifically, since a pipeline that automatically indexes content from an external feed, a public repository, a user-submitted form, without any human ever reviewing what’s being added, is exactly the kind of pathway retrieval poisoning is specifically, deliberately designed to exploit. This doesn’t mean every single automated ingestion source needs manual review for every single item, which would defeat much of the practical value of automation in the first place, but it does mean the ingestion pipeline needs deliberate, automated screening tuned to the risks relevant to that particular source, rather than simply treating ingestion purely as a functional data pipeline with no security-relevant gate applied to it at all whatsoever.

How citation and attribution can be exploited to lend false credibility

Many RAG systems are specifically designed to cite their sources showing a user which retrieved document a claim came from, and this citation behavior valuable for building appropriate trust in ordinary use introduces its exploitable risk when an attacker can influence what gets indexed, since a poisoned document that successfully gets retrieved and cited lends its false or manipulated content an air of legitimacy specifically because it’s presented alongside a citation, a signal users have generally learned to associate with trustworthiness.

This means a RAG system’s citation mechanism deserves its security consideration distinct from the retrieval mechanism itself, since a citation is, in effect, a claim about a source’s reliability, and a system that cites every retrieved source with equal, undifferentiated confidence regardless of that source’s actual, underlying trustworthiness is making an implicit claim it can’t back up. Surfacing trust signals directly alongside a citation, rather than simply presenting every cited source as equally, uniformly authoritative gives users the actual information they’d need to appropriately, honestly calibrate how much weight to give a cited claim in that moment.

How to test and monitor RAG systems for these risks

RAG security testing means actively, deliberately attempting the attacks this article has already described, crafting content specifically designed to trigger indirect injection when retrieved, actively attempting to poison an index with content engineered to activate under narrow conditions, testing whether cross-tenant retrieval boundaries hold under deliberate probing, rather than only testing that the system retrieves and answers correctly under ordinary, well-behaved conditions. This testing needs to be ongoing rather than a one-time exercise, since a retrieval index that was clean and well-secured at launch accumulates new content continuously, and each new addition is a fresh opportunity for exactly the risks this article has described to be introduced.

Production monitoring deserves its distinct, dedicated attention, actively tracking retrieval patterns for anomalies, a document being retrieved for a surprisingly broad or topically inconsistent set of queries, a spike in retrievals from a recently added source, a pattern of queries that looks like it’s specifically, deliberately probing the boundaries of what the retrieval system will surface, since these operational signals can catch an active attempt at exploitation that no amount of pre-launch testing, however thorough, could have anticipated for a system whose actual index contents keep changing after that testing was completed.

How RAG security connects to guardrails, data security, and tool calling security

RAG security sits at an intersection of several broader disciplines rather than existing as an entirely separate, standalone concern, and understanding this intersection matters considerably for building a coherent overall defense that holds together. Guardrails address what a model does with the content it receives, including retrieved content, but they operate downstream of retrieval itself and simply can’t undo damage from a retrieval index that was never properly secured in the first place at all. AI data security addresses protecting data broadly across training, context, and output, and RAG security is, in a sense, the application of that broader discipline to the particular pathway retrieval represents. Tool calling security addresses the actual mechanics of how a model invokes functions, and a RAG system that also gives a model tools inherits both sets of risk simultaneously and at once, meaning a retrieval-poisoned document could, in a sufficiently connected system, manipulate which tool gets called next in sequence, compounding the two distinct risk categories together in a way that securing either one entirely alone simply wouldn’t fully address.

This layered view matters because a RAG-vulnerability and a broader guardrail failure can produce results that look identical from the outside, a model producing a harmful or manipulated response, but the actual fix differs depending on which layer failed. A guardrail failure calls for revisiting how the model’s output gets filtered and constrained downstream, while a RAG security failure calls for revisiting what’s sitting in the retrieval index and how that content got there in the first place, and simply treating every problematic output as purely a guardrail issue, without ever examining whether poisoned or manipulated retrieved content was the underlying cause, leaves the root vulnerability entirely, completely unaddressed and unresolved.

How chunking strategy affects the security of a RAG system

Documents in a retrieval index are typically broken into smaller chunks before being embedded and indexed, a practical necessity given the limits of context windows and the way relevance scoring tends to work better against smaller, more focused pieces of text, and this chunking decision, often treated as a purely functional tuning parameter, carries security implications that deserve their explicit consideration. A chunk boundary that splits a document in a way that separates an important qualifying statement from the claim it was originally qualifying can retrieve the claim without its context, producing a result that’s technically drawn from a legitimate source but that no longer accurately reflects what that source said when read in full.

This particular risk matters well beyond mere accuracy concerns alone, since a chunk stripped of its original, surrounding context can be specifically what an attacker relies on when crafting content for retrieval poisoning embedding a claim in a position where the document’s surrounding context would normally undercut or qualify it, betting that the chunking process will separate the claim from that qualifying context well before either piece ever reaches the retrieval index. Reviewing how a chunking strategy behaves around content specifically designed to exploit this separation, rather than only evaluating chunking for its effect on ordinary retrieval quality, closes a gap that pure functional tuning would otherwise leave completely open.

How to handle retrieval from sources the organization doesn’t directly control

Many RAG systems retrieve from sources entirely outside the organization’s direct control, a public knowledge base, a partner’s shared document repository, an open web search, and this particular category of retrieval source deserves its distinct security posture, considerably more conservative than retrieval from an internally curated, carefully reviewed index, precisely because the organization has no ability to vet, in advance, everything that source might ever contain or might ever come to contain in the future. Treating an external source with the same implicit trust extended to an internal knowledge base, simply because both happen to flow through the same retrieval mechanism, ignores a meaningful difference in how much control the organization has over what each source can introduce.

A more conservative posture for external sources typically means applying additional scrutiny to content before it’s allowed to directly shape a response treating it as merely suggestive rather than fully authoritative requiring corroboration from a more trusted source before acting on a claim that originated externally, or simply surfacing to whoever reviews the output that a piece of content came from a source the organization doesn’t directly control, giving that reviewer the context needed to weigh it appropriately rather than treating it as equivalent to internally verified content.

How re-ranking and relevance tuning introduce their security considerations

Many RAG systems apply a secondary re-ranking step after initial retrieval refining the raw similarity-based candidate set into a smaller, more carefully ordered list well before anything reaches the model’s context, and this re-ranking stage deserves its security scrutiny rather than being treated purely as a relevance-quality improvement layered on top of retrieval that’s already been secured. A re-ranker trained or tuned on signals an attacker can influence, click-through data from a system where an attacker can generate synthetic queries, engagement signals from a public-facing feature, can itself become a vector for the same kind of manipulation discussed earlier, shifting which documents reach the model even when the underlying retrieval index and its access controls remain entirely untouched.

This means the security review of a RAG pipeline needs to extend well past the retrieval and indexing stages alone, to cover whatever re-ranking or relevance-tuning logic sits between raw retrieval and final context assembly, asking specifically what signals that logic depends on and whether any of those signals are things an adversarial actor could plausibly influence over time. A re-ranking system built entirely on signals the organization itself directly controls, internal relevance labels, explicit human review carries considerably less of this particular risk than one that incorporates any signal an outside party can shape, even indirectly, through ordinary, legitimate-looking interaction with the system over time.

How caching in a RAG pipeline can quietly extend the lifespan of a security problem

Retrieval and re-ranking are computationally expensive enough that many RAG systems cache their results, either at the level of individual document retrievals or at the level of entire, complete query responses, and this caching valuable for performance, introduces a security wrinkle: a cached result computed before a poisoned document was identified and removed from the index continues serving that poisoned result to users until the cache itself expires or is explicitly invalidated, regardless of how promptly the underlying index was corrected. A security fix applied only at the index level, with no corresponding, deliberate step to invalidate whatever’s already cached leaves the actual, live system still actively serving the exact same problem that fix was meant to resolve in the first place.

This means incident response for a RAG-security issue needs to explicitly, deliberately account for caching as its distinct step, not simply assume that correcting the underlying index automatically, immediately corrects what users experience in practice. An incident response playbook for RAG systems should include cache invalidation as a required, explicit action directly alongside index correction, since skipping this step can leave a resolved-on-paper vulnerability still actively affecting users for as long as the relevant cache entries happen to remain valid.

Common mistakes teams make around RAG security

Several distinct patterns recur often enough across organizations building RAG systems that naming them directly is worth doing before they’re discovered through an actual incident.

1. Treating retrieved content as inherently trustworthy simply because the system itself chose to retrieve it, rather than applying the same scrutiny given to any other untrusted input.

2. Vetting a retrieval index’s content only once, at the moment of ingestion, without any ongoing monitoring for content that’s since been edited or become stale at a source the system doesn’t fully control.

3. Testing a RAG system against a representative sample of ordinary queries without ever testing for selectively activated, poisoned content designed to surface only under narrow, specifically chosen conditions.

4. Assuming semantic similarity is a reliable, ungameable proxy for relevance, missing that embeddings themselves can be deliberately manipulated to retrieve for queries that have nothing to do with a document’s actual content.

5. Treating every document in a retrieval index as equally trustworthy, discarding provenance information that was available at ingestion and that should have shaped how retrieved content gets used downstream.

6. Relying on a model’s instructions to avoid revealing unauthorized content rather than enforcing per-user or per-tenant access boundaries directly at the retrieval layer itself.

7. Treating ingestion as a one-time event after which content simply persists in the index indefinitely, with no further scrutiny applied to whether it’s still accurate or still safe to surface.

8. Automatically indexing content from external feeds or user-submitted sources without any deliberate, automated screening tuned to the risks relevant to that source.

9. Keeping no auditable record of what content was added to the index, when, and through what process, leaving incident investigations unable to trace a problematic document back to its origin.

10. Presenting every cited source with equal, undifferentiated confidence regardless of that source’s actual trustworthiness, lending false credibility to poisoned or low-quality retrieved content.

11. Relying entirely on pre-launch testing without ongoing production monitoring for retrieval patterns that only become suspicious once accumulated usage makes an anomaly visible.

12. Conflating a RAG-security failure with a broader guardrail failure during incident response, fixing the model’s output filtering while leaving a poisoned retrieval index completely untouched.

13. Building cross-tenant retrieval scoping through soft, query-time filtering alone rather than hard architectural separation of tenant data at the strongest layer practically available.

14. Assuming a well-secured model and well-secured deployment infrastructure automatically means the retrieval pipeline sitting between them was also specifically, separately evaluated for its distinct risks.

15. Ignoring the compounding risk that emerges when a RAG system also has tool access, missing that a poisoned retrieved document could manipulate which tool gets called next rather than merely manipulating the model’s text output.

16. Treating chunking as a purely functional tuning parameter, never reviewing how a chunking strategy behaves around content specifically crafted to exploit the separation of a claim from its original, qualifying context.

17. Extending the same implicit trust to sources outside the organization’s control that it extends to an internally curated, carefully reviewed index, simply because both happen to flow through the same retrieval mechanism.

18. Tuning a re-ranking or relevance layer on signals an outside party can influence without ever asking whether that dependency itself creates a new manipulation vector separate from the underlying retrieval index.

19. Correcting a poisoned or stale entry in the retrieval index without explicitly invalidating whatever cached results depend on it, leaving the resolved-on-paper problem still actively affecting users.

What connects all nineteen of these mistakes is a single underlying pattern: extending implicit trust to a retrieval pipeline specifically because the system itself built and controls that pipeline, without recognizing that anything the pipeline can surface into the model’s context deserves the exact same skepticism applied to any other externally sourced input the system doesn’t fully control. A retrieval index that was secure on the actual day it launched can quietly become considerably less secure over real time, through new ingestion sources, through content that ages and drifts from its original context, through nobody ever revisiting whether the trust extended at launch still holds for what the index has become since.

The deeper principle underneath all of this is that retrieval fundamentally breaks the assumption that a model’s actual behavior can be fully, completely understood by reviewing its training and its code alone, since a RAG system’s actual behavior at any moment depends on the current, live contents of an index that keeps changing well after deployment, and an organization that secures everything about its model and its infrastructure while treating the retrieval index itself as a settled, low-risk detail is leaving open precisely the pathway that gives an attacker ongoing, persistent influence over what the system does, long after the system itself was originally, carefully reviewed and formally approved.