Embedding & Vector Security
How embeddings create a hidden attack surface in AI systems: vector database security boundaries, embedding-level attacks, and RAG retrieval manipulation.
Embeddings are the foundation of modern AI systems' ability to search, retrieve, and reason about information. Every RAG (Retrieval-Augmented Generation) pipeline, every semantic search system, and every AI-powered recommendation engine relies on embeddings to convert text, images, and other data into numerical vectors that can be compared and searched. This ubiquity makes embedding and vector infrastructure a critical attack surface that is frequently overlooked in security assessments.
Why Embeddings Are a Security Concern
Embeddings appear to be simple numerical vectors — lists of floating-point numbers with no obvious semantic content. This apparent opacity creates a false sense of security. In reality, embeddings encode rich semantic information about the data they represent, and this information can be extracted, manipulated, and exploited.
The Information Paradox
Embeddings are designed to capture semantic meaning: two texts with similar meaning should have similar embeddings. This property is what makes semantic search work. But it also means that embeddings contain enough information about the original text to enable reconstruction attacks. Research has demonstrated that embedding vectors can be inverted to recover significant portions of the original input text.
This creates a paradox: the more useful an embedding is for retrieval (the more semantic information it captures), the more information it leaks about the original content. Organizations that store embeddings of sensitive documents are, in effect, storing a compressed but recoverable version of those documents.
The Hidden Data Flow
In a typical RAG system, data flows through several stages:
Source Documents → Chunking → Embedding Model → Vector Database → Retrieval → LLM
↑ ↑ ↑ ↑ ↑
Sensitive Boundary Transform Storage Selection
Data Decisions to Vectors of Vectors & Ranking
Security controls are typically applied at the source document level (access control) and the LLM output level (content filtering). The intermediate stages — chunking, embedding, vector storage, and retrieval — often lack equivalent security controls. This gap allows attacks that operate at the embedding and vector level to bypass controls at both ends.
The Attack Taxonomy
This section organizes embedding and vector security threats into three categories.
Vector Database Security
Vector databases (Pinecone, Weaviate, Chroma, Milvus, Qdrant) are the storage layer for embeddings. They present a new type of database security challenge because their query model — similarity search — is fundamentally different from traditional SQL or document queries. Attacks in this category target access control, injection, and data exfiltration at the database level.
Key concerns include:
- Access control gaps — API key management, tenant isolation, and namespace security in vector databases
- Injection attacks — Embedding poisoning, metadata injection, and similarity search manipulation
- Data exfiltration — Embedding inversion to reconstruct stored documents, enumeration attacks, and similarity-based data harvesting
For detailed coverage, see the Vector Database Security subsection.
Embedding-Level Attacks
Attacks at the embedding level target the vectors themselves rather than the database that stores them. These attacks exploit the mathematical properties of embedding spaces to craft adversarial inputs, recover original content, or infer membership in training sets.
Key attack types include:
- Adversarial embeddings — Crafting inputs that produce embeddings semantically close to target content but containing malicious payloads
- Inversion attacks — Reconstructing original text from embedding vectors, with significant privacy implications
- Membership inference — Determining whether specific data was included in the embedding model's training set
For detailed coverage, see the Embedding-Level Attacks subsection.
RAG Retrieval Security
RAG systems use embeddings to retrieve relevant context for language model generation. Attacks on the retrieval pipeline can manipulate what information reaches the model, influencing its output without directly injecting prompts.
Key attack types include:
- Retrieval manipulation — Poisoning chunks to rank higher in similarity search, exploiting chunking boundaries, and cross-document injection
- Citation attacks — Fabricating sources, causing citation confusion, and manipulating how the model attributes information
For detailed coverage, see the RAG Retrieval Security subsection.
Embeddings as a Trust Boundary
A critical concept for security practitioners is that the embedding layer represents a trust boundary. Data that passes through an embedding model undergoes a one-way transformation that strips most security-relevant metadata:
- Access control labels are lost. A document that is classified "confidential" produces an embedding that has no access control label. The vector database may or may not enforce access control on that embedding.
- Provenance is obscured. Once a document is chunked and embedded, there is no cryptographic link between the embedding and its source document. An attacker who poisons the vector database can introduce embeddings that appear to come from legitimate sources.
- Content is transformed. The embedding does not contain the original text, which means content-based security controls (regex filters, keyword blocklists) cannot be applied to stored embeddings.
This trust boundary is where many security controls fail. An organization may have robust access controls on their document management system but no access controls on the vector database that stores embeddings of those documents. The embedding pipeline becomes a privilege escalation path: an attacker with access to the vector database can access the semantic content of documents they cannot access directly.
Common Architectural Patterns and Their Risks
Shared Vector Database
Many organizations use a single vector database for multiple applications or tenants. Without proper namespace isolation, queries from one application can return embeddings from another, creating cross-tenant data leakage.
Unencrypted Embedding Storage
Embeddings are rarely encrypted at rest because encryption would prevent similarity search operations. This means that anyone with access to the vector database's underlying storage can access all embeddings.
Embedding Model as a Service
When organizations use third-party embedding APIs (OpenAI, Cohere, Voyage AI), they send their source text to an external service for embedding. This creates data exposure similar to sending data to a language model API, but organizations often apply less scrutiny to embedding API calls.
Client-Side Embedding Generation
Some architectures generate embeddings on the client side to reduce API calls. This means the embedding model weights are distributed to clients, enabling model theft and adversarial embedding generation.
Assessment Methodology
When assessing the embedding and vector security of an AI system:
- Map the embedding pipeline — Document every step from source data to vector storage to retrieval
- Identify trust boundaries — Where is access control enforced, and where does it break down?
- Assess vector database security — API keys, tenant isolation, network exposure, backup security
- Test embedding inversion — Can meaningful text be recovered from stored embeddings?
- Test retrieval manipulation — Can poisoned documents be made to rank higher than legitimate ones?
- Evaluate metadata security — Is sensitive information stored in vector metadata without access control?
- Check for data leakage — Can cross-tenant or cross-application queries access embeddings from other contexts?
Related Topics
- Foundations: Embeddings & Vector Systems — Technical foundations of embedding systems
- RAG, Data & Training Attacks — Broader RAG attack surface
- Prompt Injection & Jailbreaks — Injection attacks that complement retrieval manipulation
- Infrastructure & Supply Chain — Infrastructure security relevant to vector database deployment