Should organisations enforce RBAC and ABAC on the AI agent itself or on the data it retrieves?

Why This Matters for Security Teams

The practical mistake is treating the AI agent as the only identity that matters. For retrieval-augmented systems, the agent is just the executor; the real risk sits in the documents, records, and APIs it can reach. If RBAC or ABAC is applied only to the agent, a compromised prompt, a poisoned tool call, or an overbroad connector can still expose data the user should never see. That is why current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework points toward context-aware controls at decision time, not just agent-level permissions.

NHIMG research shows why this matters operationally: only 52% of companies can track and audit the data their AI agents access, leaving 48% with a compliance and breach-investigation blind spot in AI Agents: The New Attack Surface report. In practice, many security teams discover the failure only after an agent has already retrieved, summarized, or forwarded information outside intended scope.

How It Works in Practice

The stronger pattern is to treat the agent as an authenticated workload that acts on behalf of a user, then evaluate authorization at each retrieval and response step. That means the agent may hold a workload identity, but the effective entitlement is derived from the user session, request context, and policy rules. In mature designs, the agent does not get blanket read access to a database or knowledge base. It receives short-lived, task-specific permission to request one record set, one document class, or one API operation.

This is where RBAC and ABAC belong: on the data access path, connector, query broker, retrieval layer, or downstream service. Static role checks can still help define coarse boundaries, but they are not enough when the agent can chain tools, rephrase requests, or pivot across datasets. The emerging best practice is intent-based authorization, evaluated at runtime with policy-as-code. That aligns with the direction of the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework.

Operationally, teams usually need four controls:

• Map the user’s entitlements into the retrieval request, not just into the agent’s launch permissions.
• Issue short-lived credentials or tokens per task, then revoke them when the interaction ends.
• Log the exact data objects, queries, and tool calls the agent touched for auditability.
• Apply deny-by-default rules for sensitive scopes, especially when the agent can summarize or export content.

This model is reinforced by NHIMG’s analysis of real-world failures in OWASP NHI Top 10, where agentic systems are repeatedly exposed through over-permissioned integrations rather than a single broken login. These controls tend to break down when the agent has direct, long-lived database credentials because policy checks get bypassed at the source.

Common Variations and Edge Cases

Tighter data-path authorization often increases integration complexity, so organisations must balance precision against latency, connector sprawl, and user friction. There is no universal standard for agent-specific authorization yet, and current guidance suggests a layered approach rather than a single control point.

One edge case is internal copilots that only search a narrow corpus. In those environments, coarse RBAC at the agent may appear sufficient, but ABAC still becomes important as soon as the agent filters by department, case status, geography, or secrecy level. Another case is multi-agent workflows, where one agent retrieves data and another drafts a response. Each hop needs the same entitlement context, or the second agent can unintentionally widen disclosure.

Security teams should also avoid assuming that workload identity alone solves the problem. A strong identity for the agent helps prove what the agent is, but it does not determine what it is allowed to see. The point is to combine workload identity with runtime policy evaluation, as emphasized in MITRE ATLAS adversarial AI threat matrix and the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research. If the environment uses legacy connectors or shared service accounts, the recommended pattern degrades quickly because entitlement boundaries are no longer visible at request time.

Related resources from NHI Mgmt Group

• How should organisations govern customer and AI agent authentication when using app development partners?
• How should organisations justify attendance at a data governance event when data quality and AI readiness are business risks?
• How should organisations govern unstructured data for AI use cases without creating manual bottlenecks?
• What breaks when organisations cannot audit AI agent actions in customer workflows?