Why Signing Your RAG Documents Doesn't Guarantee Honest Retrieval

If you verify signatures on the documents feeding your retrieval-augmented generation pipeline, you have verified the text and almost nothing else. A new author-reported, unreplicated preprint, Signed but Steerable: Measuring and Closing the Text, Vector Integrity Gap in Offline Retrieval-Augmented Generation (arXiv 2611.06498, observed 2026-11-05), puts numbers on a gap that most RAG security checklists leave implicit: an attacker can ship a pack or vector store whose signatures verify cleanly while the embedding vectors shipped alongside the signed text steer retrieval toward wrong answers. The paper’s measurements span five corpora and two embedding models, and its headline figure is uncomfortable in both directions. Even an idealized verification tolerance set at the level of floating-point noise leaves up to 5.5% of queries hijackable, while a plausibly calibrated threshold leaves 98–100% exposed (preprint).

That finding changes where integrity checking belongs in an offline or supplier-fed pipeline. The practical consequence: a document signature is a statement about bytes, and the bytes are not what your retriever reads. Everything the retriever actually ranks on, the chunks, the embeddings, the index, is derived from those bytes and sits outside the signature’s coverage unless you bind it explicitly.

What a file signature covers, and the fan-out it does not

A signature over a source document authenticates that document’s content as published. But a production corpus does not stay at document granularity for long. In one fintech RAG deployment described in a separate evaluation paper, a corpus of 1,624 unique documents became over 30,000 text chunks, roughly 19 derived artifacts per document. Each of those chunks then gets at least one embedding vector, and the vectors get indexed into approximate nearest-neighbor structures with their own parameters and rebuild cycles.

So one valid signature at ingest fans out to dozens of derived artifacts that the signature says nothing about. If your integrity check lives only at the ingest boundary, you are trusting every transformation downstream of it: the chunker, the embedding model, the hardware it ran on, and whoever assembled the final store. The preprint states the asymmetry directly: “Signatures establish who published a pack; they do not show that its vectors encode its text. A compromised or malicious signer is exactly the case the binding must cover.”

This is also why the attack is specific to offline and supplier-fed RAG rather than RAG in general. Packs ship precomputed vectors for a concrete operational reason: on-device embedding is slow. In the authors’ earlier study, embedding a 950-passage pack on a Raspberry Pi’s CPU took about 29 minutes, per the preprint. A device that takes 29 minutes to embed one pack cannot recompute embeddings at ingest as a routine verification step, so the ecosystem norm is to trust the vectors the supplier computed. The signature creates the appearance of end-to-end integrity while the load-bearing artifact travels unverified.

The threat model is a valid signature, not a forged one

The preprint’s adversary does not break cryptography. It assumes an attacker who can make a verifier receive a pack or store with valid signatures: a compromised publisher or build pipeline, a malicious insider holding a content key, or a compromised writer of a vector store. In the paper’s words, “An attacker who controls the publishing pipeline, or an insider, can ship benign text with vectors chosen to steer retrieval.”

This matters for how you scope defenses. Signature verification, key rotation, and transparency logs all answer “who published this.” None of them answer “do these vectors encode this text.” If your supplier is honest and competent, the gap never opens. If your supplier is compromised, if a build step between embedding and packaging is compromised, or if whoever writes your vector store is compromised, every downstream consumer inherits steering vectors under a clean signature. The defense has to cover the binding between text and vectors, which is a different problem from authenticating either one.

The margin law: why tolerance-based verification leaks by construction

The obvious fix is to recompute embeddings from the signed text and compare them against the shipped vectors within some cosine-similarity tolerance. The preprint’s central result is that this fix leaks at a rate determined by the corpus itself. The paper formalizes it as the margin law: “the hijack rate equals the distribution of angular retrieval margins at the tolerance (the margin law).”

The mechanism is worth understanding because it explains why no single tolerance is safe. A retrieval margin is the angular gap between the top-ranked result and its competitors for a given query. Where margins are wide, an attacker needs to perturb a vector a lot to change what gets retrieved, and a tight tolerance catches the perturbation. Where margins are narrow, meaning many near-tied candidates, a small perturbation within your accepted tolerance is enough to flip the ranking. The tolerance you choose therefore does not set a security level in the abstract; it selects a slice of your corpus’s margin distribution and hands that slice to the attacker.

Two calibration results from the paper show how badly this can go:

