Agentic AI and RAG Pipelines

A language model that can only generate text is a tool with bounded risk. It can produce misleading content, leak information embedded during training, or exhibit biased behavior — but its impact is limited to the text it outputs. The moment you give that same model the ability to call functions, query databases, read files, or make HTTP requests, the risk profile transforms fundamentally. The model is no longer just generating text; it is taking actions in the world with whatever permissions the deployment grants it. A backdoor in a text-only model is a concern. A backdoor in an agentic model with access to internal APIs and a file system is a potential breach.

This chapter explains the two architectural patterns that create this elevated risk: agentic AI (LLMs with tool-use capabilities that can plan and execute multi-step operations) and retrieval augmented generation (RAG, where external documents are retrieved and injected into the model’s context at inference time). These are not exotic configurations — they are the standard architecture for enterprise LLM deployments. If your organization uses an LLM to answer questions about internal documents, you likely have a RAG pipeline. If it can send emails, create tickets, or query databases on behalf of users, you have an agent. The threat analysis in Part II assumes both.

Scenario A in Chapter 104 is built entirely around a RAG-enabled agent processing internal documents, and it is the highest-severity scenario in the book. The tool-use exploitation analysis in Chapter 102 depends on readers understanding how function calling works mechanically — not just conceptually, but at the level of how tool definitions are structured, how the model selects and parameterizes tool calls, and how results flow back into context. This chapter provides that foundation.

The core security insight is that agentic architectures and RAG introduce a new class of vulnerability: the model becomes a confused deputy, executing actions on behalf of instructions it cannot distinguish from legitimate user requests. Chapter 009 covers the injection vulnerability that enables this; this chapter explains the architecture that makes it consequential.

What Makes an LLM an “Agent”

An LLM becomes an “agent” when it operates in a loop — observing its environment, deciding on actions, executing those actions through tool calls, observing the results, and deciding what to do next. This section defines the properties that distinguish an agent from a single-shot text generator: planning capability (decomposing a goal into steps), tool selection (choosing which capability to invoke), execution (actually calling the tool), and iteration (using tool results to inform the next step). The distinction matters for security because each iteration through the loop is an opportunity for the model to act on injected instructions or to direct outputs to unintended destinations.

Function Calling and Tool Definitions

Function calling is the mechanism that gives models access to external tools. This section explains how it works concretely: tool definitions are provided to the model as structured schemas (typically JSON) that describe available functions, their parameters, and their return types. The model generates structured output that specifies which function to call and with what arguments, and the runtime environment executes the call and returns the result. The model never calls functions directly — it generates a request that the framework executes — but this mediation layer is thin and usually unvalidated. Understanding this mechanism is essential because tool call arguments are where many exploitation payloads are delivered (Chapter 102).

ReAct and Agent Reasoning Patterns

ReAct (Reason + Act) is the dominant pattern for LLM agents: the model produces a chain of thought-action-observation steps, where each thought explains its reasoning, each action invokes a tool, and each observation integrates the tool’s result. This section covers ReAct and its variants, explaining how the reasoning trace structures the agent’s behavior and how each step in the chain introduces both capability and risk. From a security perspective, the reasoning trace is significant because it means the model is explicitly planning its actions — and adversarial instructions injected through prompt injection can influence that planning process.

Multi-Step Tool Chains

Many agent tasks require multiple sequential tool calls, where each call depends on the results of previous calls. This section explains how multi-step chains work: the model retrieves a document, extracts a value, uses that value to query a database, and formats the result as a response. Each step in the chain is a point where the model’s behavior can be influenced by the data it processes. Multi-step chains are particularly relevant to exfiltration scenarios: an adversary who can influence one step (for example, by injecting instructions in a retrieved document) may be able to redirect subsequent steps to exfiltrate data through a tool call. Chapter 104’s Scenario A demonstrates this attack chain in detail.

Retrieval Augmented Generation (RAG)

RAG is the pattern of augmenting a model’s knowledge by retrieving relevant documents from an external corpus and inserting them into the model’s context before generation. This section covers the end-to-end RAG architecture: the document is chunked and embedded (converted to vector representations), stored in a vector database, retrieved at query time based on semantic similarity to the user’s question, and injected into the model’s prompt as additional context. RAG is ubiquitous in enterprise deployments because it allows models to answer questions about proprietary data without fine-tuning. It is also the primary mechanism by which untrusted content enters the model’s context window — making it the delivery vector for indirect prompt injection (Chapter 009).

Vector Databases and Embedding Similarity

RAG retrieval depends on embedding models and vector databases, and this section covers how they work: documents are converted to fixed-dimensional vector representations using an embedding model, stored in a database optimized for similarity search, and retrieved based on cosine similarity or other distance metrics. The choice of embedding model matters for security because it determines what gets retrieved — and embedding models are themselves a supply chain component that may originate from untrusted sources. Chapter 010 covers embedding models in detail; this section establishes their role in the RAG architecture.

The RAG Attack Surface

This section maps the attack surface specific to RAG deployments. Poisoned retrieval occurs when an adversary places malicious content in the document corpus that is designed to be retrieved for specific queries. Injected context occurs when retrieved documents contain prompt injection payloads that the model follows as instructions. The confused deputy problem arises when the model acts on injected instructions using its legitimate tool access. Each of these attack vectors is analyzed in detail in Chapter 102; this section establishes the architectural reasons why RAG systems are vulnerable and why the vulnerabilities are inherent to the design rather than implementation bugs that can be patched.

How Tool Access Transforms Threat Models

The closing analytical section makes the case that tool access is the critical threshold for LLM threat severity. Without tool access, a compromised model can generate misleading text but cannot directly take actions. With tool access, the same model can read files, make network requests, modify data, and interact with external systems — all under the guise of fulfilling a user request. This section frames the threat model transformation: adding tool access does not just add new attack vectors, it elevates existing vectors from “influence” to “system compromise.” This framing is used directly in the risk scoring methodology in Chapter 105.

Key Takeaway: Agents and RAG Are Where the Highest-Severity Threats Live

This chapter’s closing section connects the architectural concepts to Part II’s risk assessment. The highest-severity scenarios in the book — those involving data exfiltration, system compromise, and lateral movement — all require agentic capabilities. The most common entry point for adversarial influence — indirect prompt injection through retrieved documents — requires RAG. Organizations that deploy LLMs as text generators face a different (and lower) risk profile than those that deploy LLMs as agents with tool access and document retrieval. Understanding this distinction is essential for the tiered recommendations in Chapter 107.

Summary

[Chapter summary to be written after full content is drafted.]