Do all embedding models produce vectors that are equally invertible?

Invertibility is not uniform across models. It depends on the embedding model's architecture, dimensionality, and training objective, and research in this area is still developing a general theory of which properties predict inversion risk. The vec2text results were demonstrated against widely used embedding models similar to those many production RAG systems rely on, which is why the finding generalizes as a risk to plan around rather than a narrow edge case affecting one specific model.

Does encrypting the vector store solve the inversion problem?

Encryption at rest protects a vector store from an attacker who lacks decryption keys, which is a real and necessary control. It does nothing against an attacker who has legitimate or compromised access to the decrypted vectors, including an insider, a misconfigured access policy, or a compromised service account with normal read permissions. Encryption addresses one threat model. Embedding inversion is a different threat model that starts from the assumption the attacker can already read the vectors.

Should we stop storing embeddings and re-embed on every query instead?

Re-embedding on every query eliminates the at-rest exposure of a stored vector index, at the cost of the latency and compute that storing embeddings was meant to save, which is a real tradeoff for high-volume retrieval systems. For a smaller number of highly sensitive documents, that tradeoff can be worth making. For most production RAG deployments, the more practical answer is treating the vector store's access control as equivalent to the source document's access control, rather than eliminating storage entirely.

How does embedding leakage relate to the risk of sensitive data ending up in a prompt?

They are adjacent but distinct. Sensitive data in a prompt is exposed the moment the prompt is sent and potentially logged or retained by whatever is downstream of the call. Embedding leakage is a delayed-fuse version of the same underlying problem: the sensitive data is not exposed at the moment of embedding, but a recoverable trace of it is written to storage that may be accessed, copied, or breached long after the original request is forgotten. A data classification policy that only inspects prompts and ignores what gets embedded and stored is covering the immediate exposure and missing the deferred one.

Embedding Leakage: A 2023 Paper Recovered 92% of Text From Its Own Vectors

A 2023 paper out of Cornell, "Text Embeddings Reveal (Almost) As Much As Text," introduced a method called vec2text that treats embedding inversion as a controlled generation problem: generate text that, when re-embedded, lands close to a target vector. Iterating that process recovered 92% of 32-token inputs exactly, from the embedding alone, with no access to the original text. Applied to a dataset of clinical notes, the method recovered patient names. A 2025 reproducibility study confirmed the finding holds up under closer scrutiny. The vector was supposed to be a lossy, one-way summary. It turned out to encode most of what it summarized.

TL;DR

Embedding vectors are widely treated as anonymized or one-way, and 2023 research showed that assumption does not hold for many embedding models.
The vec2text method recovered 92% of short text inputs exactly, and personal names from a clinical dataset, using only the embeddings.
Any system storing embeddings, including most retrieval-augmented generation pipelines, is storing something recoverable close to the source text.
Access control on a vector store needs to match the sensitivity of the source data, not the sensitivity assumed for a "just numbers" vector.

The assumption embedding-based systems quietly make

Retrieval-augmented generation, semantic search, and recommendation systems all convert text into embeddings and store the vectors, often instead of storing the original text, on the reasoning that a vector is a compressed numerical representation rather than the data itself. That reasoning shows up in how vector stores get access-controlled: teams that would never leave a database of raw customer records openly readable will sometimes leave the corresponding vector index far more permissive, because the vectors do not look like the data.

OWASP's Vector and Embedding Weaknesses category exists specifically because that assumption fails in practice. A high-dimensional embedding produced by a well-trained model preserves enough structure about its input that, given the right inversion technique, the input is substantially recoverable. The vec2text result is the clearest demonstration: 92% exact recovery is not a partial leak or a probabilistic hint. It is most of the original text, back.

Why this differs from a database breach

An attacker who breaches a database of raw text gets the text directly. An attacker who gains read access to a vector store, without breaching anything else, has to run an inversion technique before they have the text, which sounds like a meaningful barrier. In practice, the barrier is lower than it looks. Vec2text and comparable methods are published, reproducible, and do not require access to the model that produced the embeddings, only the embeddings themselves and a broadly similar model to invert against. The compute cost is real but not prohibitive for a motivated attacker targeting a specific, valuable dataset.

The practical consequence is that a vector store containing embeddings of sensitive documents, support tickets, clinical notes, contract text, deserves access controls close to what the source documents would require, not the lighter controls a "just numbers" mental model tends to produce. Teams that classify their document store as sensitive and their vector index as low-sensitivity have drawn the line in the wrong place, which is the same blind spot covered in RAG security architecture more broadly.

Where this sits relative to the HTTP boundary

Embedding leakage through vector store inversion happens after the embedding has already been generated and written to storage. The inversion attack itself, an attacker running vec2text against exfiltrated or improperly accessed vectors, happens entirely outside any HTTP traffic to an LLM or embedding API. Nothing about that stage is visible to a policy gateway sitting on the request path, and access control for a vector database is a data infrastructure decision that belongs to whoever owns that store, not to an AI traffic control layer.

What does sit inside the HTTP boundary is the call that creates the embedding in the first place: an application sending text to an embedding API, over HTTP, to get a vector back. That call is AI traffic like any other, and it is the one moment identity-aware policy can evaluate what is being embedded and by whom, before the resulting vector exists anywhere to be stolen.

The narrow control that actually applies

Enforcing policy at the embedding-generation call does not protect a vector store from an inversion attack once vectors are written and access-controlled elsewhere. It does two things a downstream access-control review cannot: it evaluates whether a given identity should be generating embeddings of a given data classification at all, and it produces a per-decision record of exactly what content was sent to be embedded, which is the evidence an investigation needs if a downstream vector store is later found to be over-exposed.

Those two things matter because embedding pipelines are frequently the least-reviewed step in a RAG deployment. Teams review model access carefully and database access carefully. The embedding call in between, often treated as plumbing rather than a data-handling event, gets less scrutiny than either endpoint it connects, the same review gap legacy DLP misses on AI traffic generally.

DeepInspect

DeepInspect sits inline between authenticated callers and any HTTP-based model endpoint, including embedding APIs, evaluating every request against identity, role, and data classification before it reaches the model. For embedding pipelines specifically, that means a policy decision on what is being embedded and by whom, at the one point in the pipeline where the data still exists as text rather than as a vector already at rest somewhere.

DeepInspect does not secure a vector database once vectors are written, and does not detect an inversion attack run against an already-exfiltrated vector store, the same distinction drawn in how data actually leaves through LLM traffic. That work belongs to whoever owns the vector infrastructure, with access controls sized to the sensitivity of what those vectors actually reconstruct to. If your embedding pipeline has never been classified as a sensitive-data pathway in its own right, the first step is finding out what is actually recoverable from what you are already storing. Book a demo today.