SOTA privacy experiment: decouple stored embeddings with shadow queries

Finding

Shadow Queries for Private Retrieval in Vector Databases, submitted 2026-09-04, targets embedding inversion rather than query privacy. Instead of storing a document embedding directly, SHAQ generates diverse semantically relevant shadow queries per document and stores embeddings of those queries. The originating team reports text recovery as low as 0.2104, up to 19.50% more defended tokens than baseline defenses, MAP@10 up to 0.7967, and up to 5.53% utility improvement over the compared defense.

Evidence class: originating-team measured, not independently reproduced by RuV. The arXiv manuscript is under the arXiv perpetual non-exclusive license. No implementation license suitable for code reuse was verified in this cycle, so this issue imports no source code.

RuV implication

This is orthogonal to issue #967. #967 addresses outsourced query privacy under a two-server non-collusion model. This issue addresses stored-embedding inversion if an attacker obtains or queries the vector representation itself.

Potential reuse: RuVector hosted indexes, Core Memory enterprise memory, Cognitum RAG, MCP retrieval, RVF provenance, and bounded RuVector WASM stores.

Reversible experiment

Compare five frozen conditions:

A. ordinary document embeddings

B. additive-noise defense at matched retrieval utility

C. vector scaling or normalization defense at matched retrieval utility

D. one shadow-query embedding per document

E. diverse multi-shadow-query indexing with a fixed generation budget

Use at least two embedding models and three corpora with materially different document length and semantic density.

Attack model

Reproduce a modern embedding inversion baseline such as vec2text, then add an adaptive attacker that knows the defense architecture and generation prompt family but not secret tenant data.

Required benchmark report

Record corpus digest, embedding model and version, shadow generator and version, prompts, seeds, document count, query count, index size, construction latency, generation tokens and cost, MAP@10, recall@10, p50/p95/p99 query latency, storage multiplier, inversion recovery, defended-token rate, CPU, memory, and energy where measurable. Include malformed documents, low-information documents, duplicate content, updates, deletes, distribution shift, and adversarial query patterns.

Promotion gate

A shadow-query design advances only if all are true:

1. inversion recovery falls by at least 50% relative to ordinary document embeddings
2. retrieval quality loses no more than 1 absolute point of MAP@10 or recall@10 against the stronger baseline
3. p95 query latency regresses by less than 10%
4. index storage stays below 3 times the document-embedding baseline
5. generation cost is amortized within the declared customer workload horizon
6. deletion and tenant isolation semantics remain exact

Falsification

The defense may simply move sensitive information from a document embedding into several semantically revealing query embeddings. Test an adaptive attacker over the entire per-document shadow set, not one vector at a time. If privacy gain disappears under set-level attacks, reject the design.

A cheaper dimensionality reduction or quantization baseline must also be included. If it performs within variance at lower cost, prefer the simpler defense.

Security and governance

Shadow queries are derived sensitive artifacts and inherit the source document's tenant, retention, deletion, and access policy. They cannot be logged or reused across tenants. Retrieval quality is not evidence of privacy. Privacy measurements cannot authorize release or declassification.

Existing RuVector indexing remains the rollback path. No production format migration or default change is authorized.

No implementation files or tests are named. Start by mapping the five frozen conditions and adaptive set-level attack against existing RuVector indexing, then define the benchmark inputs and measurements listed in the report. Done means meeting every promotion gate, preserving deletion and tenant isolation, or documenting falsification and rejecting the design without changing production defaults.