RAG-PIBench: A Leakage-Aware Benchmark for Prompt-Injection Detection in Trustworthy RAG Systems

What it is

RAG-PIBench is a benchmark dataset and evaluation protocol for detecting indirect prompt injection in RAG systems, built from named source corpora: host documents from WikiText-2, CNN/DailyMail, and SQuAD, and payload content from S-Labs, PromptShield, Natural Instructions, and BIPIA.

How it works

Each example renders a host context with an embedded payload (benign or malicious), using multiple wrapper styles and variable insertion positions. The construction pipeline has four phases: source registration/provenance tracing, human-centered quality review, contextual rendering with leakage/shortcut auditing (checking for duplicate content, split contamination, repeated templates, and source-specific markers), and frozen split materialization. The dataset splits into Train (2,936), Validation (962), and a Protected Test set (978) — opened only once, for a single final evaluation pass, with no tuning or diagnostic reuse permitted on it. Seven detectors were compared: Keyword heuristic, MiniLM semantic-reference similarity, TF-IDF with LR/SVM/Random Forest, DistilBERT, and DeBERTa-v3.

flowchart LR
    A[Source registration] --> B[Quality review]
    B --> C[Rendering + leakage/shortcut audit]
    C --> D[Frozen splits]
    D --> E[Train 2936]
    D --> F[Validation 962]
    D --> G[Protected Test 978<br/>opened once]
    G --> H[Final metrics only]

Preconditions / Affected

Applies specifically to text-only, English-language RAG pipelines where a detector screens retrieved content before generation; the threat model excludes query/system-prompt tampering, downstream attack execution, tool misuse, exfiltration, and retrieval poisoning — it measures detection only, not end-to-end defense.

What to do

Use the frozen splits as given rather than re-splitting the data yourself: evaluate models on Train/Validation during development, and run the Protected Test split exactly once for reported results, since the paper's core argument is that re-using or re-shuffling test data (or tuning against it) is what inflates reported detector performance in prior benchmarks. If building a lightweight detector, TF-IDF with SVM or logistic regression is presented as a competitive, cheaper alternative to transformer models (DistilBERT/DeBERTa-v3) — worth trying first before committing to a transformer pipeline.

Caveats

Host-document and payload-parent sourcing is imbalanced (e.g., 42.9%/42.9%/14.3% across the three host corpora; payload parents drawn from pools of only 192 sources per class), which the page itself flags via its source-composition breakdown rather than asserting generalizability beyond these corpora.