• Idealized tolerance. At a tolerance set at the level of floating-point noise, the best case a verifier could plausibly achieve, up to 5.5% of queries remain exposed (preprint). Once exact duplicate documents are excluded, the worst single corpus drops to at most 1.2% (preprint). Duplicates are not a detail here: near-identical documents create near-zero retrieval margins, so they dominate the exposed slice. Deduplicating before calibrating moved the worst case by more than a factor of four.
• Hardware-noise calibration. A threshold derived from a CPU INT8, FP32 comparison of a small embedding model, set at the empirical 0.1% quantile of honest cosines, leaves 98–100% of queries exposed (preprint). This is the calibration a careful engineer might actually pick: measure the noise your quantization introduces, set the tolerance just above it. The paper shows that hardware noise and retrieval margins live on different scales, so a threshold that is generous enough to accept honest vectors is generous enough to accept adversarial ones.

The load-bearing parameter is not whether you verify, but where the tolerance comes from. The paper’s implication is that tolerance must be calibrated against your own corpus’s measured angular-margin distribution, not against a hardware comparison. That is a per-corpus measurement, not a constant you can copy from a blog post, and it has to be redone when the corpus, the embedding model, or the deduplication policy changes.

Where the checks belong: a placement checklist

The evidence supports treating each pipeline stage as a distinct integrity surface with distinct limits. None of the four stages below is sufficient alone, and one of them carries a measured accuracy cost.

Two conditions deserve emphasis because they flip recommendations rather than soften them. First, if your consumers run on hardware where recomputing embeddings costs tens of minutes per pack, ingest-time recomputation is not a routine check. The preprint reports both ends of that range: the 29-minute figure came from the larger BGE-M3 model, while re-embedding its 1,745-window corpus with the smaller MiniLM model takes about a minute on the same CPU, and verification at eight pairs per second alongside generation costs the language model 23–31% of its decoding speed (preprint). Where recomputation is affordable, the paper’s closing for compressed stores is code-level verification with canonicalisation rather than a tolerance audit. Where it is not, you need either independent attestation of the vectors or a sampled-audit model, and you should be explicit that sampling bounds detection probability rather than eliminating exposure. Second, if your workload is dominated by multi-hop questions, query-time filtering is not a partial mitigation with a small cost. It is, on the measured evidence, worse than doing nothing.

Query-time per-chunk verification is not a free fix

The strongest counter-evidence to the obvious remedies comes not from the preprint but from an adjacent evaluation, Per-Chunk Filtering Fails on Multi-Hop RAG, and Decomposition Repairs It. Its finding is blunt: “per-chunk gating is significantly worse than not filtering at all in every cell, and its penalty grows with generator capability.”

The mechanism is structural. Per-chunk verification assumes one chunk is a sufficient premise for deciding relevance. Multi-hop questions are constructed so that no single chunk suffices; the answer-bearing paragraph is often not the one the question names. So a per-chunk gate systematically discards exactly the evidence multi-hop reasoning needs. The entailment scores quantify it: AUC 0.643 on HotpotQA, 0.523 on 2WikiMultihopQA, and 0.560 on MuSiQue, versus 0.951 on single-hop SQuAD. On 2WikiMultihopQA, the scorer is barely better than chance. The evaluation covered three datasets, three generator sizes, and two prompts, and the penalty grew as generators became more capable, which suggests the problem intensifies as the rest of your stack improves.

The placement consequence: integrity enforcement belongs at the vector-store boundary, where the text-vector binding is broken, not at query time, where a per-chunk decision cannot see the structure of the question. If you need query-time assurance for multi-hop workloads, this evidence says per-chunk gating is the wrong shape for it.

When two valid proofs contradict each other

A tempting response to a single-signal failure is to stack signals: sign the text, attest the vectors, watermark the outputs. A result from media provenance warns that stacked signals need cross-checking, not just individual verification. In Authenticated Contradictions from Desynchronized Provenance and Watermarking, the authors show “a digital asset can carry a cryptographically valid C2PA manifest asserting one provenance history while its pixels simultaneously carry a watermark signal that contradicts that history, with both signals passing their respective verification checks in isolation.”

The same paper reports that the Content Credentials Verify tool displays the same AI-generated, watermarked image as either AI-generated or human-edited depending entirely on the attached manifest, with no mechanism to inspect or cross-reference the pixel-level signal. Each layer verifies; together they contradict. The authors term the condition the Integrity Clash.

