Retrieval-augmented generation is the default architecture for enterprise LLM applications in 2026, and it has quietly become the most common point of failure in deployed systems. The threat model is unfamiliar to most application security teams because it spans embedding stores, vector retrieval, document parsing, and prompt construction, with security boundaries that do not map cleanly onto existing categories. This post walks through the controls that actually work, drawn from a year of post-incident reviews and architecture audits.
The framing assumption is that you already have a RAG pipeline in production and you are trying to harden it without rebuilding it. We will skip the design-from-scratch discussion and focus on the controls that retrofit onto LangChain, LlamaIndex, Haystack, and the major managed vector database products in common use.
Where do most RAG incidents originate?
Most RAG incidents originate at the document ingestion boundary. The pipeline pulls content from a wide source set, SharePoint, Confluence, S3 buckets, Notion, Google Drive, customer support tickets, and each source has its own trust level that the ingestion code typically ignores. Once content lands in the vector store, all of it is retrieved with equal authority and stitched into the prompt context. Indirect prompt injection through a poisoned document is the most frequent attack class, and it has been the proximate cause of multiple data exfiltration incidents this year. The mitigation is to preserve source provenance through the entire pipeline. Tag each chunk with its source, the trust level of that source, and the user who ingested it. Use these tags in retrieval-time policy decisions, and surface them in the system prompt so the model is at least aware of the trust context, even if it cannot enforce a boundary by itself.
How is access control handled at the retrieval layer?
Access control at the retrieval layer is the highest-leverage control and the one most often misconfigured. The naive RAG pipeline retrieves over the entire vector store regardless of the requesting user's permissions, and then relies on a downstream filter or the model itself to avoid leaking restricted content. This is broken by default. The correct pattern is to push permission filters into the vector query itself, using metadata fields on each chunk that mirror the source system's access model. Pinecone, Weaviate, and pgvector all support this; the issue is engineering effort rather than capability. The teams that get this right encode permissions as structured metadata at ingestion time and require every retrieval call to include the requesting user's identity, which the query layer translates into the appropriate filter. The teams that get it wrong rely on prompt-level instructions to the model, which fail under adversarial pressure.
What about embedding-side attacks?
Embedding-side attacks are less common but worth understanding because the mitigations are not obvious. The threat model is that an attacker crafts content designed to embed near sensitive queries, polluting retrieval results with attacker-controlled context. This works because embedding models cluster semantically similar content together, and an attacker with knowledge of the embedding model can engineer documents to land near target query vectors. The mitigations are layered: source-level access control prevents untrusted contributors from getting content into the index in the first place; re-ranking with a separate cross-encoder catches results that match by adversarial similarity but fail on actual relevance; and outlier detection on retrieved chunks flags content that scores high on the embedding similarity but low on coherence with the query. These are still emerging controls and the tooling is rough, but the threat is real and the mitigations are tractable.
How should the prompt construction stage be hardened?
Prompt construction is the stage where retrieved content meets user input and system instructions, and the structure of this concatenation is security-relevant. The hardened pattern uses explicit delimiters and trust markers that the model has been fine-tuned to respect, separates retrieved content from user input into clearly distinguishable sections, and includes instructions that retrieved content should be treated as data rather than commands. None of this is sufficient on its own, because the model is a probabilistic filter rather than a boundary, but the combination meaningfully reduces injection success rates. The other common failure is over-long context windows that effectively dilute the system prompt; long-context models have made this worse because developers now stuff entire document corpora into the context and lose the instruction salience that shorter contexts preserved. Truncating retrieval results and re-ranking aggressively keeps the signal-to-noise ratio defensible.
How is the response side being secured?
The response side of a RAG pipeline needs the same output handling discipline as any LLM application, plus a specific check for whether the model has leaked content from chunks the user should not have seen. The hardest case is when the retrieval permission filter is misconfigured and content slips through; output-side detection becomes the last line of defense. Production teams are running a small classifier on every response that checks for content patterns consistent with the user's allowed scope, blocking responses that contain identifiers or content fingerprints from out-of-scope sources. This is imperfect but it has caught real misconfigurations before they produced incidents. The other increasingly common practice is response-level citation enforcement: the model must cite specific chunk IDs for every factual claim, and the application verifies that those chunks were in the user's retrieval scope before rendering. This is particularly important in regulated industries where audit defensibility matters more than latency.
How Safeguard Helps
Safeguard maps the security state of your RAG pipeline through the same SBOM and reachability lens it applies to the rest of your software stack. Griffin AI surfaces CVEs in LangChain, LlamaIndex, and vector database clients that affect actually-reachable code paths in your deployed RAG service, dropping noise and elevating real risk. Policy gates block builds that ingest from new untrusted sources without matching access control metadata, and our zero-day feed flags vendor-disclosed retrieval and embedding-layer attacks within hours. TPRM scoring evaluates the embedding model providers and vector database vendors your pipeline depends on, including their breach history and their access control design. The result is an auditable security posture across the full RAG stack, not just the model layer.