RAG and agentic AI require different security controls

At a glance

What this is: This piece separates RAG from agentic AI and shows why each demands a different security model, with RAG concentrating risk in retrieval trust and agentic AI expanding it into action chains.

Why it matters: IAM, IGA, PAM and NHI teams need to govern retrieval permissions and autonomous tool use differently, or they will miss where trust, privilege and auditability actually break down.

Context

RAG and agentic AI are often discussed together, but they do not fail in the same way. RAG is a retrieval pattern that grounds model output in approved content, while agentic AI is an execution pattern that can take actions across tools and systems.

For identity and access teams, the governance gap is clear. RAG raises questions about what the model may read, while agentic AI raises questions about what a system may do, which means retrieval permissions, service account scope and approval logic cannot be treated as one control problem.

The article argues that programmes that blur the two patterns will miss both indirect prompt injection in retrieval workflows and privilege escalation in autonomous workflows. That distinction is now typical of enterprise AI deployments rather than an edge case.

Key questions

Q: What breaks when teams treat RAG and agentic AI as the same security problem?

A: The controls split at the wrong layer. RAG needs retrieval permissions, ingestion hygiene and output auditability, while agentic AI needs least-privilege service accounts, action tracing and approval for sensitive steps. If both are governed with the same policy, the programme misses where trust is actually enforced or bypassed.

Q: Why do agentic AI systems increase initial access and privilege abuse risk?

A: Because they can chain valid access into multiple tool calls without needing a human to approve each step. If a secret is exposed or a role is overbroad, the agent can turn that access into data movement, service interaction or recursive task execution. The risk rises when access outlives the task that created it.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Q: What should organisations do when an AI workflow includes both retrieval and actions?

A: Treat it as two different governance problems in one workflow. Apply document access and injection controls to retrieval, then apply identity, privilege and approval controls to the action layer. The workflow is only as safe as its weakest boundary, so each boundary needs its own control set.

Technical breakdown

RAG security starts with the retrieval layer

RAG, or retrieval-augmented generation, connects an LLM to a trusted knowledge store and inserts retrieved passages into the model's context window before generation. That means the model does not need to remember everything, but it does trust what the retrieval layer supplies. Security therefore shifts from the model itself to index governance, document hygiene, and retrieval permissions. If an attacker poisons the knowledge base or inserts hidden instructions into indexed content, the model can be steered without changing model weights. If the retrieval layer overexposes documents, the model can surface content a user should not have reached directly.

Practical implication: Align retrieval permissions to source-system permissions and treat the index as a governed access layer, not a neutral search cache.

Agentic AI security is about action authority, not answer quality

Agentic AI systems plan and execute multi-step tasks using tools such as APIs, databases, file systems and browsers. The security problem is not only what they can see, but what they can touch, modify and chain together across steps. In practice, these systems often operate with service accounts, API credentials or application identities that carry broad permissions. That creates a different control challenge from RAG: the decisive question is whether the identity can perform the action sequence at all, not whether the response was grounded. The article's distinction matters because the same model can be safe in retrieval mode and risky in execution mode.

Practical implication: Separate read-only retrieval controls from tool-usage controls and review the permission scope attached to every agent identity.

Prompt injection has a larger blast radius in autonomous workflows

Prompt injection is instruction manipulation through content the model processes. In RAG, the likely outcome is misinformation or data disclosure from the retrieval corpus. In agentic systems, the same attack can influence a sequence of tool calls, file actions and external requests, turning one manipulated prompt into a broader action chain. That is why logging a single output is not enough. The security control has to observe how instructions propagate across steps, which data moves with each step, and whether an apparently valid action becomes harmful when composed with later actions. This is a workflow problem as much as a model problem.

Practical implication: Instrument multi-step tracing across agent actions so you can see how one injected instruction changes downstream tool use.

Threat narrative

Attacker objective: The attacker wants to steer the AI system into revealing or moving data and performing actions that were never explicitly approved.

