Delete a record from a vector database and it does not disappear. In June 2026, four researchers at Trinity College tested three of the most widely deployed vector stores and found that a confirmed deletion changes almost nothing on disk. The embedding stays exactly where it was, byte for byte, recoverable by anyone who can read the raw index files. Reading those files never touches the query API, so it never touches any defense that lives at the API.
The paper, titled Ghost Vectors, ran a stock text-inversion model against those soft-deleted embeddings with no domain-specific training and reconstructed sensitive content at rates that break both GDPR and HIPAA thresholds. On a Wikipedia dataset of living people, it recovered 25.5% of exact person names and 46.4% of geographic locations. On a synthetic clinical dataset it recovered patient gender in 73.4% of cases and patient last names in 49.9%. On soft-deleted facial embeddings it reached 99.17% top-1 identity recovery. The number that matters for anyone running a retrieval pipeline over private data is simpler than any of those: a deleted vector is not a deleted document, and the gap between the two is where the breach lives.
What soft deletion actually does
Modern retrieval-augmented generation runs on approximate nearest neighbor search, and the dominant index structure for that search is HNSW, hierarchical navigable small world. An HNSW index is a multi-layer graph. Each node is a vector, each node links to its nearest neighbors, and a query walks the graph layer by layer to find close matches in roughly logarithmic time. That structure is the reason the index is fast, and it is also the reason deletion is hard.
To remove one node cleanly, the system has to find every node that points at it and re-run the neighbor-selection routine on each of those nodes so the graph stays navigable. HNSW stores no reverse edges, so finding the in-neighbors is itself a search, and re-linking them is a localized rebuild that can cascade. Worse, deleted nodes are frequently the high-degree hubs in the upper layers that make search logarithmic instead of linear. Rip one out and you do not lose a data point, you lose a routing highway.
So production systems do not delete. They tombstone. The Trinity College team confirmed the pattern across three independent stacks. In ChromaDB, calling delete() updates an SQLite metadata table and later queries skip the flagged IDs, but the raw index.bin file is untouched. FAISS goes further: its IndexHNSWFlat exposes no delete method at all, so every vector ever inserted accumulates indefinitely, and calling remove_ids() raises a runtime error. Weaviate stores a proprietary format, yet its disk footprint grew after a logical delete rather than shrinking. In every case the API correctly returns nothing for the deleted ID. In every case the vector is still on disk. As the authors put it, soft deletion is a deliberate performance trade-off, not a bug.
That distinction has a legal edge. GDPR Article 17 grants a right to erasure without undue delay, and the European Data Protection Board guidance specifies that erasure must be both verifiable and irreversible. Suppressing a record from query output satisfies neither. The controller can truthfully report that the API returns no record for a given ID while the underlying embedding sits intact in a backup snapshot for months. Functional deletion and storage-layer erasure are not the same thing, and the industry has been quietly treating the first as if it were the second.
How the reconstruction works
An embedding is supposed to be a lossy, one-way projection of text into a vector. The assumption baked into most RAG architectures is that you can store the vector without storing the source text, because the vector reveals little. Embedding inversion breaks that assumption. The technique the paper uses, Vec2Text, treats reconstruction as iterative controlled generation: it starts from a candidate sentence produced by beam search, embeds that candidate, measures the distance to the target vector, and rewrites the candidate to shrink the distance. Repeat for a handful of steps and the output converges on text whose embedding sits almost on top of the target.
Two properties make this dangerous at the storage layer. First, the corrector is pretrained and frozen, so the attacker runs it with no fine-tuning against the victim’s data. Second, inversion transfers across embedding models. The team reconstructed target vectors, then checked the results against three surrogate encoders different from the one that produced the embeddings, and ROUGE-L held steady at 0.190 with cosine similarity between 0.86 and 0.90. An attacker does not need to know which embedding model the victim used. Newer zero-shot methods such as Zero2Text and ZSinvert push cross-model transfer further still, which means the numbers in this paper read as a conservative floor rather than a ceiling.
The attack pipeline is almost boring in its simplicity. Read the on-disk index with a short Python script, pull the soft-deleted vectors out with the same library method the database uses internally, feed them to the frozen corrector, and read plaintext back out. The scripts never call the query API, so query-side defenses never see them. Cosine similarity between the extracted ghost vectors and the originals came back above 0.999, meaning the recovered vectors are not degraded copies. They are the originals.
The numbers that should worry a controller
On 98 records from a Wikipedia biographical-living-persons set, inversion recovered geographic locations 46.4% of the time, affiliations 44.7%, and person names 25.5%, at a ROUGE-L of 0.185. The hard-delete baseline, where vectors were encrypted and the key discarded, recovered nothing across every category. To rule out the possibility that the attack was just reading similar live records, the team isolated the 50 most unique deleted records, those whose entities appeared nowhere in the surviving data, and still recovered entities from 9 of them. The deleted vector was the only possible source.
The clinical results are the ones that will draw regulators. On a synthetic clinical set built to resemble real notes, complete with abbreviations and shorthand, gender came back 73.4% of the time and patient last names 49.9%, a 17-fold lift over a random-noise baseline that produced person-shaped strings but matched no real surname. Structured, sensitive, high-consequence data is exactly the data that inverts most cleanly, because its regularity gives the corrector more signal to lock onto.
Compression does not save you. Vector quantization is standard in production to cut memory, and the team tested it directly. Scalar int8 quantization, the most common scheme, preserved 93% of reconstruction quality. Product quantization preserved 78%. A defense tuned for live API queries does nothing against raw index access, because the geometry the attacker needs survives the compression.
The threat crosses modalities. Soft-deleted facial embeddings from Labeled Faces in the Wild yielded 99.17% top-1 identity recovery, 156 times better than the random baseline, with a Wilcoxon p below ten to the minus twelfth. Histopathology patches recovered tissue class at 100%. The ghost vectors in both cases retained cosine similarity of 1.000 with their originals, and on a UMAP projection they land as gold stars sitting perfectly inside the clusters they were supposed to have left. Biometric data is exactly the category GDPR Article 9 puts under the strictest consent rules, and it is exactly the category where a deleted vector remains a perfect fingerprint.
Why this is not just a storage-layer problem
Even if nobody ever reads the raw files, the ghost node keeps working. Soft deletion operates on metadata, not on the graph, so the deleted node stays wired to its neighbors and the greedy search walk still visits it. It gets filtered out of the final result set, but it still shapes the path the search takes. The team measured a 95% drift in top-K neighbor sets between soft deletion and true deletion. In plain terms, a record a user asked to be forgotten still influences what other users see, because the deleted node is still acting as a structural hub in the search. The deleted record still votes.
There is even a timing side channel. True deletion shaved 4.3% off query latency by removing the wasted traversal through dead nodes. That difference is small but statistically real, which means an attacker with nothing more than API query access can compare latency against a baseline and infer whether a given record was actually erased or merely hidden. The ghost extends past the disk and into the live query path.
How cheap the attack is
Security risk is a function of cost, and this one is cheap. The team ran a step-count sweep on the corrector and found that a single inference step recovers 98.4% of the quality that ten steps produce, at 30.7 milliseconds per record. There is no iterative grind, no need to let the model refine over dozens of passes. One pass is almost the whole result.
Scale that out and the arithmetic is stark. On a single GPU, inverting one million soft-deleted records takes under nine hours by the paper’s own extrapolation. No specialized hardware, no distributed cluster, no privileged access to the model. The attacker needs read access to the raw index directory, which a misconfigured cloud bucket, a leaked backup, or an insider with database credentials all provide, and a frozen model anyone can download. The whole barrier to entry is the willingness to copy one binary file.
That last point reframes the threat model. The extraction script reads the on-disk file directly and never generates an API audit log, so a database administrator or a cloud provider employee can pull the vectors without leaving the fingerprint that a query would. Copying index.bin once is the entire operation. Everything after that runs offline on the attacker’s own hardware, on their own schedule, invisible to the controller who believes the records were erased.
Why the window never closes
A conventional breach has a timeline. Credentials get rotated, the hole gets patched, the exposure ends. A ghost-vector exposure does not close on its own, because the vector is not a live credential. It is a static artifact that stays semantically intact until the storage media is physically destroyed or cryptographically overwritten. The team verified this by inverting from a backup snapshot and getting identical reconstruction quality, ROUGE-L 0.207, months of stale data reading exactly as well as fresh data.
The variance held steady across scale too. Across index sizes from one thousand to one hundred thousand records, ROUGE-L variance stayed at 0.016, so the attack does not degrade as the corpus grows. A larger private database is not a safer one. It is a larger pool of indefinitely recoverable records, each one waiting on the same open window that began the moment the controller clicked delete and will not end until someone erases the bytes.
What verification would actually look like
If an API’s silence is not proof of erasure, the obvious question is what proof looks like. The paper’s answer is worth separating from its specific defense, because the principle outlives the implementation. Verifiable deletion needs three properties that a tombstone flag has none of. It has to be irreversible, meaning no key, no backup, and no index copy can reconstruct the content. It has to be auditable, meaning the system emits a record that a third party can check without trusting the operator’s word. And it has to be complete, meaning the deletion covers every replica, every snapshot, and every derived index, not only the primary.
Cryptographic erasure satisfies the first two cleanly, which is why the epoch-rotation design lands on it. Destroying a key is irreversible in a way that overwriting a row is not, and signing the deletion event produces an artifact an auditor can verify. The third property is where most production deployments will fail regardless of the crypto, because vector indexes get replicated for availability, snapshotted for disaster recovery, and copied into staging environments for testing. A deletion that covers the primary index and misses six months of nightly snapshots is not a deletion. It is a deletion of one copy.
For anyone auditing their own stack, the concrete test is blunt: take the raw index file, extract the vectors for a record you deleted, and check whether the geometry is still there. If the vector comes back with cosine similarity near 1.0 against the original, your deletion is cosmetic. That test requires no attack tooling and no inversion model. It only requires reading the file you already own and being willing to see the answer.
The fix, and where it is fragile
The authors propose Epoch Key Rotation, and to their credit they do not oversell it. Each user gets an encryption key tied to an epoch counter. Vectors are stored encrypted with AES-256-CTR. On a deletion request, the system rotates the epoch, which means it encrypts under a fresh key and irrecoverably discards the old one. Any vector under a discarded key is, reinterpreted as float32, indistinguishable from noise, so an inversion model has no geometric structure left to exploit. In testing, PII recovery dropped to 0%, the operation ran in 2.5 milliseconds for 500 vectors, and it emitted an ECDSA-signed proof of the deletion event, which is the verifiable audit record GDPR actually wants.
The honest part is what the authors flag as the failure mode. The whole guarantee rests on the key being gone. SQLite’s standard DELETE marks a row for reuse without zeroing the disk sector, which leaves the key recoverable from free pages, and the researchers say so directly. Real security requires hardware-isolated key storage, a TPM or an HSM, or explicit memory zeroing before disposal. Epoch rotation also erases the content of the ghost vector but not the node itself, so the structural drift and timing side channel remain until a separate graph-repair pass re-links the deleted node’s neighbors. It is a real defense with two clearly labeled edges, which is more than most security papers offer.
Differential privacy, the reflexive answer to embedding leakage, is the wrong tool here. Adding calibrated noise to protect a query distribution assumes the adversary is querying. This adversary is reading raw bytes off disk, where no query-time noise budget applies. The paper shows a query-side orthogonal transform, a representative inversion defense, collapses instantly against a storage adversary, because the transform matrix has to persist as a server-side secret and can simply be extracted and inverted. After reversing it, reconstruction quality actually rose slightly above the undefended baseline.
What to do before the next model gets better
The uncomfortable framing the paper leaves you with is that reconstruction quality is a moving target and physical persistence is not. Today’s corrector recovers clinical free text poorly, with MIMIC-III scores near zero, because the model is out of distribution. Fine-tuning it on 43,000 clinical pairs pushed that up 26-fold. The vector on disk does not change. It sits there with its exact geometry intact, waiting for a better inversion model, and better inversion models arrive on a monthly cadence. A backup snapshot taken today can be inverted with tomorrow’s corrector at full fidelity.
The practical takeaway for anyone running retrieval over sensitive data is to stop treating an API’s silence as evidence of erasure. If your compliance story depends on deletion, the deletion has to happen at the storage layer, which means cryptographic erasure with disposed keys, not a tombstone flag. Treat the vector store with the same security posture as the source documents, because a breach of the index is a breach of the documents. This connects directly to the broader pattern this publication has tracked in RAG attacks on clinical systems and biomedical retrieval pipelines: the retrieval layer is now the attack surface, not a neutral plumbing detail. It also sharpens the stakes behind formal privacy work like differential privacy for LLM training and the memorization problem covered in how models leak their training sets. The vector database was supposed to be the safe place to put the data. It is not.
This piece analyzes a published security paper. It describes a data-privacy risk and its documented defense. It is not a guide to attacking any system.