Agentic RAG vs Classic RAG: Security Risks When Retrieval Becomes Autonomous

When retrieval stops being a fixed lookup and becomes something a model plans, repeats and acts on, the security of a RAG system stops being a question about the index and becomes a question about authority. Classic retrieval augmented generation (RAG) runs one query against one index and hands the results to a model that writes an answer. Agentic RAG lets the model decide whether to retrieve, what to ask, which sources and tools to use, how many times to loop and what to do with the results. This guide compares the two designs for security: retrieval scope and permissions, injection through retrieved content that drives actions, query planning abuse, cost and denial of service, failure modes and the controls each design needs. It is written for AI platform engineers, application security teams and architects choosing between the patterns. For the controls common to every RAG system, see the RAG Security Guide.

Key takeaways

• Classic RAG risk is about what the model reads and says. Poisoned or over-shared content shapes or leaks an answer, but the retrieval path itself is fixed and auditable.
• Agentic RAG adds what the model decides and does. Retrieved text can now steer the next query, the next tool call and the next write, so one injected sentence can become a chain of actions.
• Permissions must follow the identity, not the pipeline. An agent that chooses its own sources needs every retriever and tool to enforce the caller's access, because there is no fixed query path to review.
• Loops turn cost into an attack surface. Iterative retrieval and fan-out multiply tokens and calls, so step limits and spend caps are security controls, not just finance controls.
• Choose the least autonomous design that meets the need. Many "agentic" use cases work as classic RAG with a query rewriter and a router, with far less to secure.

Definitions and architecture in words

Classic RAG

Flow: the user asks a question; the application embeds it, runs one similarity or hybrid search against a fixed index, takes the top results, places them in the prompt and asks the model for an answer, usually with citations. Any query rewriting is a single deterministic step. The model never chooses a source and never calls a tool.

Trust boundaries: the ingestion pipeline (who can write to indexed sources), the vector store (who can read and write vectors), the retriever (whose permissions filter the results) and the output handler (what the client does with links and markdown).

Agentic RAG

Flow: a survey on agentic RAG (arXiv 2501.09136) describes it as embedding autonomous agents into the RAG pipeline so that they manage retrieval strategy, refine context and adapt the workflow, using four patterns: reflection, planning, tool use and multi-agent collaboration. In practice the model decomposes the question, decides whether retrieval is needed (the idea behind Self-RAG, where the model learns when retrieval is useful and critiques passages with reflection tokens), chooses among indexes, search APIs, databases and web tools, reads results, reformulates, retrieves again and may write back to memory or call action tools. ReAct, which interleaves reasoning steps with actions such as calls to a Wikipedia API, is the common loop underneath.

Trust boundaries: everything in classic RAG, plus the planner (which sources it may pick), each tool and its credential, memory, any sub-agents, and the loop controller (how many steps, how much spend).

Threat model: classic RAG

Classic RAG threats are well catalogued. OWASP LLM08:2025 Vector and Embedding Weaknesses covers unauthorised access and leakage through misaligned access controls, cross-context leakage when data with different restrictions is combined, poisoning and embedding inversion. LLM01:2025 Prompt Injection covers indirect injection through retrieved text. In MITRE ATLAS the path runs from AML.T0064 Gather RAG-Indexed Targets to AML.T0070 RAG Poisoning, AML.T0071 False RAG Entry Injection and AML.T0066 Retrieval Content Crafting. The Threat Modelling RAG Systems guide walks through the method.

• Poisoning: PoisonedRAG reports about a 90% attack success rate from injecting five malicious texts per target question into a knowledge base of millions of texts, and found the defences it evaluated insufficient.
• Over-retrieval: the index holds documents the user should not see, and the retriever does not trim by permission. See the Permission-Aware RAG Guide.
• Exfiltration through the answer: injected text makes the model embed data in a link or image the client fetches. The EchoLeak 2025 analysis shows an external email retrieved into an assistant's context pushing internal data into a link fetched automatically.
• Secrets in the corpus: credentials in indexed documents become retrievable (ATLAS AML.T0082 RAG Credential Harvesting).

