What Is Actually Different About RAG Security
Generic LLM security talk centers on the model boundary: jailbreaks, direct prompt injection typed into a chat box, output filtering before a response ships. RAG adds an earlier boundary that has nothing to do with the model. Before the model sees a question, a retrieval step decides which documents get pulled from a corpus and concatenated into the context window as trusted background. That pipeline, ingestion, embedding, indexing, retrieval, filtering, has its own attack surface, and a well-behaved model will still repeat whatever the pipeline hands it, because RAG is built on the assumption that retrieved text is safe context, not input that needs scrutiny.
Three attack patterns fall out of that assumption directly:
- Corpus poisoning: an attacker gets a crafted document into the source corpus so the retriever surfaces it later, to a different user, on a different query.
- Indirect prompt injection: a retrieved document carries instructions the model treats with the same authority as its system prompt, because nothing marked it as untrusted.
- Cross-tenant leakage: a shared vector index returns another tenant's documents because the access-control filter meant to separate them is missing or incomplete.
OWASP's Top 10 for LLM Applications gives the first of these its own category, LLM08:2025 Vector and Embedding Weaknesses, distinct from prompt injection (LLM01:2025) and from training-time data poisoning (LLM04:2025). That split matters operationally: three failure modes, three different fixes. Treating RAG security as "prompt injection defense plus a vector database" misses two of the three.
Vector and Embedding Store Poisoning
If ingestion has no content vetting or provenance check, anyone who can get a document into the source corpus, a wiki edit, a support ticket, a scraped page, a resume upload, can shape what the retriever surfaces days or weeks later, to an unrelated user asking a related question. This attacks the retrieval corpus, not the model's weights, which is why retraining or fine-tuning does nothing to a poisoned index. The fix has to happen at ingestion: source allowlisting, content validation before embedding, and monitoring for clusters of near-duplicate documents engineered to dominate similarity search for a specific query, the embedding-space equivalent of keyword stuffing.
Indirect Prompt Injection via Retrieved Content
Direct prompt injection, OWASP's LLM01:2025, is a user typing "ignore previous instructions" into a chat box. Indirect prompt injection is the same payload arriving inside a document the pipeline fetched and handed to the model as background, not user input. A support article, an email thread, an uploaded PDF, a web page a tool call retrieved, can carry instructions in visible text, in metadata, or rendered so a human reader would never notice, and most implementations concatenate retrieved passages straight into the prompt with no delimiter an instruction-following model actually respects as a trust boundary.
The fix is architectural, not a bigger blocklist: tag retrieved content as data rather than instruction, and treat any imperative sentence inside a retrieved chunk as suspect by default, especially one asking the model to disclose something, call a tool, or change its own behavior.
Cross-Tenant Data Leakage in Shared Vector Indices
Multi-tenant RAG products commonly store every customer's embedded documents in one shared index for operational simplicity, then rely on a metadata filter applied at query time, tenant ID equals X, to keep tenants apart. That filter is application logic, not a property of the nearest-neighbor search itself. If it is missing on any code path, a background job, an admin tool, a newly added retrieval endpoint, the vector database will return another tenant's documents, because they are mathematically close in embedding space regardless of who owns them. A RAG pipeline with no per-document access-control tagging at ingest time will retrieve and surface any document in the index regardless of the querying user's actual permissions. This is an access-control failure wearing a machine-learning costume, and it needs the same rigor as row-level security in a multi-tenant database: enforced at the query layer and tested the way anyone would test a broken-object-level-authorization bug, not assumed because the UI only shows the right tenant's data.
Tokenize Before You Index
One structural fix for the field-level-PII slice of this problem: keep raw sensitive values out of the embedding pipeline entirely. The Kinetic Gain Protocol Suite's vault contract pattern works this way for RAG specifically. rag-sentinel, the open-source reference implementation documented at suite.kineticgain.com/implementations/, sits between document ingestion and the vector store. It reads a Decision Card's data_vault_targets[] list, tokenizes the fields named there per the protection level the Card assigns, and only then lets the document proceed to embedding. The index ends up storing and searching over the token, not the raw value, so a compromised index, a misconfigured retrieval filter, or a successful cross-tenant leak surfaces a token instead of a Social Security number or an account detail.
Worth being precise about what this does and does not solve. It addresses field-level PII baked into embeddings, nothing more. It does not stop indirect prompt injection, tokenizing a phone number does nothing to a malicious instruction sitting in the same document, and it does not replace access-control filtering at retrieval time, a tokenized document can still be a cross-tenant leak, just a less damaging one. Tokenize-before-index is one control in a layered RAG security posture, not a substitute for the ingestion vetting and retrieval-time authorization the sections above cover.
None of this holds up without a record of what the pipeline actually did with a given document, see Tamper-Evident Audit Logs, and without a clear statement of what the retrieval system is authorized to fetch and surface in the first place, see AI Capability Declaration.