RAG Pipeline Security: Embedding Inversion and Vector Store Poisoning

It is common for teams building a RAG pipeline to treat the embedding step as a one-way transformation, converting text into a vector is assumed to be roughly as irreversible as hashing. That assumption does not hold. The clearest evidence is Vec2Text, introduced by John X. Morris and coauthors in the 2023 EMNLP paper "Text Embeddings Reveal (Almost) As Much As Text." Vec2Text treats inversion as a controlled generation problem: it trains a model to propose text, re-embeds that proposed text, measures how far the resulting vector is from the target embedding, and iteratively corrects the proposal until the two vectors converge. Against 32-token inputs, the method achieved 92% exact text recovery, with correspondingly high recovery of specific identifying details, including names extracted from embedded clinical notes. Critically, the attack is black-box: it does not require access to the embedding model's weights, only a set of text-embedding pairs to train the inversion model on, which is realistic for anyone who can query a public embedding API and observe its outputs.

A 2024 follow-up, "Understanding and Mitigating the Threat of Vec2Text to Dense Retrieval Systems," examined why this works and what actually blunts it. The finding relevant to architecture teams is that the risk is not confined to raw, full-precision embeddings. Inversion accuracy degrades but does not disappear against 8-bit quantized embeddings, mean-pooled embeddings, or embeddings of short, low-semantic strings, meaning the storage or transmission optimizations teams already apply for cost reasons are not a substitute for an actual access control decision. The paper's most actionable finding is that injecting calibrated Gaussian noise into embeddings before they are stored or served measurably degrades inversion accuracy while preserving most retrieval quality, which is the closest thing this research area currently has to a validated technical mitigation rather than a policy one.

The practical takeaway is not that embeddings are useless as a representation, it is that anyone who can query the vector store or the embedding API has query access to the underlying documents in a meaningful sense, even without ever seeing the raw text field. That reframes several architecture decisions that teams often treat as pure infrastructure choices.

Where embedding inversion attacks the confidentiality of a RAG pipeline, vector store poisoning attacks its integrity, and the research here is more mature. The most direct demonstration is PoisonedRAG, accepted at USENIX Security 2025, which formalized knowledge corruption attacks against RAG systems: an attacker crafts short passages that are simultaneously optimized to rank highly against a target query and to contain text that steers the LLM toward an attacker-chosen answer when that passage lands in the context window. The result that should concern any team running an open or loosely governed ingestion pipeline is the efficiency of the attack: injecting as few as five crafted documents into a knowledge base containing millions of legitimate documents achieved over 90% attack success across the benchmarks tested. Vector store poisoning does not require compromising a large fraction of the corpus, it requires winning a handful of retrieval races.

A related line of research, Phantom ("General Trigger Attacks on Retrieval Augmented Language Generation"), demonstrates a more targeted variant: a single poisoned document engineered to stay dormant and never surface for ordinary queries, but to be retrieved and activate an adversarial payload the moment a specific trigger phrase appears in a user's query. Phantom's tested objectives included forcing refusals, injecting biased content, and exfiltrating other passages from the context window, evaluated across multiple retrievers and generators up to GPT-4 scale. The common thread across both lines of research is that once a poisoned document is retrieved, the RAG architecture hands it to the LLM as trusted context, which means a successful poisoning attack functions as prompt injection with the pipeline's own retrieval step doing the delivery. Our enterprise prompt injection defense guide covers what happens after that handoff; this is about preventing the handoff from ever occurring.

Poisoning attacks assume the attacker has some way to get content ingested. In practice that assumption holds more often than teams expect, because RAG ingestion pipelines are frequently built for throughput and correctness, not for treating incoming documents as an untrusted attack surface.

Prevention at ingestion is the strongest control, but it is not complete, which is why detection research in this area matters. RevPRAG ("Revealing Poisoning Attacks in Retrieval-Augmented Generation through LLM Activation Analysis") approaches detection from the generation side: it analyzes the LLM's internal activations when responding to a query, on the premise that answers grounded in poisoned context produce a measurably different activation pattern than answers grounded in legitimate retrieved content. A complementary line of work, RAGForensics, works from the corpus side, iteratively sampling subsets of the vector store's documents and using an LLM with a purpose-built prompt to flag passages that look engineered to manipulate rather than inform, functioning as a traceback tool once poisoning is suspected rather than a real-time gate.

Neither of these substitutes for the basic operational controls that both PoisonedRAG's authors and vendor researchers converge on: restricting write access to the vector store to the fewest possible identities, maintaining document provenance (where did this chunk come from, and when), and running periodic re-ingestion audits that diff the current corpus against a known-good baseline to surface additions or changes to a document at ingestion. Layering ingestion controls, provenance tracking, and runtime detection is what the research characterizes as reducing poisoning success rates toward zero; any single layer alone leaves the 90%-with-five-documents result largely intact.

Two vendors working specifically in this space have published research and guidance that lines up with the academic findings above, and it is worth grounding this piece in what they actually say rather than in a generic vendor pitch. Lasso Security's RAG security guidance names data reconstruction from vector embeddings and lax access control as two of the primary risks in RAG deployments, explicitly recommending that teams treat all retrieved content as untrusted input requiring validation, and that access to a vector database be governed with the same rigor as access to the documents it was built from, an approach it frames as context-based access control rather than a flat read/write permission model. WitnessAI's RAG security guidance leans more directly on the PoisonedRAG result, citing the same five-document, 90%-success finding, and separately calls out that decoder-based reconstruction of text from embeddings is a distinct exfiltration path from response manipulation, meaning a team that has locked down retrieval-time output can still be leaking data through the embedding layer itself. Both vendors describe knowledge base poisoning as the most upstream point in the pipeline to control, which matches the architectural framing in this piece: ingestion-time governance is cheaper and more effective than trying to filter or detect after a poisoned document has already been embedded and indexed. Teams evaluating runtime inspection products for the prompt-injection consequences of a poisoning attack, including WitnessAI's own runtime offering, should read our comparison of runtime prompt injection firewalls alongside this piece; that comparison covers what those products actually do and where they fit relative to ingestion-side controls.

Pulling the two threat models together into decisions worth making before a RAG pipeline goes live, not after an incident: