What a 95.4% Retrieval-Pivot Rate means for your stack

Dmitry Maranik·

In February 2026 an arXiv paper titled Retrieval Pivot Attacks in Hybrid RAG reported that 334 of 350 benign queries, 95.4%, leaked cross-tenant data on a typical shared-vector-index deployment. No prompt injection, no jailbreak, no adversarial inputs. The queries were the kind of thing a real user would type. The leakage came from the embedding model being good at its job.

What the paper actually claims

The setup: a hybrid RAG pipeline (a vector database for embeddings plus a keyword retriever) serving multiple tenants from a shared index. The "leakage" is a query from tenant Y that surfaces a document owned by tenant X.

The mechanism: organic entities. Real tenants share things, vendor names, person names, compliance terms ("SOC 2", "PCI-DSS"), monetary amounts, dates, project codes. When tenant Y types a benign query about something they have in common with tenant X, the embedding model, being good at semantic similarity, surfaces tenant X's document because it legitimately matches the query embedding.

The headline number: 334 / 350 benign queries (95.4%) triggered a retrieval pivot on the studied stack. The paper also found, uncomfortably, that stronger embedding models leak more: mpnet-base-v2 (the stronger model) pivoted on more queries than MiniLM (the weaker model). Recall and cross-tenant leakage are correlated.

What this means in practice

If you run a multi-tenant RAG pipeline with a shared vector index and you have not measured your Retrieval-Pivot Rate, three things are likely true at the same time:

  1. Some non-trivial fraction of your benign user queries surface foreign-tenant content. The number is bounded above by the research finding (~95% in the worst case) and below by zero (a properly per-tenant-namespaced index). Where your stack lands depends on your namespace scheme, your embedding model, and whether your tenants share organic entities.
  2. The leakage scales with embedding-model quality. If you have recently upgraded from a smaller embedding model to a larger one (or are planning to), your leakage rate likely went up at the same time your recall improved.
  3. A standard LLM-as-judge red-team check will miss most of it. The leaking queries are benign; a judge looking for adversarial prompts or jailbreaks will not flag them.

How to measure it on your own stack

The Retrieval-Pivot Rate is the Class 2 metric in Sectum AI's open- source attack catalog. The measurement is reproducible: provision a handful of synthetic tenants on your stack, give each one a corpus that shares organic entities with the others, embed a unique canary marker in each tenant's documents, and issue benign queries from each tenant's session. Count the fraction of queries that surface a foreign-tenant canary. 

pip install sectum-ai

# Provision 4 synthetic tenants (Acme, Globex, Initech, Hooli by
# default), plant canary markers, record the ground-truth manifest:
sectum-ai seed --workdir .sectum-ai --config sectum-ai.yaml

# Run the probe suite (Class 2 is the headline). The --output json
# flag emits a single JSON object with the RPR ready for a dashboard:
sectum-ai probe --workdir .sectum-ai --config sectum-ai.yaml --output json

# Build the tamper-evident evidence pack, the artifact your auditor
# or DPO accepts as testing coverage:
sectum-ai report --workdir .sectum-ai --config sectum-ai.yaml

A clean run on a per-tenant-namespaced index reports RPR ≈ 0. A run on a shared-index stack reports the actual rate; the research number is the upper bound, not a guarantee.

What to do if your RPR is non-zero

Three remediation paths, none of which Sectum AI implements (we verify; we don't remediate):

  1. Per-tenant namespaces. Most vector DBs support them natively, Pinecone namespaces, pgvector per-tenant schemas, Weaviate per-tenant collections, Chroma per-tenant collections. If your stack is on a shared index because of historical reasons, this is the first thing to fix. Sectum AI's per-tenant- namespaced adapter modes (`shared_index: false`) verify the fix worked.
  2. Server-side metadata filtering. If a shared index is a hard requirement, every query MUST filter by tenant ID at the database layer (not in the application layer; not in the LLM prompt). Sectum AI's Class 2 probes deliberately exercise the boundary even with metadata filters in place, the goal is to verify the filter actually engages.
  3. Hybrid retrieval with tenant-aware re-ranking. If you're running BM25 + vector hybrid retrieval, your re-ranker can demote cross-tenant matches before they reach the LLM. This is the "sledgehammer" fix; it works but adds latency.

The evidence shape that matters

Knowing your stack has a 23% RPR (or 0%, or 90%) is useful for your platform team. Proving it to your auditor, your DPO, or a customer's security team, with an artifact they can independently verify, is what they actually need.

Sectum AI's evidence pack is exactly that artifact: the evidence.json + audit-pack.pdf + attestation.intoto.json bundle, anchored with an RFC 3161 timestamp + (optional) Sigstore Rekor inclusion proof. Anyone, your auditor, your DPO, a customer's reviewer, runs sectum-ai verify against the pack and confirms it was produced at a stated time over stated test conditions, without needing to trust Sectum AI.

Start an engagement See the wedge SKU OSS on GitHub

References