What bounds the damage: the model can only answer. The worst case is disclosure to the asking user, misleading output, or data leaving through the rendered answer. Fix the retrieval filter and the output channel and most of the risk is contained.

Threat model: agentic RAG

Every classic RAG threat remains. Agentic RAG adds four classes of risk because retrieved content is no longer only read; it is acted on.

1. Injection via retrieved content that drives actions

Greshake and colleagues showed in 2023 that attackers can plant prompts in data an LLM-integrated application is likely to retrieve and so control whether and how other APIs are called, without any direct interface to the model. In classic RAG that control ends at the answer. In agentic RAG the next step may be a tool call. The ForcedLeak 2025 case is the pattern: hidden instructions in a stored web form lead were loaded when an employee asked the agent to process it, and the agent queried other CRM records and placed the results in an image URL pointing at an expired allowlisted domain. This maps to OWASP ASI01 Agent Goal Hijack and ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation.

2. Retrieval scope and permission drift

A planner that chooses sources can reach any index or tool it is wired to. If one retriever uses a broad service credential while another trims by user, the agent will find the broad one when the narrow one returns nothing. Multi-hop retrieval also aggregates: individually permitted fragments combined across sources can reveal what no single source exposes. OWASP LLM08 warns about combining data with different access restrictions; agentic retrieval does this automatically.

3. Query planning abuse

Because the model writes its own queries, an attacker who influences the plan can steer what is fetched next. Injected text can direct the agent to search for credentials, to query a specific table, to follow a link to an attacker page that carries the next instruction, or to write a summary into memory where it will be retrieved later (ATLAS AML.T0080.000 Memory, OWASP ASI06 Memory and Context Poisoning). The query log, which in classic RAG mirrors user intent, now mixes user intent and attacker intent.

4. Cost and denial of service

OWASP LLM10:2025 Unbounded Consumption describes denial of wallet through the pay-per-use model, and ATLAS AML.T0034 Cost Harvesting notes that agentic systems can be pushed beyond normal capacity. A crafted document that tells the agent to verify every claim by searching again, or a question that fans out into dozens of sub-queries, multiplies model calls, embedding calls and paid search API calls. ATLAS AML.T0029 Denial of AI Service covers the availability side. See the Denial-of-Wallet and AI Agent Cost Runaway Guide.

Failure modes compared

Controls for each design

Classic RAG baseline

• Ingestion trust: control who can write to indexed sources, record provenance per chunk and scan for secrets before indexing.
• Permission-aware retrieval: filter by the signed-in user's entitlements at query time, partition tenants.
• Content separation: mark retrieved text as data in the prompt. The UK NCSC suggests separating data from instructions, for example with delimiting tags, while warning that this lowers likelihood rather than removing the risk.
• Output channel control: block or proxy external images and links in rendered answers.
• Logging: query, chunk IDs and source per answer. See the Vector Database Security Guide for store-level controls.

Additional controls for agentic RAG

• Bounded source catalogue: a fixed allowlist of retrievers and tools per agent, each with a declared data classification. Unknown tools fail closed, as the OWASP AI Agent Security Cheat Sheet recommends.
• Identity-carrying retrieval: every retriever and tool call carries the end user's delegated identity or an agent identity scoped to that user's task, and the data source enforces it. No retriever runs on a broad shared service credential. See Delegation Chains and Attenuated Authority for AI Agents.
• Read and act separation: keep retrieval agents read-only. Route any write, send or external call through a separate step that validates parameters against a schema and policy, and requires approval for high-impact actions. See the Human-in-the-Loop for AI Agents Guide.
• Taint tracking: mark content from untrusted sources (web, inbound email, public forms) and block tool calls whose parameters derive from tainted content without review.
• Loop budgets: maximum steps, retrieval depth, sub-queries and spend per task, with a hard stop and a logged reason.
• Memory hygiene: validate before write, isolate per user and session, expire, and log provenance. See the AI Agent Memory Poisoning Guide.
• Trajectory logging: the plan, each generated query, each source hit, each tool call with parameters and the identity used.

When to use each, and the trade-offs

