Most published RAG poisoning work assumes exact retrieval: inject a document, let it compete in a global ranking, measure how often it lands in top-k. Almost nobody runs exact retrieval at scale. A paper posted to arXiv on October 15 (2610.21464, Chen, Wang, and Zhang of Xidian University) makes the gap explicit and then closes it in the wrong direction for defenders.
The authors point out that deployment-scale systems use approximate nearest-neighbor indexes — HNSW in particular — where limited search budgets, graph-search reachability, and local competition from benign documents all break the global-ranking assumption. Existing attacks degrade under those conditions. That sounds like accidental hardening, and for a while it has been treated that way.
Their attack recovers the loss by targeting the graph rather than the embedding space. Poisoned documents are organized into what they call a Hub–Satellite structure: satellites act as competitive entry points spread across semantic regions, while hubs provide local cohesion and enable cascading retrieval once traversal enters the neighborhood. On a 2M-document Wikipedia corpus they report over 72% retrieval success and 31.29% attack success, outperforming baselines. Their structural analysis shows the Hub–Satellite topology actually forms inside HNSW — the index's own neighbor-selection heuristics help the attacker.
Why this changes what you measure
If you evaluate your retrieval defenses with brute-force similarity search on a sample of your corpus, your numbers are not about your production system. ANN parameters you tuned purely for recall and latency — M, efConstruction, efSearch — are now security-relevant. Two systems with identical embeddings, identical chunking, and identical top-k can have materially different poisoning surfaces because their graphs are built differently.
This also puts pressure on where you spend your defense budget. Admission-time filtering is the natural reflex, and it is cheap: "Coverage Is Not Containment" (2608.16044) measures collective-statistic scoring at roughly 10% of HNSW insert time, 0.29 ms against 2.97 ms per document, with cost independent of corpus size. The paper's argument, though, is that coverage at admission does not equal containment against coordinated injection. Cheap and inline is not the same as sufficient.
Deletion is the other half
The same index-internals perspective breaks erasure. "Ghost Vectors" (2606.18497) shows soft-delete in HNSW only changes API-visible metadata while vectors stay intact on disk; reading ChromaDB's `index.bin` directly and running Vec2Text inversion recovered 25.5% of exact person names and 46.4% of geographic locations on a Wikipedia biographies set, and age and gender markers at 100% on structured clinical data. Their mitigation — encrypt per epoch, discard the key on deletion — reports 0% PII recovery at about 0.005 ms per record.
Who should care: anyone ingesting third-party or user-submitted content into a shared index, and anyone who has told a customer that delete means deleted. Test against the index you actually ship.