Why do RBAC, ABAC, and ReBAC each break down when an AI agent is the caller?

Why static role, attribute, and relationship models fail for an AI agent caller

RBAC, ABAC, and ReBAC all assume that the caller’s access needs can be predicted from a stable role, a fixed set of attributes, or a known relationship. An AI agent changes that assumption. The request path, tool choice, target object, and action often emerge only during execution, so the access decision has to follow the task in motion rather than a predeclared identity shape.

That is why agents create an authorization mismatch even when the underlying policy model is sound for humans or conventional services. The model can still describe who the caller is, but it often cannot describe what the caller should be allowed to do next when the next step depends on live context, intermediate outputs, or another tool call.

For agent callers, the practical problem is not simply “too much” or “too little” access. It is that the access boundary becomes dynamic: a safe decision at the start of the run can become unsafe after the agent gathers new context, while a safe future action may not have been foreseeable when the grant was issued. That is why task-scoped and per-action authorization matter more than coarse preassignment.

What breaks in each model

RBAC breaks first on granularity. A role can say “agent,” “analyst,” or “automation,” but those labels do not capture the full spread of actions an agent may need across one run. If the role is broad enough to avoid constant failure, it usually becomes broad enough to enable unintended actions outside the immediate task.

ABAC improves on roles by checking conditions, but it still depends on attributes that are known ahead of time and evaluated as if they were stable. That works poorly when the deciding factor is not a fixed attribute but a sequence of runtime decisions, tool outputs, or user-provided instructions that change the scope of the next permitted step.

ReBAC breaks when the useful relationship is not pre-existing in the directory or graph. An agent may need to act on a record, system, or dataset because the current task just created that need, not because a stored human-readable relationship already exists. In practice, the relationship that matters is often delegated, temporary, and contextual rather than durable.

Why execution-time authority is the real control point

The central design issue is that an AI agent is not just a user surrogate. It is an autonomous software entity whose decision path can branch after each tool call, retrieval step, or user interaction. That means the security boundary should sit at the action, the token, and the decision point, not only at the label attached to the caller at login or provisioning time.

Current guidance for agent systems increasingly points to per-action policy, just-in-time access, and explicit delegation as the safer pattern. NHIMG’s AI Agent Authorisation Guide is a useful reference for that shift because it treats the authorisation decision as something that should be evaluated against the specific task step, not just the agent’s general standing.

The same logic also explains why runtime identity and privilege management matter. When the agent’s authority is short-lived and bounded to the current action, the system can reduce blast radius without forcing every workflow into a permanent high-privilege posture. That is the practical bridge from “can the agent act?” to “can the agent act only this way, now?”

Risk and Threat Considerations

When static grants are stretched to cover an agent, the main risk is privilege creep: the policy expands until it is broad enough to keep the workflow moving, then becomes a standing access path that outlives the task. That creates exposure to destructive actions, data access beyond intent, and harder-to-detect misuse when the agent’s behaviour changes run by run.

Failure mechanism: The policy model cannot express the agent’s runtime branching, so teams compensate by widening roles, attributes, or relationships until the agent stops failing closed and starts failing open.

Impact: The result is either blocked automation or overbroad access, and the latter can turn a single task into persistent permission that exceeds the original business need.

Practitioner Guidance

What to prioritise: Treat the authorisation boundary as a per-step decision problem. If the agent can choose among tools, objects, or actions, the access decision must be able to narrow itself to the current step instead of relying on a one-time grant.

What to verify: Check whether the control can answer three questions at runtime: what the agent is doing now, what object it is touching now, and whether the next action still belongs to the approved task. If any of those cannot be evaluated, the model is too coarse for agent execution.

Decision rule: Use static RBAC, ABAC, or ReBAC only for low-risk defaults and background context; use delegated, time-bounded, action-scoped controls when the agent can change its path after it starts.

Common mistake: Giving an agent a “workflow role” that is broad enough to survive every possible branch. That usually solves reliability by creating standing privilege.

Practitioner takeaway: For AI agents, the safest authorization model is the one that can shrink with the task, not just describe the caller.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• When do AI agent credentials create more risk than they reduce?