Embeddings and the Vector-Database Threat Model

Retrieval-augmented generation gets the attention, but the layer underneath it — the embeddings and the vector database that stores them — has a threat model of its own that survives even a perfectly scoped RAG pipeline. The core misconception to unlearn is that an embedding is a safe, anonymous fingerprint of text. It is closer to a compressed, reversible copy, sitting in a store that most teams never classified as sensitive.

What an embedding actually is

An embedding model maps a chunk of text to a vector — a few hundred to a few thousand numbers — positioned so that similar meanings land near each other. That geometry is what makes semantic search possible: embed a query, find the nearest stored vectors, return their text. The vector database exists to do that nearest-neighbour search at scale, which relational engines were never built for. So far, so useful.

The security-relevant fact is what the vector preserves. Because meaning is retained with high fidelity, the vector is not a one-way hash of the text — it is a lossy but reconstructable representation of it. Given a vector and access to a similar embedding model, researchers have repeatedly shown you can recover a close paraphrase, and often much of the literal content, of the original chunk. If the source text was a medical note or a customer record, the vector inherits that sensitivity.

The threats specific to this layer

These are distinct from the RAG-pipeline issues of retrieval scoping and prompt injection — they live in the embeddings and the store itself:

• Embedding inversion. An attacker who obtains vectors — through a leaky API, a misconfigured store, or a shared index — can reconstruct approximate source text. The vector database must be classified and protected at the sensitivity of its source data, not treated as opaque math.
• Membership inference. Even without full inversion, an attacker can often determine whether a specific document or person was in the index by probing similarity — a privacy leak in its own right.
• Index poisoning / retrieval magnets. An attacker who can add content crafts a chunk whose embedding sits near a broad range of queries, so it is retrieved constantly. Pair that with a hidden instruction and you have injection that fires on almost any question.
• Cross-tenant and cross-scope leakage. Similarity search does not know about your permissions. In a shared index without per-vector access metadata, one tenant's query can surface another tenant's chunks.

There is a compliance dimension here that catches teams off guard. If your source documents fall under a data-protection regime — personal data, health records, anything with a deletion or residency obligation — those obligations follow the meaning, not the file. A vector derived from a customer's record is still that customer's data for the purposes of a deletion request, and a right-to-be-forgotten operation that scrubs the document store but leaves the vectors intact has not actually erased anything recoverable. Few embedding pipelines were built with a delete path in mind, which is precisely why regulators and auditors have started asking about them.

Controls that fit the layer

• Classify the vector store as sensitive data. Encrypt at rest, lock down network access, and audit who and what can read vectors — the same posture you give the source.
• Attach access metadata to every vector and filter retrieval by the asking identity, so similarity never overrides authorization.
• Govern ingestion. Control who can add content to the index; a retrieval magnet needs a way in, and ingestion is it.
• Isolate tenants. Prefer separate indexes or enforced partition keys over a shared index with hopeful filtering.

Embeddings feel abstract, and that abstraction is exactly what lulls teams into under-protecting them. Treat the vector store as what it is — a searchable, reversible copy of your most useful text — and the controls become obvious. The catch, as ever, is coverage: you cannot classify or lock down a vector database nobody recorded standing up, so the first job is finding every embedding store your organisation is quietly running.