Trade-offs: agentic RAG improves answer quality on complex questions at the price of higher and less predictable cost, longer latency, harder evaluation and a larger attack surface. Small teams usually get most of the benefit from classic RAG with query rewriting, hybrid search and a router. Large organisations running agentic RAG need identity and platform teams involved from the start, because the strongest controls sit in token issuance and data source authorisation. For the wider programme shift, see Agentic AI Security vs LLM App Security.

Worked scenario: an internal policy assistant goes agentic

Classic version: employees ask an assistant about HR and IT policies. It searches one index of approved policy documents, trimmed by department, and answers with citations. The security review covered who can publish policies, department filters and link rendering.

Agentic version: the team lets the assistant also search the ticketing system, the wiki and the intranet, and open an IT ticket when the answer requires one. Wiki pages and tickets are writable by any employee.

1. New injection route: any employee can now write a wiki page that the agent may retrieve for someone else, including instructions to open tickets or search for content. Mark wiki and ticket content as untrusted.
2. Permission check: confirm the ticket search runs as the asking employee, not as an integration account that sees every ticket. If the connector only supports a service account, leave that source out.
3. Action separation: the ticket tool accepts only a fixed schema (category, summary, requester is always the caller) and cannot be invoked with parameters derived from untrusted content without the employee confirming.
4. Budgets: cap each request at a set number of retrieval steps and a token budget; alert on requests that hit the cap repeatedly.
5. Testing: plant a wiki page with hidden instructions in a test tenant and confirm that no ticket is opened and no restricted ticket content appears. See the RAG Security Test Plan Template.

Detection and measurement

• Permission enforcement coverage: share of retrievers and tools that enforce the caller's identity at the data source (target 100%).
• Untrusted-to-action rate: tool calls whose parameters derive from untrusted retrieved content, and the share stopped for review.
• Loop budget hits: requests reaching step or spend caps per day; a sudden rise suggests abuse or a poisoned source.
• Cost per answered request: trend by use case; compare against the classic RAG baseline.
• Provenance completeness: share of answers and actions traceable to source chunk IDs and ingestion records.

Alert on queries that look for credentials or tokens, on retrieval of documents outside the caller's usual scope, and on outbound requests to new domains during a retrieval task.

Framework mapping

Common failure patterns

• Calling it agentic and keeping the classic review. The threat model shows one index and no tools, so tool calls driven by retrieved text are never assessed.
• One shared service credential behind every connector. The agent's reach becomes the integration account's reach, regardless of who asked.
• Retrieval and action in one agent. The component that reads untrusted text also holds write tools, which is the path seen in ForcedLeak.
• No loop budget. A single crafted document or question drives hundreds of model and search calls before anyone notices the bill.
• Relying on prompt filters. The NCSC cautions against deny-lists and against products that claim to stop prompt injection; limits must be deterministic.
• Allowlists nobody audits. Outbound allowlists that include expired or unowned domains turn into exfiltration routes.

Practitioner checklist

• Decide per use case whether classic RAG with a router is enough before adopting an agentic loop.
• List every retriever and tool the agent can reach, with its credential, data classification and whether it enforces the caller's identity.
• Remove any connector that can only run on a broad shared service credential, or isolate it to non-sensitive data.
• Separate read-only retrieval from actions; validate action parameters against schema and policy outside the model.
• Tag untrusted sources and require confirmation for actions derived from them.
• Set step, depth, fan-out and spend limits per task with a hard stop and alerting.
• Scan sources for secrets before indexing and audit outbound allowlists for expired domains.
• Log full trajectories with source chunk IDs and identities used.
• Add planted-content trajectory tests to release gates in a test tenant.

Standards and references

• OWASP GenAI Security Project: LLM08:2025 Vector and Embedding Weaknesses
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP Cheat Sheet Series: AI Agent Security Cheat Sheet
• MITRE ATLAS: RAG Poisoning
• UK NCSC: Prompt injection is not SQL injection (it may be worse)
• arXiv: Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
• arXiv: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection
• arXiv: PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation

Related NHI Mgmt Group resources: RAG Security Guide · Permission-Aware RAG Guide · Threat Modelling RAG Systems · AML.T0070 RAG Poisoning · Prompt Injection Guide