This is an analogue from image provenance, not a RAG measurement, and it should be read as one. But the transfer is direct: if your pipeline signs text at ingest and separately attests vectors at the store boundary, an attacker who can desynchronize the two produces exactly this shape of failure, two proofs that each pass and jointly describe different content. The checklist implication is that verification steps must compare signals against each other (does this attested vector set correspond to this signed text revision?) rather than each signal against its own reference.

What this preprint establishes, and what it cannot

The integrity-gap measurements above trace to one author-reported, unreplicated preprint. The paper tests five corpora and two embedding models (BGE-M3 and MiniLM), running its tolerance audits on flat FAISS indexes across SQ8, SQ4, product-quantisation and binary storage with cosine retrieval; other vector stores and retrievers are untested, and the exposure rates are tied to the paper’s idealized-tolerance threat model. The 5.5% and 1.2% figures from the preprint describe what an attacker can achieve against a specific verification construction; they are not measurements of any deployed system, and no vendor pipeline is named as vulnerable. The per-chunk gating penalty was measured on multi-hop QA datasets in a different evaluation context, and the C2PA result is an analogue, not a RAG finding. None of it has been independently replicated as of 2026-11-05.

What the preprint does establish, conditional on replication, is narrower and still useful: the text-vector integrity gap is real and measurable, tolerance-based verification leaks according to a corpus property you can measure yourself, and the intuitive calibration (hardware noise) fails almost completely while the idealized calibration still leaks. Even if the specific numbers move on replication, the margin-law framing gives you the instrument: measure your own corpus’s angular-margin distribution and read the exposure off it directly.

The decision, with its conditions

Treat a document signature as covering only the text. Place integrity enforcement at the vector-store boundary: recompute embeddings where hardware allows, use the paper’s code-level verification with canonicalisation for compressed stores, or require independent attestation of shipped vectors where recomputation is not possible; attestation is this article’s extrapolation, not an option the paper measures. In any tolerance-based check, calibrate against your own corpus’s measured angular-margin distribution rather than a hardware-noise quantile. Exclude exact duplicate documents before calibrating, because duplicates moved the paper’s worst case from 1.2% to 5.5% (preprint). Audit for the four adversaries the threat model names (compromised publisher, compromised build pipeline, insider holding a content key, compromised writer of a vector store), since each one can hand consumers a validly signed pack or store. If you stack authenticity signals, cross-check them against each other; individually valid proofs can contradict. And do not reach for query-time per-chunk filtering as the backstop: on multi-hop questions it was measured worse than no filtering in every tested cell.

I would start with the margin measurement, not with new cryptography. It is the one step that is cheap, uses your own data, and tells you how large the exposed slice is under the tolerance you already implicitly accept. If your corpus answers single-hop, low-stakes questions and can tolerate a small hijack rate during evaluation, a tight float-noise-level tolerance with deduplication may be an acceptable residual risk. If a steered retrieval can redirect a customer’s funds, a clinician’s attention, or a compliance answer, the paper’s own numbers say no tolerance-based check closes the gap entirely, and the honest options are recomputation, code-level verification with canonicalisation for compressed stores, attestation with a calibrated tolerance plus auditing, or not trusting third-party vectors at all. That is a more expensive conclusion than “we signed the pack,” and it is the one the evidence supports.

Frequently Asked Questions

How much does query-time per-chunk filtering affect accuracy on multi-hop questions?

The mechanism is structural. Per-chunk verification assumes one chunk is a sufficient premise for deciding relevance. Multi-hop questions are constructed so that no single chunk suffices; the answer-bearing paragraph is often not the one the question names. So a per-chunk gate systematically discards exactly the evidence multi-hop reasoning needs. The entailment scores quantify it: AUC 0.643 on HotpotQA, 0.523 on 2WikiMultihopQA, and 0.560 on MuSiQue, versus 0.951 on single-hop SQuAD. On 2WikiMultihopQA, the scorer is barely better than chance.

What is the cost of recomputing embeddings on constrained hardware?

The preprint reports both ends of that range: the 29-minute figure came from the larger BGE-M3 model, while re-embedding its 1,745-window corpus with the smaller MiniLM model takes about a minute on the same CPU, and verification at eight pairs per second alongside generation costs the language model 23–31% of its decoding speed (preprint).