KidnapRAG: Poisoning the Reasoning Chain of Agentic RAG
What happens when the attacker stops trying to fool retrieval and starts steering the agent's *next question*? That is the shift documented in KidnapRAG (arXiv:2607.00422), a black-box poisoning technique aimed square…
KidnapRAG: Poisoning the Reasoning Chain of Agentic RAG
What happens when the attacker stops trying to fool retrieval and starts steering the agent’s next question? That is the shift documented in KidnapRAG (arXiv:2607.00422), a black-box poisoning technique aimed squarely at Agentic Retrieval-Augmented Generation. Single-shot corpus poisoning is yesterday’s problem. Multi-hop hijacking is here.
Why agentic retrieval breaks classic threat models
Traditional RAG poisoning assumes one query, one retrieval, one answer. Agentic RAG breaks that assumption: the LLM plans, retrieves, re-plans, retrieves again, and reasons over the accumulated evidence. Each hop is a new attack surface. KidnapRAG exploits this by publishing three role-specific documents into the corpus — Bait, Chain-Link, and Mal-Ins — engineered to be picked up at different stages of the reasoning chain. Bait wins the first retrieval; Chain-Link seeds the follow-up sub-query the agent will generate; Mal-Ins carries the final instruction the agent executes on. The authors report the attack outperforms prior poisoning baselines across multiple Agentic RAG frameworks and LLM backbones.
The relevant defensive frame is not “was this document malicious?” but “did the trajectory drift?”. That distinction matters because ENISA’s 2024 Multilayer Framework for Good Cybersecurity Practices for AI treats data-supply-chain integrity as a system-level property, not a per-document check. The EU AI Act reinforces this at Article 15 on accuracy, robustness and cybersecurity, which applies to high-risk systems built on retrieval components.
How the three documents cooperate
The elegance — and the danger — is that no single document looks anomalous under semantic similarity screening. The payload lives in the sequence, not the tokens.
What defenders should actually change
A concrete detection posture that we recommend to teams shipping Agentic RAG in production:
agentic_rag_guardrails:
trajectory_audit:
enabled: true
log_hops: all
alert_on_intent_drift: cosine < 0.42
retrieval_provenance:
signed_sources_only: true
reject_unsigned_after: 2026-01-01
planner_isolation:
subquery_llm_call: sandboxed
max_reasoning_hops: 4
incident_retention_days: 365Three practices carry disproportionate weight. First, log the full retrieval trajectory — not just the final context window — so intent drift between hops is measurable. Second, sign your source corpus at ingestion; unsigned chunks should not reach the planner. Third, cap reasoning depth. KidnapRAG needs 3+ hops to complete; a hard ceiling of 2 hops for high-stakes queries neutralises the attack pattern without killing utility. This aligns with the layered controls we describe in our note on securing RAG pipelines end-to-end and the topology-first stance we take on agent runtime safety.
For teams already on NIST AI RMF or the OWASP LLM Top 10 (LLM04: Data and Model Poisoning), KidnapRAG is not a new category — it is a proof that existing categories must be evaluated at trajectory granularity.
The CAI position
We do not treat Agentic RAG as a document-security problem. We treat it as a control-flow problem, and we instrument the planner as if it were a privileged process. If your evaluation harness only measures answer accuracy on gold questions, you are blind to this class of attack. Talk to us about pipeline-level RAG assurance before your next production release.