Storing only the embeddings feels like storing a hash — a one-way projection, safe to treat as opaque. It is not: text embeddings invert back to the original text at high fidelity, and the newest attacks need no access to the model that produced them.
A team builds semantic search over a corpus it should be careful with — support tickets, internal correspondence, a decade of records that name real people. They are careful with it. The source documents stay in the primary datastore, access-controlled, encrypted, audited. What goes into the vector database is only embeddings: each document run through an encoder and written out as a few hundred floating-point numbers. The reasoning is the kind that passes a design review without a second look — the vector store contains no text, only opaque numeric arrays, so a breach of it exposes no documents. The embedding is treated, in every later conversation about the system, as a one-way projection. A hash, more or less.
It is not a hash. Nothing about it is a hash. A party who obtains a copy of that vector store — a leaked backup, a misconfigured index, a subprocessor doing exactly what its contract allows — does not hold opaque numeric arrays. They hold the documents, in a lightly encoded form, recoverable to a faithful copy with published tooling and a few hours on a GPU. The embedding was never a one-way door. It was the document, written in a different alphabet.
This post is about why a vector database is, for every purpose that privacy cares about, a store of the text that went into it — why embedding inversion works, how far it now reaches, and what, short of not storing the embeddings, actually narrows the exposure.
The mistake is a category error, and it is worth naming precisely, because it feels so much like common sense.
A cryptographic hash is built to destroy information. Irreversibility is not a quality of a hash; it is the definition of one — the output is fixed-width, the input is not, and the mapping is engineered so the input cannot be recovered from the output. That is the entire job.
An embedding is built to do the opposite. It is engineered to preserve information — specifically, to preserve enough of the meaning of the input that two inputs which mean similar things land near each other in the vector space. That preservation is not a side effect of embedding; it is the function of embedding. Semantic search works at all only because the geometry carries the meaning faithfully enough to rank by.
Hold those two facts next to each other and the conclusion is immediate. A representation that carries enough meaning to rank a million documents by their relevance to a query carries enough meaning to reconstruct a document. You do not get the first property without the second, because they are the same property read from two directions. Retrievability is recoverability. An embedding informative enough to be worth storing is an embedding informative enough to invert — and the more useful your embeddings are for search, the more faithfully they give the text back.
Embedding inversion is not an attack in the sense of an exploit. There is no malformed input, no overflow, no leaked key. It is a model trained to run the encoder backwards.
The encoder you deployed maps text to a vector. An inversion model is trained to map a vector back to text — feed it embeddings paired with their source text and it learns the inverse. A single forward pass through such a model produces an approximation: text that is close to the original, in the right neighborhood, often wrong in the details.
The method that turned “close” into “near-exact” — introduced in Text Embeddings Reveal (Almost) As Much As Text (arXiv 2310.06816) — wraps that approximation in a correction loop. Generate a candidate text. Re-embed it with the target encoder, the same model that produced the embedding under attack. Compare the candidate’s embedding to the target. Adjust, regenerate, re-embed, compare again. Each round pulls the candidate closer in vector space, and because closeness in vector space is — by the encoder’s own design — closeness in meaning, each round pulls the candidate closer in text. The attacker is hill-climbing toward the original document, and the encoder is the oracle telling them whether they are getting warmer. The paper measures the loop’s contribution directly: the correction steps raise exact reconstruction by a factor of two to six over a single pass.
Notice what the attacker needs and what they do not. They need the embeddings. They need query access to the encoder, or a local copy of it — for a popular open model, that is a download. They do not need the training data, the documents, or any privileged access to the system that produced the vectors. The vector store is the target; everything else is public.
The reason this is a post and not a caution is that the reconstruction quality has been measured, repeatedly, and the numbers do not leave much room.
The original vec2text result recovered 32-token text inputs at a BLEU score of 97.3 and reproduced 92% of them exactly — not approximately, not the gist, the same tokens. Held against a dataset that should focus the mind: on clinical notes from MIMIC-III, the same method recovered 94% of first names, 95% of last names, 89% of full names, and 26% of the documents verbatim. A vector store built over medical records is, on those numbers, a medical-record store.
A natural objection is that those embeddings were chosen to be invertible. Understanding and Mitigating the Threat of Vec2Text to Dense Retrieval Systems (arXiv 2402.12784) answers it by attacking the embeddings a production retrieval system would actually use. Against dense-retrieval encoders with standard mean-pooled embeddings, it reconstructed 57.9% of inputs exactly at 89.4 BLEU; against an encoder pre-trained with a bottleneck objective, 64.4% exactly at 94.4 BLEU. These are not adversarial toy encoders. They are the kind of model a team picks off a leaderboard.
And the result reproduces. Rethinking the Privacy of Text Embeddings (arXiv 2507.07700), an independent 2025 reproducibility study, re-ran the original attack and matched it — 98.5 BLEU and 94% exact recovery against the headline configuration. It also ran the attack against password-like strings and recovered 36 of 36 of the easy ones exactly. When the same number comes out of two labs that did not coordinate, it has stopped being a demonstration and become a property of the representation.
One honest scope note belongs here, because the version of this argument that overstates loses the reader who knows better. Reconstruction fidelity is highest for short text — the headline numbers are for inputs around 32 tokens — and it falls as the input gets longer; it is also higher in-domain than out-of-domain. None of that is comfort. A support ticket, a chat message, a name-and-address field, a password, a search query, a single clause of a contract — the units that carry the most concentrated personal information — are mostly short. The attack is most precise exactly where the data is most sensitive.
Up to this point a defender had one real structural comfort to hold on to. Every attack above needs the target encoder — the loop re-embeds candidates with the specific model that produced the vectors, and the inversion model is trained against that specific embedding space. If your encoder were private, or fine-tuned in-house, an attacker holding only the stored vectors would first have to obtain or replicate the encoder. A barrier. Not a tall one for an off-the-shelf model, but a real one for a custom space.
That barrier is what the 2025 work removed. Universal Zero-shot Embedding Inversion (arXiv 2504.00147) demonstrates an inversion method — ZSInvert — that needs no encoder-specific training at all. It is, in the authors’ framing, fast, query-efficient, and usable against any text embedding without first building a model for that embedding space. Across encoders it reconstructs text whose re-embedding lands at high cosine similarity to the target — 87.4 for one widely used retrieval encoder, 94.4 for another — and on a corpus of Enron emails an LLM judge scored the information leaked from the reconstructions at 82% to 92%.
Be precise about what ZSInvert recovers: the substance of the text — the entities, the facts, the meaning — rather than a guaranteed token-for-token copy. For a privacy threat model that distinction is close to irrelevant. The harm in a leaked support ticket is that it says who complained about what; the harm in a leaked record is the name and the fact attached to it. The substance is the leak. The one remaining comfort — “well, they would need our exact encoder” — is now an assumption a defender cannot make.
The reflex on reading the above is to encrypt the vector store at rest. Do that — it is hygiene — but be clear about what it buys. Encryption at rest defends against a stolen disk. It does nothing against the threats that actually move embeddings out of your control: a subprocessor that holds the index in the clear to operate it, an over-broad internal access grant, a backup copied to the wrong bucket, a query path that returns vectors. For all of those, the data is decrypted exactly where the inversion happens.
The control that changes the inversion math, rather than the storage math, is quantization. Inversion depends on the fine-grained precision of the stored vector — the correction loop is reading small distances. Quantize the embedding — store each dimension in 8 bits, or apply product quantization — and that precision is gone, while enough coarse structure survives to rank on. The numbers bear it out from both directions. The dense-retrieval study found that product quantization dropped exact reconstruction from the high-fifties percent to 0.0%, at 2.2 BLEU — effectively closing the attack. The reproducibility study found that 8-bit quantization cut reconstruction BLEU from 59.1 to 19.0 on one benchmark while retrieval quality, measured by nDCG@10, held essentially flat.
That is the genuinely useful finding in this literature for a team that has to ship: the privacy property and the storage-cost property point the same way. Quantization is already on the table as a way to shrink a vector index; it is also, and this is rarely said in the same sentence, the most practical single thing you can do to make that index hard to invert.
It is mitigation, not closure. Quantization raises the cost and lowers the fidelity of inversion; it does not make the embedding meaningless, because an embedding that still retrieves well still carries recoverable structure. The honest statement is the one the dense-retrieval paper makes: you are trading a measured amount of recoverability against a measured amount of retrieval quality, and that trade should be made on purpose, by someone who knows both numbers.
You cannot make a useful embedding uninvertible. You can stop treating the vector store as if it were already safe, and close the specific gaps that make it an easy target.
Classify the vector store as the source text. This is the decision everything else follows from. If the documents are confidential, the embeddings are confidential — same access controls, same audit logging, same encryption, same blast-radius accounting in an incident. A vector index over regulated data is regulated data, and “it’s only embeddings” is not a basis for a lighter touch.
Quantize, and write down that it is a privacy control. Product quantization or 8-bit storage materially degrades inversion at little retrieval cost. If quantization is already in your index for cost reasons, record that it is also load-bearing for privacy, so a later optimization pass does not quietly undo it.
Keep the sharpest content out of the index. The most concentrated identifiers — government IDs, credentials, exact account numbers — should not be embedded at all where that can be avoided. Redacting them before the encoder runs is the same discipline that PII redaction that does not wreck retrieval applies to the corpus, and it applies here for a blunt reason: what is not embedded cannot be inverted.
Remember the stored vectors are one leak, not the only one. Inversion attacks the embeddings at rest. The answer channel is a separate door — an adversary with only query access can reconstruct a corpus from the responses, which is the subject of your RAG corpus is extractable. A vector store can be hardened against inversion and still hand its contents out through retrieval. Both doors need a lock, and they are not the same lock.
Put inversion in the security test suite. Run vec2text-style reconstruction against your own index and measure the exact-match rate. An untested index has an unknown reconstruction rate, and the unknown rate is not zero. This is a measurement you can take in an afternoon and then track as the encoder and the index change.
Count the subprocessors. A managed vector-database vendor that holds your embeddings holds your text — that is now a sentence you can defend with citations. The data-processing agreement, the region, the encryption-in-use posture, and the deletion guarantees for that vendor govern the same data as the agreement covering your primary document store. Hold them to the same level.
Before you call a vector index safe to hold sensitive data:
An embedding reads like a hash to a person — both are arrays of numbers that mean nothing at a glance. But you are not the threat model, and the threat model is not reading at a glance. It has the inversion model, it has a few GPU-hours, and to it your vector database is not opaque at all. It is the documents, lightly encoded, waiting to be read back.
A membership-inference attack that separates your book from a held-out one is usually reading the calendar, not the weights. A successful attack is not a sound proof — and the null it would need to test against cannot be sampled.
17 min →
Unlearning promises a model can forget specific data without a full retrain. What it delivers is output suppression: a small benign relearning set — or simply quantizing the model — brings the 'forgotten' knowledge back.
14 min →
The EU AI Act requires AI output to be marked in a robust, reliable way. A formal impossibility theorem says strong watermarking cannot exist. Five words in the statute carry the collision.
13 min →