Vector and Embedding Weaknesses
- Memory / State
- Tools & External Data
The vector stores and embedding pipelines behind retrieval are exploited — poisoned embeddings, cross-tenant leakage in a shared index, or adversarial inputs that manipulate similarity search — to compromise a RAG pipeline.
What it is
Retrieval-augmented generation adds a vector-store attack surface distinct from the model itself: how embeddings are generated, stored, and retrieved can be exploited to leak sensitive content, poison what the model treats as ground truth, or manipulate similarity search into surfacing the wrong document. Retrieved content is typically treated as more trustworthy than open user input precisely because it came from a curated index, which is what makes weaknesses in that index dangerous — they bypass defenses built to scrutinize the prompt, not the retrieval step feeding it. A multi-agent system that shares one vector index across several agents or tenants multiplies both the poisoning surface (Data and Model Poisoning, LLM04) and the disclosure surface: anything one agent's ingestion pipeline embeds becomes retrievable by every other query against that index unless access is explicitly partitioned, so an unscoped shared store is the default path to both cross-tenant leakage and silent, system-wide poisoning.
Kinds
- Unauthorized access & leakage
- Inadequate access controls on the vector store let a query retrieve embeddings or source documents the requester should never see.
- Cross-tenant / cross-context leakage
- A vector index shared by multiple tenants or user classes lets one tenant's content surface in another's query results, with no logical partition between them.
- Embedding inversion
- An attacker reconstructs substantial source content from its embedding vector, defeating the assumption that an embedding is a safe, non-reversible representation of the underlying text.
- Poisoned or conflicting retrieval
- A maliciously seeded document is retrieved and treated as ground truth, or retrieved content simply contradicts what the model already learned in training, producing unpredictable output either way.
Attack scenarios
In a multi-tenant support system, one tenant's planted document ranks highly for another tenant's unrelated query, leaking cross-tenant content into the answer.
Hidden-text resume poisoning
An attacker submits a resume containing instructions hidden in white-on-white text; a RAG-based screening pipeline ingests it unfiltered, and later follows the hidden instruction when queried about the candidate.
Cross-tenant embedding leak
In a shared multi-tenant vector database, one tenant's planted or ordinary document ranks highly for another tenant's unrelated query, leaking cross-tenant business information into the answer.
Embedding inversion attack
An attacker recovers significant source content by inverting embedding vectors extracted or exposed by the retrieval system, compromising data the vector store was assumed to keep opaque.
Mitigations
- Permission-aware, partitioned stores
- Implement fine-grained access control and strict logical partitioning per tenant or agent in the vector database, per Semantic / Vector / Graph Memory — an unpartitioned shared index is the root cause of cross-tenant leakage.
- Validate before ingestion
- Run every document through a validation pipeline that screens for hidden or malicious content and accepts only trusted, verified sources before it enters the index — the Integrator's role for retrieval, not just tool results.
- Review and classify combined datasets
- When merging content from different sources, tag and classify it so access levels travel with the data rather than flattening into one undifferentiated pool.
- Monitor retrieval activity
- Keep immutable logs of what was retrieved and by whom, so a suspicious access pattern is detectable rather than invisible inside normal query traffic.