RAG widens the attack surface
A bare LLM has essentially one untrusted input: the user's prompt. A RAG system has many. Every document you ingest, every embedding you generate, every vector you store, and every retrieval you perform is now part of the path that produces an answer — and any of them can be a control point for an attacker. OWASP's 2025 list formalized this by adding LLM08: Vector and Embedding Weaknesses.
The practical consequence is that RAG security cannot be solved at the prompt layer alone. The data pipeline, the vector database, and the retrieval logic each need their own controls, because a compromise in any one of them flows directly into the model's context window.
Untrusted ingestion and indirect injection
The most common blind spot is treating the document corpus as trusted because "it's internal data." In practice, knowledge bases ingest content from wikis, ticketing systems, shared drives, scraped web pages, support emails, and user uploads — much of it attacker-influenceable. Indirect prompt injection exploits this: an adversary plants instructions inside a document, and when a legitimate user later asks a benign question, the retriever pulls that poisoned chunk into context.
Research on corpus poisoning shows attackers can inject a small number of optimized documents and force them into the top retrieval results with high probability. The model, which cannot reliably distinguish data from instructions, may follow them — overriding the system prompt, leaking other documents, or triggering tool actions. Defenses include treating all retrieved content as untrusted, separating instructions from data, constraining tool permissions, and provenance-checking ingested documents rather than trusting their source.
Multi-tenant isolation and cross-tenant leakage
When one RAG deployment serves many customers, the dangerous moment is retrieval time. If isolation is enforced only by a metadata filter appended in application code, a single bug or an injection that manipulates the filter can surface one tenant's confidential documents inside another tenant's answer — a silent breach with no obvious error.
The robust pattern is to make isolation structural rather than advisory: per-tenant namespaces or collections that act as hard partitions, or dedicated indexes for high-sensitivity tenants. Document-level authorization should be re-checked on every query, verifying the requesting user is entitled to each returned chunk before it enters the context, rather than assuming the index only contains data they may see.
Vector database exposure and access control
A vector database is a datastore holding a semantically searchable copy of your most sensitive content, yet it is frequently deployed with weaker controls than the primary database it mirrors. Common failures are unauthenticated or default-credential endpoints, management APIs exposed to the network, missing encryption, and overly broad API keys shared across services.
Because similarity search lets a holder of read access probe the corpus by meaning rather than by exact match, even partial access is high-value to an attacker. Treat the vector store as a tier-one data asset: enforce authentication and least-privilege RBAC, scope API keys narrowly, place it on private networking, encrypt data, and log queries so anomalous bulk retrieval is detectable.
Embedding inversion and data reconstruction
A persistent misconception is that embeddings are a safe, one-way, lossy representation — so teams store vectors without the same protections they'd give plaintext. They are not opaque. Embedding inversion attacks reconstruct meaningful portions of the original text from its vector; foundational work (Song and Raghunathan, 2020) recovered over half the input words, and 2024-2025 research has pushed this further, including transferable attacks.
The implication is blunt: if an attacker obtains read access to your vector store, that can constitute a plaintext breach of the underlying documents, not merely exposure of inscrutable numbers. Vectors derived from sensitive content therefore deserve the same confidentiality controls — encryption, access restriction, and isolation — as the source data itself.
Governance: deletion, retention, and PII
RAG quietly duplicates your data: the same record now lives in the source system, the embedding pipeline, the vector index, and often a cache. That breaks naive deletion and retention assumptions. A "right to be forgotten" deletion that only touches the source database leaves the corresponding vectors — which may still reconstruct the original PII — behind in the index indefinitely.
Governance must span the whole pipeline: propagate deletions to the vector store, track lineage from each chunk back to its source record, minimize or redact PII before it is embedded, and apply consistent retention windows across every copy. Without this, RAG becomes a shadow data store that silently undermines existing privacy and compliance commitments.
In a RAG pipeline, your retrieved documents, your vector store, and even your embeddings are all untrusted, attacker-reachable parts of the model's trust boundary — secure them like the sensitive data they actually are.