There is an assumption underneath nearly every enterprise retrieval deployment that has never been written into a design document, because nobody thought it needed defending: that turning text into an embedding is a one-way trip. Document goes in, a vector of floating-point numbers comes out, and the vector gets treated as a derived artefact rather than as the text — replicated across environments, shipped to third-party stores, held under controls the source document would never have been allowed to travel under. Vectors look like hashes. Security reviews wave them through on that resemblance.
The research has been answering this question since 2023, and the answer has held up through two independent reproductions, an extension to zero-shot conditions, and a 2026 result about what “deleted” means on disk. This is the complete case file: what each paper established, what the reproductions corrected in the original, what the defences genuinely buy, and what to do about a vector store that is already in production.
The short version, so you can decide whether to read the rest: an embedding is a lossy compression of the text, and the loss is not where you hoped it would be. What survives the compression is disproportionately the material that made the text sensitive in the first place.
The original result, read properly
Morris, Kuleshov, Shmatikov and Rush put the question directly in “Text Embeddings Reveal (Almost) As Much As Text” (EMNLP 2023). Given only an embedding and black-box access to the encoder, can you reconstruct the input?
Their method — vec2text — frames inversion as controlled generation rather than as decoding. A naïve model conditioned on the embedding does poorly, which is presumably why the field assumed the problem was hard. The move that works is iterative: generate a candidate text, embed the candidate, compare it to the target vector, correct the candidate in the direction that closes the gap, repeat. Each round is cheap. The correction signal is exactly the thing the embedding API hands you for free.
The headline number from the abstract, stated plainly: the multi-step method “is able to recover 92% of 32-token text inputs exactly.” Not approximately, not semantically — exactly, on a benchmark built from Natural Questions.
The clinical experiment is the one that should have ended the conversation about vectors as de-identification. Running against embedded clinical notes from MIMIC, with names present, the method recovered 94.2 percent of first names, 95.3 percent of last names, and 89 percent of full names, alongside 26 percent of documents matched exactly. Read that sequence carefully, because the ordering is the finding: the individual name components come back at higher rates than whole documents do. The compression discards structure and prose and preserves the tokens that carry the most distinguishing information, which in a clinical note is the name, the number, and the condition.
The authors’ own conclusion is unusually direct for a research paper, and it is the sentence I would put in front of a security architecture review: embeddings “should be treated as highly sensitive private data and protected” in the same way one would protect the raw text.
That is a design instruction, not a caveat.
The reproduction that criticised the original — and landed at ninety percent anyway
This is the part of the literature most summaries skip, and it is the part that makes the result trustworthy rather than merely alarming.
Zhuang, Koopman, Chu and Zuccon set out to understand vec2text as a threat to dense retrieval systems (SIGIR-AP 2024). In reproducing it they found two methodological problems in the original evaluation, and they are real problems, not quibbles.
First, data contamination: “We found that 50.7% of validation data points also appear in the training dataset.” Half the benchmark on which 92 percent exact recovery was measured had been seen during training. Second, an embedding bug: the original work “inadvertently used the last hidden layer outputs of the GTR-base model as the final text embeddings” rather than the output of the dense pooling layer that GTR-base actually applies. The inversion was therefore being run against a richer representation than the one a real deployment stores.
Either finding, alone, is the kind of thing that deflates a headline number. So here is what happened when they fixed both. On the filtered validation set — contamination removed — with the pooling bug corrected, exact-match recovery came in at 90.1 percent. Their reproduction without the bug fix reached 89.0 percent on the same filtered set; the original authors’ released checkpoint reached 92.2 percent.
The strongest available critique of the original paper removed the inflation and the number moved from 92 to 90.
I want to be precise about why this matters for a practitioner rather than for a reviewer. When a striking result survives its most rigorous replication essentially intact, the correct operational response is to stop treating it as a research curiosity awaiting confirmation and start treating it as a property of the technology. The confirmation has happened. It happened adversarially, by people trying to find the flaw, and they found two flaws that did not change the conclusion.
The second reproduction, and the passwords
A second independent reproduction ran at RecSys 2025: Seputis, Li, Langerak and Mihailov, “Rethinking the Privacy of Text Embeddings: A Reproducibility Study of ‘Text Embeddings Reveal (Almost) As Much As Text’.” They report successfully replicating the original key results in both in-domain and out-of-domain settings, “with only minor discrepancies arising due to missing artifacts, such as model checkpoints and dataset splits.”
Their extension is the interesting part. They tested whether vec2text could reconstruct inputs that carry no semantic structure for a language model to exploit — the intuition being that inversion works because embeddings encode meaning, so a string with no meaning should be safe. It is not. The paper finds the method “capable of reconstructing even password-like sequences that lack clear semantics.”
That result closes a defence that sounds plausible in a threat-modelling session. Nobody deliberately embeds passwords, but plenty of systems embed documents containing account identifiers, policy numbers, medical record numbers, internal case references and API keys pasted into a support ticket. The comfortable assumption is that these high-entropy, low-meaning tokens are the least recoverable part of a document. The finding says they are recoverable.
The same paper identifies a genuine limitation, which I will return to when the defences come up: sensitivity to input sequence length. The dramatic recovery figures are measured at 32 tokens. Longer inputs are harder.
Zero-shot: dropping the last practical barrier
Through 2024 the honest version of the risk assessment included a real mitigating factor. Vec2text requires training an inversion model against your specific encoder — a corpus, compute, and a considerable number of queries against the target embedding API. That is not nothing. It puts the attack inside the budget of a capable adversary and outside the budget of an opportunist who has come into possession of a leaked index.
Zhang, Morris and Shmatikov removed that factor in “Universal Zero-shot Embedding Inversion” (2025). Their method, ZSInvert, is built on adversarial decoding and is described as “fast, query-efficient, and can be used for any text embedding without training an embedding-specific inversion model.”
Two things about how to read this, and the second is where I want to be careful, because overstating it would be the easy mistake.
What it changes: the economics. An attacker who obtains a vector store no longer needs to know, in advance, which encoder produced it, nor to invest in a bespoke inversion model per target. The per-target cost of attempting inversion collapses toward the cost of running an existing tool.
What it does not change: the fidelity claim. ZSInvert is characterised as recovering “key semantic information about the corresponding texts” — not the verbatim exact-match rates that the trained, encoder-specific vec2text achieves. Zero-shot inversion is a broader, blunter instrument.
Which is why “blunter” is cold comfort in a compliance context. The question a regulator or a data-protection authority asks after a vector-store breach is not “was the text reconstructed to the token.” It is whether personal data was disclosed. Recovering the key semantic content of a clinical note — the condition, the context, enough to identify the patient in combination with anything else — is disclosure. The fidelity gap between trained and zero-shot inversion is a gap that matters to researchers benchmarking BLEU. It does not obviously matter to the obligation.
Ghost vectors: what “deleted” means on disk
The 2026 result extends the problem into a place most architectures have never examined: the deletion path.
“Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases” (Chakraborttii, García Alvarado, Abdulofizova and Dwivedi, submitted 16 June 2026) starts from an implementation detail that is entirely standard and entirely reasonable. HNSW — the graph index most production vector databases are built on — does not support cheap physical removal. Deleting a node would require repairing the graph’s connectivity, so implementations mark vectors as deleted and filter them out at query time, reclaiming the space later during compaction, if compaction runs at all.
The consequence: the vector is gone from the application’s point of view and present in the index files on disk. The paper’s contribution is to run off-the-shelf inversion against those tombstoned vectors and report what comes back.
On a Wikipedia biographies-of-living-persons corpus: 25.5 percent of exact person names and 46.4 percent of geographic locations (ROUGE-L 0.185). On the NIH Synthea synthetic medical dataset: 100 percent recovery of both patient age and gender markers (ROUGE-L 0.290). Beyond text, on facial embeddings, top-1 identity recovery reaches 99 percent; on histopathology embeddings, 100 percent tissue classification.
Two caveats I would state to a client before they act on this. It is a preprint and has not been through peer review at the time of writing — treat the exact percentages as provisional and the mechanism as sound, because the mechanism is a documented property of HNSW rather than a novel claim. And the recovery rates are per-dataset and per-category; the structured demographic markers come back at 100 percent because they are low-cardinality fields, which is a different kind of finding from the free-text name recovery.
The mechanism is what should worry you, and it does not depend on the percentages. If your erasure process terminates at the vector database’s delete API, it terminates above the layer where the data physically lives. The paper frames this against GDPR Article 17. The obligation I would raise first with an Indian data fiduciary is closer to home: under the DPDP Act 2023 and the DPDP Rules 2025, personal data must be erased once the purpose it was collected for is no longer served, and data-principal erasure requests have to be discharged inside a defined window. A delete call that leaves a reconstructible vector in an index file has not discharged that obligation. It has produced a record that says it did.
That distinction — between the erasure and the record of the erasure — is the whole finding, and it is the kind of gap that only surfaces when someone asks to see the disk.
What the security canon now says
This is no longer only a research literature. OWASP’s Top 10 for LLM Applications 2025 promoted Sensitive Information Disclosure to LLM02 and added an entirely new category — LLM08:2025, “Vector and Embedding Weaknesses” — which exists because the retrieval layer turned out to have its own failure surface distinct from the model’s.
The category description is blunt: weaknesses in the generation, storage or retrieval of vectors and embeddings can be exploited to inject harmful content, manipulate outputs, or access sensitive data. Five risks are enumerated, and it is worth having all five in view rather than only the one this piece is about:
Unauthorised access and data leakage. “Inadequate or misaligned access controls can lead to unauthorized access to embeddings containing sensitive information.” The retrieval path discloses personal or proprietary content because the store does not know who is asking.
Cross-context information leaks and federation knowledge conflict. In multi-tenant deployments, “there’s a risk of context leakage between users or queries” — and separately, retrieved content can contradict the model’s parametric knowledge, with no defined precedence.
Embedding inversion attacks. “Attackers can exploit vulnerabilities to invert embeddings and recover significant amounts of source information, compromising data confidentiality.” The subject of this piece, named in the standard, in those words.
Data poisoning. Poisoned content entering the knowledge base — from insiders, from unverified providers, from user-supplied documents — and steering outputs from inside retrieval.
Behaviour alteration. Retrieval augmentation changing the base model’s behaviour in ways that are not purely improvements; factual grounding can come at the cost of other qualities.
The mitigations OWASP lists are four, and I reproduce them in full because the first one is the load-bearing one and it is the one most deployments have skipped:
Permission and access control. “Implement fine-grained access controls and permission-aware vector and embedding stores,” with strict logical and access partitioning of datasets to prevent unauthorised cross-user access.
Data validation and source authentication. Robust validation pipelines for knowledge sources; regular audit of the knowledge base for hidden instructions and poisoning; accepting data only from verified sources.
Data review for combination and classification. Reviewing combined datasets when sources are merged, and tagging and classifying data within the knowledge base to control access levels.
Monitoring and logging. “Maintain detailed immutable logs of retrieval activities to detect and respond promptly to suspicious behavior.”
Note what the first mitigation implies architecturally, because it is not a configuration change. A permission-aware vector store requires entitlement metadata to travel with each element and to be evaluated at retrieval time, per query, against the asking user. Most pipelines discard that metadata at index time — chunking a document into passages is precisely where the document’s access-control identity gets dropped, because a chunk is a string and a string has no owner. The mitigation is therefore an ingestion redesign in most estates, and pricing it as a permissions toggle is how it stays on the roadmap for a year.
The adjacent failure, stated carefully: EchoLeak
EchoLeak (CVE-2025-32711) is frequently cited alongside inversion research, and it belongs in this file — but as an adjacent failure at the same layer, not as evidence for the same claim. Being precise about the difference is worth a paragraph, because conflating them weakens both arguments.
What it was: a critical vulnerability in Microsoft 365 Copilot disclosed by Aim Security in June 2025, carrying a CVSS score of 9.3 and classified by Microsoft as AI command injection. The researchers described the technique as an “LLM scope violation” — untrusted external input causing the assistant to reach into data it was legitimately able to access on the user’s behalf, and to exfiltrate it. Microsoft addressed it server-side and stated that there was no exploitation in the wild.
The “zero-click” framing needs care. It does not mean the user does nothing. It means the user never interacts with the attack artefact: the malicious content arrives as an ordinary email, the victim need not open or click anything in it, and the exfiltration path is triggered when they subsequently use the assistant in a normal way and the assistant’s retrieval pulls the attacker’s content into context. The absence of a click is the significant part — the usual last line of defence, a person deciding not to engage with something suspicious, is not available, because the person never sees it.
What it demonstrates is that the retrieval layer is a reachable attack surface, and that content indexed for helpfulness can be used to steer the system that indexes it. What it does not demonstrate is embedding inversion. No vector was inverted. It is worth pairing with the inversion literature only for this reason: the two results attack the same asset from opposite directions. EchoLeak shows an adversary can make the retrieval layer surface indexed content to them. The inversion research shows that the vectors are exposed without the retrieval layer’s cooperation — that possession of the index files alone is sufficient. Defending the query path does not address the second problem.
The defences, and their fine print
The same literature that broke the anonymisation assumption also measured what blunts the attack, and the measurements are genuinely encouraging. They are also narrower than they are usually reported to be.
Noise injection. Morris et al. tested adding Gaussian noise to the embedding before storage, scaled by a parameter λ. Their table is the clearest statement of the tradeoff anyone has published. At λ = 0, retrieval NDCG@10 is 0.302 and reconstruction BLEU is 80.372. At λ = 0.01, NDCG@10 falls to 0.296 and BLEU collapses to 10.334 — in the authors’ words, “retrieval performance is barely degraded (2%) while reconstruction performance plummets to 13% of the original BLEU.” At λ = 0.1, reconstruction is destroyed (BLEU 0.148) and so is retrieval (NDCG@10 0.002).
Read the full row set rather than the λ = 0.01 line alone. The usable window between “no protection” and “no retrieval” spans one order of magnitude in a single hyperparameter, and it is narrow enough that getting it wrong in either direction is easy. Zhuang et al., testing noise on a different setup, found λ = 0.1 drove exact-match reconstruction to zero with top-10 retrieval accuracy at 0.730 against 0.748 unprotected — a different optimum in a different configuration, and their conclusion is that correct parameter setting is critical and varies by embedding model. So the defence exists, and it is not a constant you can copy from a paper into a config file. It has to be tuned per encoder, per corpus, and re-tuned when either changes.
Quantization. The stronger and simpler result. Zhuang et al. found product quantization drove exact-match reconstruction to 0.0 — against 43.0 unquantized in that setting — while top-10 retrieval accuracy was 0.749 against 0.748 unquantized. Retrieval effectiveness was preserved to within noise, and index size dropped from 61GB to 16GB. The RecSys 2025 team reached a compatible conclusion independently, finding that both Gaussian noise and quantization mitigate the risk, “with quantization offering a simpler and more widely applicable solution.”
A defence that costs nothing in retrieval quality and reduces your index by three quarters is a defence you should already have deployed. If you take one operational action from this piece, that is the one.
Now the fine print, and it is the part that keeps this a mitigation rather than a solution.
Every published evaluation assumes a non-adaptive attacker. The inversion models were trained against undefended embeddings and then pointed at defended ones. Nobody has published a result where the attacker trains against the defence — inverting quantized embeddings with a model trained on quantized embeddings, or learning the noise distribution. That is the obvious next paper, and the history of every privacy mechanism evaluated this way suggests the adaptive number will be worse than the non-adaptive one. How much worse is unknown, which is itself the point: you are deploying a control whose strength against a motivated attacker has not been measured.
Low reconstruction scores do not prevent coarse inference. BLEU falling to 13 percent of baseline means verbatim reconstruction is broken. It does not mean nothing is learnable. Whether an embedding sits in the region of the space occupied by oncology notes, or by distressed-debt term sheets, or by internal-investigation memoranda, is a much easier inference than reconstructing the text — and in many contexts it is the disclosure that matters. Knowing that a named individual’s record is in the cancer cluster does not require recovering a single sentence of it.
The length sensitivity cuts both ways. The headline exact-recovery figures are at 32 tokens, and RecSys 2025 confirms degradation with length. Longer chunks are harder to invert verbatim — but chunking strategies in production RAG typically land in ranges where a meaningful fraction of chunks are short, and the shortest chunks are frequently the most structured: headers, table rows, form fields, identifiers. The chunks most likely to invert cleanly are the ones most likely to be pure identifier.
Deploy the defences. They meaningfully reduce exposure and quantization in particular is close to free. Do not let deploying them reinstate the assumption they were deployed against. Until an adaptive-attacker result says otherwise, the operating assumption for any serious deployment is the title of this piece.
The vector-store audit protocol
What follows is the sequence I would run against a production retrieval estate. It is ordered so that the cheapest findings come first and each step’s output feeds the next. Most teams discover something in the first two hours.
One: inventory the embedding endpoints. Not the vector stores — the encoders. For every index in the estate: which embedding model produced these vectors, hosted where, reachable by whom, and under which credential. Black-box inversion requires query access to the same encoder; zero-shot methods relax even that. So the answer to “who can query the encoder that produced our sensitive index” is now a security-relevant fact, and almost no asset inventory records it. Expect to find shared API keys, a self-hosted encoder with no authentication because it was “internal,” and at least one index whose encoder nobody can identify. That last one is its own finding: an index you cannot attribute to an encoder is an index you cannot assess or migrate.
Two: propagate classification from source to derivative. For each index, trace back to the source systems and inherit the highest classification present. A vector derived from a record covered by health-sector rules carries that coverage. A vector derived from material non-public information is material non-public information. Then compare the inherited classification against the controls the index actually operates under — residency, encryption, retention, access review, backup handling, vendor sub-processing. The delta between those two columns is your report. In most estates the delta is large and entirely undramatic in origin: the store was provisioned by an application team as infrastructure, at a time when the classification question genuinely did not seem to apply to a list of numbers.
Three: test permission-aware retrieval, do not ask about it. Take a document a specific named user is not entitled to read. Issue a query as that user that should surface it. Watch what comes back. This is a ten-minute test and it settles an argument that otherwise runs for a quarter. If entitlement metadata was dropped at chunking time — the usual case — the test fails immediately and visibly, and you now have a demonstration rather than an architectural assertion. Record whether the fix is a retrieval-layer filter or an ingestion redesign, because the cost difference between those two is an order of magnitude.
Four: verify deletion to the disk. The step the Ghost Vectors result makes non-optional. Delete a test record through the normal application path. Then, at the storage layer, confirm the vector is not present in the index files: check whether your vector database performs soft deletion, when compaction runs, whether it runs at all under your configuration, and what your backup and snapshot retention does with index files that still contain tombstoned vectors. Backups are where this usually fails even in estates that have handled compaction — a snapshot taken before compaction preserves the ghost indefinitely, inside a system whose retention policy nobody has mapped to the erasure obligation. Under DPDP the obligation attaches to the personal data, not to the primary copy of it.
Five: map the erasure path end to end. A data-principal erasure request has to reach every derivative store: the vector index, the cached retrieval results, the evaluation datasets someone exported for testing, the vendor’s logs, the debugging traces, and the backups of all of the above. Write it out as a diagram and identify who has confirmed each hop. The hops that fail are usually the ones nobody owns — the evaluation export sitting in an object bucket, and the vendor logs governed by a contract that says nothing about erasure. Both are fixable. Neither gets fixed until someone draws the diagram.
Six: put inversion in the threat model in writing. Not as an appendix. As a stated position: a leaked vector store is a disclosure of the underlying text, and the incident-response plan reflects that. Which brings us to the last section.
Incident response: what a leaked vector store actually is
The framing to settle before an incident, because the alternative is settling it with counsel on a call at speed.
If a vector index containing embeddings of regulated data is exposed — exfiltrated, left on an unauthenticated endpoint, included in a compromised backup, sub-processed to a party that should not have had it — the position that “only embeddings were exposed, not documents” is not defensible. It was never defensible on the research, and since OWASP named embedding inversion in LLM08:2025 it is not defensible on the standards either. The research is public, the reproductions are published, the tooling is open source, and zero-shot methods removed the requirement to train against your specific encoder. Every element of the attack is available to a moderately capable party who has come into possession of your index.
Three consequences follow, and each of them is easier to arrange before the incident than during it.
Notification assessment starts from the source data, not from the vectors. The question is not “what can be recovered from these embeddings” — that is an open research question you will not resolve in the notification window. The question is what these embeddings were derived from, which is answerable in minutes if step two of the audit protocol was ever run, and is a forensic project if it was not. Provenance metadata on the index is what converts a notification decision from a research problem into a lookup.
The encoder is part of the blast radius. If the same encoder is reachable by the attacker — a public API, a shared endpoint, a self-hosted model with weak controls — inversion fidelity is higher than if it is not. This should be assessed and stated in the incident record. It also means encoder access revocation is a containment action, which is not a step in anybody’s runbook today.
The sentence you do not want in a supervisory finding is that the organisation believed the word “embedding” implied anonymisation. That belief was reasonable in 2022. It has not been reasonable since October 2023, it has survived two independent reproductions since, and the security standard your own architecture team cites now names the attack in the category title. The gap between what the research established and what the deployment assumed is exactly the kind of gap a supervisor characterises as a control failure rather than a technical surprise.
The counterargument worth taking seriously
The strongest objection is not that the research is wrong. It is a question of threat model: inversion requires possession of the vectors. If an attacker has your vector store, they have breached your perimeter, and at that point you have a breach regardless. Why does the inversion result change anything?
It changes three things, and each of them is a place where the standard breach calculus gives the wrong answer.
It changes where the vectors are. The premise assumes vectors live where documents live. They do not, and the reason they do not is the assumption this piece is about. Because embeddings were classified as derived and safe, they were allowed to travel: to managed vector databases in other jurisdictions, into analytics environments, into evaluation datasets shared with vendors, into debugging logs, into backups held under a different retention policy from the source system. Every one of those is a copy of the sensitive text sitting outside the control environment built for the sensitive text. The inversion result does not create new attack paths; it reveals that paths already treated as low-risk carry the payload.
It changes what a partial breach means. Read-access to a vector store — a misconfigured endpoint, an over-scoped service credential, a sub-processor’s environment — is normally triaged as low severity precisely because vectors were thought to be opaque. That triage is wrong, and it is wrong at the point where the severity decision is made, which determines everything that follows: the escalation, the forensic depth, the notification clock. A misclassified severity at hour one is not recoverable at day ten.
It changes what deletion means. The Ghost Vectors result is not about a breach at all. It is about the ordinary operation of a compliant system: data erased on request, from the application’s point of view, remaining physically recoverable in index files and in the backups of index files. No attacker is required for that to be a violation of an erasure obligation. The organisation does it to itself, in the course of believing it has complied.
So the objection is right that inversion is a post-compromise capability and wrong that this makes it academic. It is a post-compromise capability applied to assets your controls treat as pre-compromise-irrelevant — which is the definition of a mispriced risk.
Where this leaves you
An industry built its retrieval layer on an anonymisation assumption that nobody tested, because the assumption was never articulated clearly enough to test. The researchers tested it. Then two independent teams reproduced it, one of them finding real flaws in the original evaluation and reporting ninety percent recovery after correcting them. Then a third dropped the requirement to train against your specific encoder. Then a fourth showed that deletion does not reach the disk.
The corrective actions are not exotic. Classify the vector as the data it encodes. Make retrieval permission-aware, which for most estates is an ingestion redesign rather than a toggle. Inventory the encoders. Verify deletion at the storage layer and in the backups. Turn on quantization, which costs nothing measurable and defeats the attack in tested settings against non-adaptive attackers. Write the inversion assumption into the incident-response plan before counsel asks for it.
None of that requires anyone to have been wrong. It requires accepting that a reasonable belief held in 2022 was overtaken by evidence in 2023 and has been repeatedly confirmed since. That is an ordinary thing for a fast-moving field to do to a design assumption. What is not ordinary — what a supervisor will treat as a control failure rather than a surprise — is continuing to hold it now.