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

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