Embedding Inversion Attacks
How attacks that reconstruct source text from embeddings stored in a vector database work, what recovery rates have actually been measured, and how far quantization and noise defenses go.
Embeddings were never designed to discard information, so a vector store breach has to be treated at the same severity as a plaintext breach.
The assumption that a vector store is a safe derivative
One deployment pattern shows up again and again when teams add retrieval-augmented generation (RAG). Source documents stay in an internal store, and only the embedding vectors go out to a managed external vector database. The reasoning behind it is that an embedding is an array of floating point numbers no human can read, so it counts as a de-identified derivative.
That reasoning treats hashes and embeddings as the same kind of object. A cryptographic hash is designed to throw input information away on purpose. An embedding model is trained so that sentences close in meaning land close together in vector space. Retrieval only works if the meaning of the input survives in the vector, and whatever survives is the raw material for reconstruction.
The capacity math leaves room as well. Widely used sentence embeddings are floating point vectors with hundreds to thousands of dimensions. The information a single short sentence carries is smaller than what such a vector can hold. What blocks reconstruction is not missing information but the difficulty of finding the inverse function.
That difficulty has been falling since 2023. The assumptions an attacker needs keep weakening, recovery accuracy keeps rising, and the cost of reconstructing one sentence keeps dropping. At this point, storing embeddings in an external vector database is close to storing weakened plaintext.
Three routes from an embedding back to text
Embedding inversion takes an embedding vector as input and reconstructs the source text. The methods published so far split into three families, distinguished by which problem they convert reconstruction into.
- Generative injection. GEIA (arXiv 2305.03010, EMNLP 2023) pushes a sentence embedding into the hidden representation slot of the first token in a pretrained decoder language model and lets it generate freely. The attacker needs only (text, embedding) training pairs and query access to the encoder.
- Iterative refinement. Vec2Text (Morris et al., arXiv 2310.06816) re-embeds a candidate sentence and uses the gap against the target vector to correct that candidate. It requires the ability to keep issuing round-trip queries to the encoder.
- Adversarial decoding. ZSinvert (arXiv 2504.00147) replaces the scoring function of beam search, swapping language model probability for cosine similarity to the target embedding. No attack model has to be trained per encoder.
The practical difference between the three is the cost of preparing an attack. GEIA and Vec2Text require a freshly trained attack model for each encoder, so preparation restarts whenever the target changes. ZSinvert reuses a correction model trained once on synthetic data and never touches the target encoder. On an A40 GPU, nine iterations at ten seconds each finish one reconstruction in roughly 90 seconds (arXiv 2504.00147).
Zero2Text (arXiv 2602.01757) strips away the domain assumption on top of that. Instead of training on a static dataset, a language model generates candidates on every iteration. Ridge regression analyzes the gap between the candidate embedding and the target embedding, and injects a correction signal into the prompt for the next iteration. It works without in-domain training pairs, which breaks the assumption that a specialized data domain protects you.
How far recovery rates have actually gone
Each metric means something different. F1 measures how many source tokens were recovered, and the Named Entity Recovery Rate (NERR) measures how many named entities were recovered. BLEU measures n-gram overlap, so it sits closer to string-level identity, while cosine similarity measures proximity in embedding space.
| Attack | Target encoder and data | Recovery metric | Source |
|---|---|---|---|
| GEIA | SimCSE-BERT / PersonaChat | Token F1 63.11%, entity recovery 55.57% | arXiv 2305.03010 |
| GEIA reproduction | SimCSE-BERT / PersonaChat | Token F1 63.22%, entity recovery 51.00% | arXiv 2504.16609 |
| Vec2Text | GTR-NQ, 32 tokens, in-domain | BLEU 98.5, cosine 0.99 | arXiv 2507.07700 |
| Vec2Text | OpenAI embeddings / MS MARCO, 81 tokens | BLEU 54.3, cosine 0.99 | arXiv 2507.07700 |
| ZSinvert | Contriever, GTE, GTR / MS MARCO | Token F1 50-60%, cosine 80-94% | arXiv 2504.00147 |
| Zero2Text | text-embedding-3 / MS MARCO | 1.8x ROUGE-L and 6.4x BLEU-2 over baseline | arXiv 2602.01757 |
The GEIA numbers held up under reproduction. In the SIGIR 2025 reproduction study (arXiv 2504.16609), F1 on SRoBERTa came out at 52.78% against the original 53.24%. On SimCSE-BERT it came out at 63.22% against 63.11%. Only entity recovery landed somewhat lower, and the conclusion did not change.
The Vec2Text reproduction study (arXiv 2507.07700) settled the conditions under which verbatim reconstruction holds. In the GTR-NQ 32-token regime, plain decoding stopped at BLEU 34.4, but adding 50 refinement steps and sequence-level beam search pushed it to BLEU 98.5. That value amounts to string-level identity. Performance collapses outside the training sequence length, however: a model trained at 128 tokens falls apart on 32-token inputs.
Results survive even when the target string carries no meaning. The same study exactly reconstructed 36% of easy passwords, 22% of medium ones, and 4% of hard ones from the Password Strength dataset. If user input was embedded and indexed as-is, fragments of tokens or keys can come back out of the vectors.
A low token overlap does not mean safety either. ZSinvert reached only 21.60% token F1 on Enron emails, yet the information leakage rate judged by GPT-4 was 92%. The surface strings differed, but who said what to whom came back almost intact. Judging a defense by BLEU reduction alone misses the real exposure.
Attacks that grow stronger as assumptions weaken
Every attack above assumed the ability to query the encoder. Real breaches unfold differently. A database dump or a stolen backup hands over the embeddings alone, and access to the encoder is more often absent than present.
Transferable Embedding Inversion (arXiv 2406.10280) operates under exactly that condition. The attacker attaches an MLP adapter to an encoder of their own and trains a surrogate model with two losses. One loss minimizes the error between the surrogate embedding and the leaked embedding for the same sentence. The other preserves the similarity relationships between pairs of sentences. Once the surrogate imitates the victim encoder, standard inversion techniques apply unchanged.
Measurements on clinical records show the size of the risk. With 4,000 leaked MIMIC-III documents, age was inferred at 98.84% accuracy and sex at 99.47%. Disease reached 79.07%, symptoms 79.45%, and medical history 65.36%, so most clinical attributes were recovered as well. A patient profile gets rebuilt from embeddings alone, without a single line of source text.
Embedding inversion targets something different from model inversion. Model inversion recovers the data used in training from parameters or outputs. Embedding inversion recovers the input from the encoder output representation, so its target is the operational data indexed right now rather than the training set.
The two attacks do meet at one point. The reproduction study cited above observed a log-likelihood gap of up to 28.17% between original and modified sentences for the GLM-4 and SRoBERTa combination. The same attacker infrastructure therefore yields a membership signal in addition to reconstruction.
| Scenario | What the attacker holds | Recovery level | Representative work |
|---|---|---|---|
| Vector DB breach | Embeddings only, no model or keys | Sensitive attribute inference up to 99% | Transferable |
| Encoder queries available | Query access, no weights | Token F1 50-60% with no training | ZSinvert |
| Domain mismatch | Out-of-domain data only | 1.8x ROUGE-L over baseline | Zero2Text |
| Encoder round trips available | Repeated query access | String-level recovery inside the training length | Vec2Text |
Weaker assumptions ought to imply weaker attacks, but the measurements point the other way. The line at which a setup counts as safe has moved toward the weaker side every year.
Where defenses hold and where they do not
Every defense trades against retrieval quality. The items with published measurements are as follows.
| Defense | Effect on the attack | Retrieval quality cost | Source |
|---|---|---|---|
| 8-bit quantization | BLEU 35-63 down to 16-27 | nDCG@10 within 1% | arXiv 2507.07700 |
| Noise at sigma 0.01 | Works on iterative refinement, marginal on adversarial decoding | Nearly none | arXiv 2507.07700, 2504.00147 |
| Noise at sigma 0.1 | Attack neutralized | Retrieval itself breaks | arXiv 2504.00147 |
| Differential privacy | Ineffective against adaptive attacks | Large | arXiv 2602.01757 |
| Avoid storing embeddings | Complete | RAG becomes impossible | — |
The clearest win per unit of cost is 8-bit quantization. The Vec2Text reproduction study cut BLEU from 35-63 down to 16-27 across five datasets while keeping the nDCG@10 change within 1%. Storage cost drops along with it, which keeps the barrier to adoption low. It belongs as the default step before embeddings are written.
Gaussian noise is where the two papers disagree. The Vec2Text reproduction study reports that BLEU drops sharply at sigma 0.01 while retrieval quality holds. ZSinvert reports that the attack is barely neutralized at the same sigma 0.01. The difference comes from the attack method. Iterative refinement is thrown off by noise, while adversarial decoding, which searches directly on cosine similarity, is thrown off far less.
Raising the noise to sigma 0.1 blocks the attack but breaks retrieval itself. Noise alone therefore does not cross the frontier between utility and privacy. Zero2Text states explicitly that differential privacy also fails against adaptive attacks. The attack recomputes its correction signal on every iteration, so it routes around fixed noise.
What remains is access control. Raise permissions on the embedding store to the same tier as the source database, and encrypt backups at the same level. Keep separate permissions on the mapping table that links embeddings to source text, so a leak of vectors alone does not extend into source lookups.
Using an external embedding API moves the defense boundary one step earlier. Source text travels to the vendor server in plaintext, so exposure happens at the transmission stage before any vector protection applies. Pinning no-training and zero-retention terms in the contract, or hosting the encoder on internal inference infrastructure, sits closer to the root of the problem.
Operational checklist
Storage placement follows from data classification.
| Data class | Vector storage location | Additional processing |
|---|---|---|
| Public | Managed vector DB allowed | None |
| Internal | Managed vector DB allowed | 8-bit quantization, short-lived access tokens |
| Confidential | Self-hosted inside the VPC | Quantization plus small noise |
| Restricted (PII, health, finance) | Self-hosted only | Noise and paraphrase preprocessing, avoid storing embeddings where possible |
- Make 8-bit quantization the default when embeddings are written.
- Enable noise at sigma 0.005 to 0.01 only after measuring the retrieval quality impact.
- Never ship embeddings of restricted-class data to an external vector database.
- Encrypt embedding backups through a key management service.
- Include embeddings in the breach notification trigger policy (PIPA Article 34, GDPR Article 33).
- Put separate permissions on the table that maps embeddings to source text.
- Run ZSinvert or Vec2Text against your own data periodically as a regression test.
The last item is the one teams skip most often. Defense settings get silently neutralized by an encoder swap or a change in the indexing pipeline. Measuring recovery metrics on your own data on a schedule turns that drift into a number you can see.
Summary
An embedding is a representation trained to preserve meaning, so it carries the raw material for reconstructing the source text. After GEIA demonstrated sentence generation in 2023, the Vec2Text reproduction study confirmed string-level recovery at BLEU 98.5 inside the training sequence length. ZSinvert and Zero2Text removed both per-encoder training and the domain assumption, bringing the cost down to roughly 90 seconds per sentence.
An attacker holding leaked embeddings alone still inferred age and sex on MIMIC-III at close to 99% accuracy. On the defense side, 8-bit quantization is the only measure with a confirmed cost-benefit case, while noise and differential privacy waver in front of adaptive attacks. Classifying the embedding store at the same tier as the source data and separating permissions on the mapping table is the defense that reliably remains.