1. Entry occurs when an attacker plants malicious instructions in retrieved content or uses a crafted prompt to influence the system's next step.
2. Credential and context abuse follows when the system trusts retrieved passages or executes tools with broad service account permissions.
3. Escalation happens when a multi-step agent turns a single instruction into chained access across files, APIs or external services.
4. Impact is data disclosure or unauthorised action at a scope larger than the original prompt or query.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

RAG and agentic AI are not variants of the same control problem. RAG is a retrieval governance issue because the model reads approved content before answering, while agentic AI is an execution governance issue because the system can act across tools. Programmes that collapse both into a single AI policy will under-protect retrieval permissions and over-trust autonomous action paths. The practical conclusion is that security architects must separate read trust from act trust.

Service account privilege becomes materially more dangerous once an AI system can chain actions. In a RAG design, overbroad permissions may expose data. In an agentic design, the same overbroad credentials enable a system to combine retrieval, file access and external API calls into a task that no individual user explicitly approved. That moves the concern from output correctness to delegated authority. Practitioners should treat broad NHI permissions as the main escalation path in agentic workflows.

Prompt injection is no longer just a content integrity issue when the model can act. The same manipulative text that might only distort a response in RAG can become an operational instruction in an agentic workflow. That expands the security boundary from the knowledge base to the entire action chain, including tool selection and step ordering. The implication is that instruction hygiene, traceability and approval design now matter as much as model grounding.

Identity governance for autonomous systems needs a separate control plane from human access review. Human review cycles assume access persists long enough to be certified, but agentic systems may request, use and release permissions inside a single task sequence. That makes review-after-the-fact a weak control for the problem described here. Practitioners should reframe governance around issuance, scope and traceability at runtime rather than around periodic certification alone.

AI-aware DLP must follow actions, not just content. Traditional DLP is strongest at endpoints and discrete transfers, but agentic systems move information through API chains and multi-step workflows that can look benign step by step. The article shows why the decisive question is data lineage across the action path. For security teams, this means visibility into what the agent touched, where it moved, and which identity authorized each step.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

RAG security and agentic AI security will increasingly split into separate operating models. Security programmes that keep one policy for both will fail to see the difference between read trust and act trust. The practical shift is toward distinct governance for retrieval permissions, service account scope and step-level traceability.

Agentic action chains create an identity problem before they create a model problem. Once a system can move from one tool to the next, the control question becomes which identity is allowed to initiate each step and how that authority is recorded. That is why the governance model has to move closer to runtime execution.

AI-aware visibility is becoming a baseline requirement, not a specialist add-on. The article's central lesson is that stepwise tracing matters more than a single output log when autonomous workflows span files, APIs and external services. Security teams should expect auditability to become a design requirement rather than an afterthought.

For practitioners

• Separate retrieval controls from execution controls Map RAG workflows to document and index permissions, then map agentic workflows to tool, API and service-account permissions. Do not let one policy cover both.
• Reduce privilege on agent identities Review every non-human identity used by agents and remove broad service account access that exceeds the task scope. Scope should be task-specific, not environment-wide.
• Trace multi-step agent actions Log retrievals, tool calls, file operations and external requests as a single chain so you can reconstruct how one instruction became a sequence of actions.
• Add approval gates for irreversible actions Require explicit human approval before any agent action that moves, deletes or exfiltrates sensitive data, especially when the workflow crosses system boundaries.
• Test retrieval-layer and tool-layer injection separately Red-team RAG for poisoned knowledge and indirect prompt injection, then red-team agentic workflows for tool misuse, chained execution and privilege escalation.

Key takeaways

• RAG and agentic AI fail differently, so programmes that unify their controls will leave blind spots in either retrieval governance or execution governance.
• Agentic AI turns broad service account permissions into an escalation path because the system can combine multiple actions without human approval at each step.
• Security teams need separate controls for retrieval access, tool authority, approval gates and multi-step traceability if they want AI governance to hold up in production.

Key terms

• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.