Guides › Secure RAG › Embedding inversion

Embedding Inversion: Can Vector Embeddings Be Reversed?

Hunter Moore, Founder and CTO · Updated August 4, 2026

Yes, to a substantial degree. Embeddings are not one-way hashes. Published research has recovered source text from embedding vectors alone, including exact reconstruction of short passages and personal names from clinical notes. A vector export should be treated closer to a text export than to a hash dump.

At a glance
  • Lossy is not one-way. Embeddings are trained to preserve the meaning that retrieval depends on, so the transformation is not irreversible.
  • Recovery can be exact. Published research recovered 92 percent of 32-token inputs exactly, and reconstructed full names from clinical notes.
  • Classify the index as source data. A vector store that can be inverted should inherit the source content's controls, retention and access review.

What does the research actually show?

Morris, Kuleshov, Shmatikov and Rush published Text Embeddings Reveal (Almost) As Much As Text at EMNLP 2023. They framed inversion as a controlled generation problem, iteratively refining a candidate text until its embedding matched the target.

92%of 32-token inputs recovered exactly
2023EMNLP paper reporting the result
28/2024EDPB opinion on model anonymity, adopted 17 December 2024

The headline result is that they recovered 92 percent of 32-token inputs exactly. Not approximately, exactly. On a clinical notes dataset they reconstructed full names along with other identifying content. Longer passages degrade, and even partial recovery of a longer chunk usually surfaces the sensitive part, because the sensitive part is what makes the text distinctive.

INVERSION, AS THE RESEARCH ACTUALLY PERFORMS IT Source text a chunk from your index Embedding model often a public API Vector what your store holds Attacker holds the vector guess a text, embed it, compare, refine, repeat 92% of 32-token inputs recovered exactly, not approximately Full names reconstructed from a clinical notes dataset, with surrounding detail Morris, Kuleshov, Shmatikov and Rush Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023 The attack assumes query access to the same embedding model, which is realistic when that model is a commercial API anyone can call.
Inversion is a search, not a decryption. Because embeddings are built to preserve meaning, a candidate text whose vector matches is usually the original text or very close to it.

Why do people assume embeddings are safe?

Because they look like hashes. An embedding is a fixed-length array of floats with no visible relationship to the input, so intuition says the transformation is lossy and one-way.

DimensionCryptographic hashText embedding
OutputFixed-length digestFixed-length array of floats
Preserves meaningNoYes, by design, because similarity search depends on it
LossyYesYes
Source text recoverableNoYes, to a substantial degree

It is lossy, and that is not the same as one-way. Embeddings are engineered to preserve semantic content, since that is what makes similarity search work. Preserving meaning and discarding meaning are opposing goals, and the model was optimized for the first. Anything that encodes enough meaning to retrieve accurately encodes enough meaning to reconstruct approximately.

A vector export should be treated closer to a text export than to a hash dump.

What does this change in practice?

Mainly the classification of your vector store. If embeddings can be inverted, the index is a copy of the source content rather than a derived artifact at lower sensitivity, and it should inherit the source's controls, retention and access review rather than being treated as infrastructure.

Three consequences

A vector export in a backup, a debug dump or an analytics pipeline carries roughly the disclosure risk of the underlying text. Third-party embedding providers receive your content in a form that is not meaningfully obscured. And deletion obligations reach the index, because if a vector reconstructs personal data then deleting the source document while leaving the embedding does not complete the request.

Can you encrypt embeddings to fix it?

Not while still searching them. Similarity search requires comparing vectors in their native space, which means they have to be decrypted at query time. Schemes that operate over encrypted vectors exist in research but are not practical at production latency and scale.

Encrypt at rest anyway for the same reasons you encrypt anything else, and do not record it as mitigating inversion, because the attack assumes access to usable vectors.

WHAT CHANGES WHEN THE INDEX IS CLASSED AS A COPY OF THE CONTENT Dimension Treated as infrastructure Treated as a copy of the content Access review Whoever operates the database. Reviewed on the source document's cycle, by its owner. Retention Kept as long as the service runs. Expires on the source data's clock. Deletion Reindexed eventually, if at all. Propagated from source to index, and verified. Third-party sharing An embedding API call is a technical detail. A processor receiving the content, handled contractually. The mitigation that addresses the mechanism is to reduce what the vectors encode, before they are created. Everything in the right-hand column governs the access path. Only ingestion transformation changes what a recovered vector is worth.
Reclassifying the index is a governance change with concrete consequences. It does not reduce what a vector encodes, which is why it belongs alongside ingestion work rather than instead of it.

What actually reduces the exposure?

Reduce what the vectors encode. If sensitive values are transformed before text is embedded, the embedding cannot encode what is no longer in the input, and inversion recovers the transformed version. This is the only mitigation that addresses the mechanism rather than the access path.

Reduce what the vectors encode

addresses the mechanism

  • Transform sensitive values before the text is embedded.
  • The embedding cannot encode what is no longer in the input.
  • Inversion then recovers the transformed version.

Treat the index as source data

addresses the access path

  • Access limited to the retrieval service, with no shared credentials.
  • Audit logging on queries.
  • Deletion propagation from source to index.
  • Vector exports handled under the same rules as document exports.
  • Covered further in vector database security.

Frequently asked questions

Does inversion need access to the embedding model?

The strongest attacks assume query access to the same embedding model, which is a realistic assumption when that model is a commercial API anyone can call. Attacks are weaker without it, and the practical posture is to assume an attacker who holds your vectors can also call the model that produced them.

Are longer chunks safer?

Somewhat. Exact reconstruction degrades as length grows, and partial reconstruction of a long chunk still tends to surface the distinctive content, which is usually the sensitive content. Chunk length is a weak control, not a real one.

Does this affect GDPR obligations?

It bears on them. If an embedding can be inverted to recover personal data, it is difficult to argue the vector is anonymous. The EDPB's Opinion 28/2024, adopted December 17, 2024, took a comparable position on model weights, holding that a model trained on personal data cannot automatically be treated as anonymous and requiring case-by-case assessment.

Should we stop using third-party embedding APIs?

Not necessarily, but assess them as processors receiving your content rather than as a mathematical transformation. The relevant questions are contractual and about retention, not about whether the vector obscures the text, because it does not obscure it as much as the format suggests.

Sources

Morris, Kuleshov, Shmatikov and Rush, Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023. · European Data Protection Board, Opinion 28/2024, adopted 17 December 2024.