How should security teams govern RAG and agentic AI differently?

Why This Matters for Security Teams

RAG and agentic ai often get lumped into one “AI governance” bucket, but the security failure modes are different. RAG primarily expands the data boundary: it can surface restricted documents, stale content, or poisoned sources unless retrieval, ingestion, and output controls are aligned. Agentic AI expands the action boundary: once a model can call tools, open tickets, send messages, or change records, it becomes an execution path that needs runtime authorization and traceability.

This distinction matters because a control that protects retrieval does not automatically protect action. The NIST AI Risk Management Framework treats AI risk as a lifecycle issue, while the OWASP Agentic AI Top 10 focuses on risks that emerge when systems can reason and act across tools. NHIMG’s OWASP NHI Top 10 also highlights why identity-bearing workloads need tighter operational controls than static applications.

Practitioners should assume RAG can leak through bad source selection, while agents can cause harm even when the source data is clean. In practice, many security teams encounter the breach only after an agent has already taken an unintended action, rather than through intentional testing of the control boundary.

How It Works in Practice

Governing RAG starts with content provenance. Security teams should classify which corpora can be indexed, validate ingestion pipelines, and define retrieval permissions at the document, segment, or tenant level. The control question is simple: should this model be allowed to see this source at this time? Output auditing matters too, because a RAG system may faithfully retrieve material that should not be disclosed in the current context. This is a data governance problem first, and an AI problem second.

Agentic AI needs a different model. Once the system can invoke tools, the core question becomes: should this agent be allowed to do this action right now, with this context, for this purpose? That pushes teams toward least-privilege NHIs, short-lived credentials, approval gates for high-impact actions, and full tracing across tool calls. The right primitive is workload identity, not a human-style session. Standards such as CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework both point toward runtime evaluation, policy enforcement, and accountability rather than static trust.

A useful operating pattern is to separate controls by plane:

• RAG plane: source allowlists, ingestion scanning, chunk-level provenance, and retrieval logging.
• Agent plane: JIT secret issuance, task-scoped authorization, tool allowlists, and action approval workflows.
• Shared plane: policy-as-code, audit trails, and detection for prompt injection or data exfiltration attempts.

NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations report AI agents have already performed actions beyond their intended scope, which is why execution governance cannot be an afterthought. These controls tend to break down in loosely governed SaaS integrations because the agent can chain benign tools into an unsafe end-to-end workflow.

Common Variations and Edge Cases

Tighter governance often increases friction, so organisations need to balance retrieval precision against operational throughput and action safety against automation speed. That tradeoff becomes more visible in customer-facing assistants, code copilots, and back-office agents that operate across multiple tenants or business units.

Best practice is evolving for hybrid systems that do both RAG and action. Current guidance suggests splitting policy decisions by intent: retrieval requests should be judged against data-access rules, while tool calls should be judged against task scope, risk tier, and approval state. If a single policy engine is used, it should still evaluate two different questions. The NIST Cybersecurity Framework 2.0 is useful for mapping both to governance, protection, detection, and response outcomes, but it does not remove the need for AI-specific runtime controls.

Edge cases include agents that retrieve from one system and act in another, multimodal copilots that blend files, tickets, and chat logs, and workflows where a human approves the first step but not the chain of downstream actions. In those environments, the boundary between RAG and agentic execution blurs quickly. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio is a reminder that even “assistive” automation can become a credential and privilege problem when the workflow crosses trust domains.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?