Retrieval-Augmented Generation (RAG) security is the discipline of protecting the data pipelines, vector databases, and retrieval logic that feed external knowledge into large language models before those models generate a response. Unlike a standalone chatbot that only draws on its training data, a RAG system pulls in documents, code, tickets, or web pages at query time — which means every one of those sources becomes a potential attack surface. In June 2024, JFrog disclosed CVE-2024-5565, a prompt injection flaw in the popular Vanna.ai text-to-SQL RAG library that let attackers achieve remote code execution simply by controlling data the model would later retrieve. That single CVE captures the core problem: in RAG architectures, "data" and "instructions" blend together, and traditional application security controls were never built to police that boundary. Security teams adopting RAG for internal search, copilots, and customer support need a new threat model — this glossary post breaks it down.
What Is RAG Security?
RAG security is the set of controls that protect the four components of a retrieval pipeline: the data ingestion layer, the embedding model, the vector store, and the orchestration logic that assembles retrieved content into a prompt. A typical enterprise RAG stack ingests documents from sources like Confluence, SharePoint, Slack exports, or a code repository, converts them into vector embeddings using a model such as OpenAI's text-embedding-3 or an open-source alternative like BGE, stores those vectors in a database like Pinecone, Weaviate, Chroma, or Postgres with pgvector, and retrieves the top-k nearest matches at query time to inject into the LLM's context window. Each hop — ingestion, embedding, storage, retrieval, and prompt assembly — has a distinct failure mode, from stale access controls on the source documents to unauthenticated vector database endpoints exposed to the internet. Because RAG systems are often stood up quickly by application teams rather than security teams, misconfigurations accumulate fast: Shodan and Censys scans throughout 2024 repeatedly turned up thousands of exposed Elasticsearch and vector database instances with no authentication, many holding embeddings of proprietary or customer data.
How Do Attackers Exploit RAG Pipelines?
Attackers exploit RAG pipelines primarily through indirect prompt injection, where malicious instructions are hidden inside content the system will later retrieve and feed to the LLM — not typed directly by the user. This attack class was formalized in the February 2023 paper "Not What You've Signed Up For" by Greshake et al., which demonstrated that a webpage containing hidden text could hijack Bing Chat's behavior once the assistant retrieved and summarized that page. The same mechanic scales to enterprise RAG: a poisoned PDF sitting in a shared drive, a support ticket with embedded instructions, or a GitHub issue comment can all silently redirect an LLM's behavior the moment they're retrieved into context. The Vanna.ai case (CVE-2024-5565) took this further — the library passed LLM-generated Python directly to exec() to render charts, so a prompt injection in retrieved data escalated straight to remote code execution on the host running the RAG application. LangChain has had comparable issues, including CVE-2023-36258 (arbitrary code execution via the PALChain module) and CVE-2023-29374 (code injection in LLMMathChain), both stemming from the same pattern: LLM output treated as trusted, executable input.
What Is Retrieval or Knowledge-Base Poisoning?
Retrieval poisoning is an attack where an adversary inserts crafted documents into the corpus a RAG system indexes, so that the system retrieves and trusts attacker-controlled content instead of legitimate sources. The 2024 academic paper "PoisonedRAG" (Zou et al.) quantified how little effort this takes: the researchers showed that injecting just five malicious text chunks into a knowledge base containing millions of legitimate documents achieved a greater than 90% attack success rate against RAG pipelines built on GPT-4, PaLM 2, and other production-grade LLMs. In practice, poisoning doesn't require breaching the vector database directly — it's often enough to get a malicious file into a source system the ingestion pipeline already trusts, such as a public wiki, a shared support inbox, or a package README that gets scraped into a documentation RAG. Because embedding similarity search has no concept of provenance or intent, a well-crafted poisoned chunk that's semantically close to a target query will reliably outrank legitimate content for that query.
Can Attackers Steal Data Through Embeddings Alone?
Yes — embedding vectors are not anonymized data, and research has repeatedly shown they can be inverted back into readable text. The 2023 EMNLP paper "Text Embeddings Reveal (Almost) As Much As Text" (Morris et al.) introduced Vec2Text, a technique that reconstructed the exact original text from its embedding with high precision for models like GTE-base, recovering full sentences from vectors that many teams assumed were a safe, one-way transformation of sensitive source data. This matters for RAG specifically because embeddings of proprietary documents, PII-laden support tickets, or source code are routinely stored in third-party vector database services, sometimes with looser access controls than the source system itself, on the assumption that "it's just numbers." If an attacker gains read access to a vector index — through a misconfigured API, an SSRF pivot, or an over-permissioned integration — embedding inversion turns that access into a direct data breach.
How Is RAG Security Different From Traditional Application Security?
RAG security differs from traditional AppSec because the trust boundary between "data" and "code" collapses — retrieved text becomes part of the model's effective instruction set, with no sandbox to contain it. A SQL injection defense works because you can parameterize a query and separate data from command syntax; there is no equivalent hard boundary between a retrieved document and the natural-language prompt it gets concatenated into. The OWASP Top 10 for LLM Applications (2025 edition) reflects this shift directly, ranking LLM01: Prompt Injection as the top risk and adding LLM04: Data and Model Poisoning and LLM08: Excessive Agency as categories that map almost exactly onto RAG-specific failure modes. Traditional AppSec tooling — SAST, DAST, and dependency scanning — will catch a vulnerable LangChain version or an exposed Chroma endpoint, but none of it evaluates whether a retrieved chunk of text can override a system prompt, which is why RAG deployments need dedicated red-teaming and runtime guardrails on top of standard scanning.
What Should Security Teams Do First to Reduce RAG Risk?
The highest-leverage first step is treating every data source feeding a RAG pipeline as untrusted input and inventorying it the same way you'd inventory a software dependency. That means mapping which vector databases exist across the organization (a surprising number get spun up ad hoc by ML teams outside standard change management), verifying authentication is enforced on each one, and confirming that document-level access controls from the source system — like a Confluence space's permissions — are actually preserved when that content is chunked and embedded, which is a common gap. Teams should also pin and patch RAG framework versions given the CVE history above (LangChain, Vanna.ai, and similar libraries have shipped multiple critical fixes since 2023), and add prompt injection test cases — including indirect ones planted in retrievable documents — to CI before a RAG feature ships.
How Safeguard Helps
Safeguard extends software supply chain security into the AI stack, starting with SBOM generation and ingest that catalogs the RAG frameworks, embedding libraries, and vector database clients running in your environment — including flagged versions like the ones affected by CVE-2024-5565 and CVE-2023-36258 — so a known-vulnerable component doesn't sit undetected in a production pipeline. Reachability analysis then determines whether a vulnerable function, such as an unsandboxed exec() call in a charting library, is actually invoked in a code path that processes retrieved or LLM-generated content, cutting through noisy CVE alerts to surface the ones that matter. Griffin AI applies this same context-aware analysis to AI-specific findings, correlating exposed vector database endpoints, outdated retrieval libraries, and risky data-flow patterns into a single prioritized view instead of disconnected alerts. When a fix is available, Safeguard opens an auto-fix pull request that bumps the affected dependency and reruns validation, so security teams can remediate RAG supply chain risk with the same speed and precision they already apply to the rest of their codebase.