Ghost Vectors: deleted embeddings stay recoverable in RAG vector databases

What is this?

In June 2026, Chandranil Chakraborttii, Jackeline García Alvarado, Sitora Abdulofizova and Shivanshu Dwivedi (Trinity College) published Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases. The paper examines a quiet assumption in almost every retrieval-augmented generation (RAG) stack: that when a record is deleted from the vector store, the data is gone.

It usually is not. Most production vector databases built on HNSW (Hierarchical Navigable Small World) indexes implement deletion as a soft delete — the record is flagged with a tombstone so search stops returning it, but the underlying embedding stays physically written to the index files on disk. The authors show that those “deleted” vectors can be read straight from the raw index at the storage layer and then inverted back into an approximation of the original content. Because embeddings frequently encode personal or medical data, that turns a routine deletion request into a compliance problem under data-erasure regimes such as GDPR Article 17 and HIPAA.

How it works

Two facts combine into the finding, and neither requires attacking a live query API.

First, soft delete does not erase. To keep deletions fast, an HNSW store marks a node as removed and skips it during traversal, deferring the actual reclamation of that space to a later (often rare) compaction or rebuild. Until then, the vector, and any payload stored alongside it, remains on disk. The authors confirmed this behaviour across three separate HNSW implementations: reading the raw index files recovers vectors the API reports as deleted, bypassing the access layer entirely.

Second, embeddings are not one-way. Using the off-the-shelf Vec2Text inversion model without any domain-specific fine-tuning, the team reconstructed readable content from recovered vectors across multiple real-world datasets and modalities, including both text and image embeddings, at meaningful recovery rates. No exploit code is needed to understand the result: an embedding is a lossy but reversible projection of its input, so whoever can read the vector can approximate the source text. The threat model here is anyone with storage-layer reach — a stolen disk snapshot, a misconfigured backup bucket, a cloud volume left readable, or an insider — not a remote user hitting the search endpoint.

Why it matters

RAG pipelines have quietly become long-term stores of sensitive text: support transcripts, HR files, clinical notes, contracts. Teams treat the embedding as an opaque, anonymised numeric blob and treat an API-level delete as fulfilment of a user’s erasure request. This paper breaks both assumptions at once. The vector is recoverable, and it is reversible, so “we deleted it” can be false at exactly the moment a regulator, auditor, or breach-notification obligation depends on it being true.

The gap is especially dangerous because it is invisible from the application’s own vantage point. Query the API after a delete and the record is genuinely gone; inspect the index file or a nightly backup and it is still there. Every replica, snapshot, and cold backup that captured the vector before compaction is an independent copy of the “forgotten” data. This is the storage-layer cousin of the retrieval-time leakage covered in RAG knowledge-base leakage and a reminder, alongside work like embedding inversion defenses failing in multi-agent settings, that embeddings deserve the same handling as the raw data they encode.

Defenses

The paper is constructive: it names the failure and ships a mitigation.

1. Do not equate a tombstone with erasure. If your compliance posture claims data is deleted, the vector and its payload must actually be removed from the index, its replicas, and its backups, not just hidden from search. Schedule and verify compaction/rebuilds rather than deferring them indefinitely.

2. Crypto-shred instead of soft-delete. The authors propose Epoch Key Rotation: encrypt stored vectors and, on deletion, discard the key so the ciphertext becomes unrecoverable. They report this drops observed PII recovery to 0%, completes in about 2.5 ms for 500 deleted vectors, and emits an ECDSA-signed proof that the deletion happened — an auditable artifact you can hand a regulator.

3. Treat embeddings as regulated data. Encrypt vector indexes at rest, restrict raw file and snapshot access with the same controls you apply to the source corpus, and keep embeddings of PII or PHI out of low-trust storage.

4. Extend deletion to the whole lineage. A verified erasure has to reach every backup, replica, and exported snapshot that ever held the vector. Inventory those copies before you promise a user their data is gone.

5. Produce deletion evidence. For GDPR Article 17 and HIPAA, a cryptographic, timestamped proof of erasure is far stronger than an API returning “not found.”

Status

Item	Reference	Date	Notes
Ghost Vectors paper (arXiv 2606.18497)	arXiv	2026-06	Trinity College; three HNSW implementations analysed
Recovery method	arXiv	2026-06	Raw index-file read at storage layer + Vec2Text inversion, no fine-tuning
Data types recovered	arXiv	2026-06	Text and image embeddings across multiple datasets
Compliance framing	arXiv	2026-06	GDPR Article 17, HIPAA data-erasure requirements
Proposed defense	arXiv	2026-06	Epoch Key Rotation: 0% PII recovery, ~2.5 ms / 500 vectors, ECDSA-signed deletion proof

The takeaway is not “vector databases are broken.” It is that deletion in a RAG store is a storage-layer property, not an API response — and if your erasure guarantees stop at the query interface, the ghost of every deleted record is still sitting in your index files.