Signed Knowledge Packs Can Still Hijack RAG: Closing the Text-Vector Integrity Gap
Summary:Signed but Steerable identifies a text-vector integrity gap in offline retrieval-augmented generation: a digital signature authenticates the publisher of a knowledge pack, but it does not prove that its precomputed embedding vectors faithfully encode the included text. The paper formalizes the relationship between retrieval margins, cosine tolerance, and attack success, showing that seemingly reasonable verification thresholds can leave a large fraction of queries vulnerable. The proposed mitig
The Core Finding: Signatures Do Not Guarantee Vector Integrity
The knowledge packs studied in this work target offline RAG on edge devices. Each pack contains text together with precomputed embedding vectors and carries a publisher signature. That signature establishes who released the pack, but it does not establish that the vectors faithfully encode the text. If an attacker controls both components, the signed artifact can manipulate retrieval rankings without breaking cryptography.
The issue is a mismatch in trust boundaries. Publisher authentication and representation-integrity verification are different properties. This matters most in offline systems: edge devices may be able to check a signature or compare vectors approximately, but they often cannot afford to recompute every embedding whenever a knowledge pack is updated.
The Margin Law: Why Tolerance Determines Exposure
The paper connects attack success to the angular retrieval margin. Let (d) be the true document vector, (a) the attacker's vector, and (\tau) the cosine tolerance used by the verifier. An attack succeeds when the tampered vector is close enough to the honest reconstruction to pass verification while also being closer to the query than the legitimate document.
The central relationship is approximately:
[ P(\text{hijack}) \approx P(\text{angular margin} \leq \tau) ]
Increasing the accepted tolerance therefore admits a predictable fraction of queries near the retrieval decision boundary. The paper turns a security question into an empirical one: how large are the margins, how many near-duplicate documents exist, how does the embedding model behave, and how much of the observed error comes from numerical execution?
Across five corpora and two embedding models, margins were generally small. Even an idealized tolerance at the level of floating-point noise left up to 5.5% of queries exposed. After excluding exact duplicate documents, the maximum exposure in any individual corpus was 1.2%. The absolute rates may appear modest, but a single promoted malicious document can provide high-quality misinformation to the downstream generator.
Calibration Can Make the Problem Worse
The results show that a stricter threshold is not necessarily a safer threshold. The paper derived a threshold from an empirical 0.1% quantile of honest CPU INT8-versus-FP32 cosine differences. Under that calibration, 98%—100% of the tested attacks were exposed.
Embedding inference is not inherently bit-reproducible across batch sizes or hardware architectures. Floating-point reduction order, SIMD implementations, thread scheduling, dynamic quantization ranges, and backend-specific kernels can all alter low-order bits. An attacker does not need to reproduce the honest computation exactly; the tampered vector only needs to fall inside what the verifier considers a plausible numerical neighborhood.
A fixed cosine threshold calibrated on one machine is therefore not a portable security policy. Moving to another CPU, an ARM device, another inference backend, or a different batching regime can turn a conservative threshold into a broad attack surface.
Auditing a Compressed FAISS Index Is Not Enough
The study also examines a FAISS product-quantization index containing 57,638 documents. Product quantization divides the vector space into subspaces and stores each vector as codes selected from learned codebooks, reducing memory use while enabling approximate nearest-neighbor search.
The failure comes from checking the wrong object. Verifying that a stored vector is close to its reconstructed approximation shows that the representation is internally plausible; it does not show that the quantization code was derived from the accompanying text. In the experiments, tampered vectors that passed every audit still ranked the attacker's document first for 25% of target queries.
This is a general failure pattern: approximate reconstruction checks establish storage consistency, not semantic provenance.
A Stronger Direction: Verify Quantization Codes
The proposed mitigation validates quantization codes rather than directly comparing continuous vectors. It combines this with three mechanisms:
- Code validation checks whether the codes can be produced from the declared text under a controlled encoding process.
- Verifier-side ambiguity resolution determines the accepted interpretation when multiple encodings are possible, leaving the publisher no freedom to choose the favorable one.
- Guard bands and canonicalization provide calibrated tolerance and constrain inputs, preprocessing, and numerical execution to reduce batch- and architecture-dependent variation.
Across three platforms, the method accepted every honest vector in the evaluated samples and eliminated the publisher's ability to select between inconsistent representations. Its guarantee is stronger than approximate vector matching because it checks a traceable generation procedure rather than only the distance between two floating-point vectors.
The result should not be overstated. Accepting all honest samples does not establish a zero false-rejection rate for every embedding model, corpus, or hardware configuration. Narrow guard bands weaken security, while broad ones can enable denial of service. Quantization stability across models, batch sizes, and malicious-query distributions still requires larger-scale validation.
Why Downstream Filters Did Not Solve the Problem
The paper also reports pre-registered negative results for abstention, context pruning, and semantic screening. These methods can sometimes limit the impact of bad evidence, but they cannot substitute for retrieval-layer integrity verification.
Abstention requires the generator to recognize insufficient or contradictory evidence. A promoted malicious document can instead look highly relevant and linguistically normal. Context pruning may preserve exactly the document that the attacker worked to promote, while semantic screening can misclassify a semantically matched forgery as legitimate. A compromised retrieval stage creates convincing evidence that defeats many downstream safeguards.
Deployment Guidance
Teams operating offline RAG systems should separate publisher authentication from representation verification. Digital signatures should continue to authenticate the source, but a knowledge pack should also bind its text to the embedding model version, preprocessing configuration, quantization parameters, runtime, and a verifiable encoding procedure.
Where continuous-vector comparison is unavoidable, the error distribution should be measured on the actual target device, inference backend, and representative batching conditions. A calibrated guard band should replace a generic cosine threshold. More importantly, the publisher should not be allowed to choose among ambiguous floating-point or quantized representations; ambiguous cases should be resolved by the verifier.
The larger implication is that RAG supply-chain assurance must extend beyond file authenticity. For offline edge deployment, deterministic quantization, reproducible encoding, and hardware-aware error modeling are core integrity controls rather than optional hardening work.
— END —Source: Hugging Face Daily Papers (2026-11-04)
Tags: #RAG Security #Vector Integrity #Knowledge Supply Chain #Quantized Retrieval #Edge AI
Editorial & Fact-Checking Note: This article is compiled from primary research, official release documentation, and source papers by the ZICQ Newsroom pipeline with automated entity verification and human editorial review. If you notice any technical inaccuracy, please submit a correction via our corrections policy or email our editorial desk directly.
Community Comments