Securing RAG Pipelines: Threats Across Retrieval and Generation
A new arXiv survey (Security and Privacy in RAG, June 2026) maps the attack surface of Retrieval-Augmented Generation across four deployment shapes — centralized, on-device (Micro-RAG), federated, and hybrid — and the…
Securing RAG Pipelines: Threats Across Retrieval and Generation
A new arXiv survey (Security and Privacy in RAG, June 2026) maps the attack surface of Retrieval-Augmented Generation across four deployment shapes — centralized, on-device (Micro-RAG), federated, and hybrid — and the picture is uglier than most engineering teams assume. Membership inference, index inference, poisoning, gradient leakage, and collusion are no longer academic. They land in production logs.
The authors organize threats by pipeline stage. That framing matters because most RAG postmortems blame “the model” when the real failure lives in the retriever or in context assembly.
Where the attacks actually land
Retrieval is the most exposed stage. An attacker who can write to the corpus — directly, or via a poisoned upstream feed — can shape every downstream answer. The survey catalogues poisoning variants that survive embedding normalization and re-ranking. Membership inference targets the index: a crafted query can confirm whether a specific document (a customer contract, a patient record) sits in the store. The EU’s General Data Protection Regulation treats that as a personal-data disclosure under Art. 4(2) GDPR, regardless of whether the document content is returned.
Context construction is the silent stage. Prompt injection arriving through retrieved chunks bypasses the input-side filters that most teams instrument. ENISA’s threat landscape briefing flags indirect prompt injection through retrieved content as the dominant LLM failure mode of 2025–2026 production systems.
Generation leaks through gradients during fine-tuning and through verbose outputs during inference. Federated RAG is the worst case: gradient leakage attacks recover training fragments from shared updates, a class of attack NIST’s AI Risk Management Framework flags as high-severity for cross-organization deployments.
# rag_audit_policy.yaml
retrieval:
log_query_hashes: true
block_metadata_echo: true
poisoning_canary_docs: 12
context:
injection_detector: enabled
max_chunks_per_prompt: 6
generation:
output_pii_filter: strict
gradient_clip_norm: 1.0
retention_days: 90A defensive topology, not a defensive feature
The survey’s cryptographic defenses — secure aggregation, differential privacy, trusted execution environments — work only when wired into a topology. Bolting differential privacy onto a leaky retriever is theater. Our work on agentic system safety reinforces the same idea: security lives in the graph between components, not in any one component’s hyperparameters. The same logic ties the RAG pillar to the intrusion-detection layer feeding the retriever its threat signal.
What we tell clients
CAI Technology treats RAG security as a topology problem governed by three audit gates: signed-source provenance at ingest, canary-doc poisoning detection at retrieval, and PII residue scanning at output. Under the NIS2 Directive (EU) 2022/2555, the audit trail for these gates is itself a compliance artifact for essential-entity operators. If you are building a RAG system that touches customer data, start with the RAG pillar overview before picking a vector store.