RBAC vs ReBAC for AI agents: where runtime authorization breaks

At a glance

What this is: This analysis argues that AI agent authorization needs more than RBAC because delegated, tool-driven actions require relationship-aware decisions at runtime.

Why it matters: It matters because IAM teams now have to govern delegated agent behaviour, not just human logins or static service accounts, and the decision point moves to every tool call.

👉 Read PermitIO's analysis of RBAC vs ReBAC for AI agent authorization

Context

AI agent authorization is a runtime governance problem, not a one-time role assignment problem. An agent can chain tools, call APIs, and continue acting after the initial prompt, so the real question is whether each action is still allowed for that delegator, resource, tenant, and context at the moment of execution.

That shifts the identity problem from coarse permissions to delegated execution identity. For practitioners building controls around AI agents, the core issue is not whether authentication succeeds, but whether authorization can stay precise enough to enforce scope, delegation, and tenant boundaries across an active workflow.

Key questions

Q: How should security teams authorize AI agents that act on behalf of humans?

A: Use RBAC for broad boundaries, ReBAC for delegated and resource-aware decisions, and runtime conditions for risk-sensitive actions. The key is to authorize each tool call against the delegator, resource, tenant, and current context, not just the agent’s login state or token scope.

Q: Why do RBAC policies often fail for AI agent governance?

A: RBAC fails when the real decision depends on delegation, tenant scope, sub-agent propagation, or changing runtime conditions. A role can say an agent category may attempt an action, but it cannot reliably decide whether this exact action is allowed on this exact resource right now.

Q: What breaks when delegated context is missing from agent authorization?

A: Without delegated context, an agent may appear authorised even when it is acting outside the human’s intent, outside the tenant boundary, or beyond an allowed business limit. That creates over-permissioning, weak auditability, and inconsistent enforcement across tool calls.

Q: Who is accountable when an AI agent makes an unauthorised action?

A: Accountability sits with the organisation that defined the delegation model, enforced the policy, and approved the agent workflow. If the policy layer cannot explain who delegated authority, what resource was touched, and why the action was allowed, accountability is already incomplete.

Technical breakdown

Delegated execution identity in AI agents

In agentic systems, the principal is not just the signed-in human or the service account. The security object becomes a delegated execution identity, which combines the human delegator, the agent acting on their behalf, the tool being invoked, the resource targeted, and the tenant or workspace boundary. That matters because each tool call can represent a new authorization decision even when the session is continuous. If policy only understands the login event, it misses the actual decision surface where agentic systems create risk.

Practical implication: model agent identity, delegator context, and resource scope as first-class inputs to every authorization decision.

Why RBAC sets boundaries but not runtime precision

RBAC is useful for coarse control because it answers which classes of actions an agent category may ever attempt. For example, it can separate refund review from refund approval or restrict certain tool families entirely. But RBAC does not naturally express whether this agent may act for this human on this exact resource in this tenant right now. As soon as delegation, sub-agent propagation, and amount or risk thresholds enter the workflow, role lookup alone becomes too blunt to represent the real security decision.

Practical implication: use RBAC to define the outer boundary, not to approve every agent action.

ReBAC and conditions for delegated agent authorization

ReBAC works better for AI agents because it models relationships rather than just membership. It can express who delegated authority, which agent acts for whom, which resource belongs to which tenant, and whether the tool call is inside the delegated chain. Conditions such as amount, time, environment, or risk score then add runtime precision without hardcoding business logic into each service. In practice, that makes the policy engine the place where delegated authority is evaluated per request, not inferred from a token alone.

Practical implication: evaluate delegated relationships and runtime conditions at the policy enforcement point for every agent tool call.

Threat narrative

Attacker objective: The attacker objective is to abuse delegated agent authority so the system performs actions or reaches resources that the original human did not truly authorise.

1. Entry occurs when a delegated agent receives a valid token or tool path that appears authorised at login time but does not yet prove per-action scope.
2. Escalation occurs when the agent chains tools or spawns sub-agents, expanding the effective action path beyond what the original delegation intended.
3. Impact occurs when overbroad or stale authorization lets the agent touch the wrong resource, exceed delegated limits, or complete an unsafe transaction.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

RBAC is the boundary layer, not the decision layer, for AI agents. In agentic systems, a role can say what a class of agent may attempt, but it cannot capture the full delegated context of who asked, what resource is targeted, and whether the action is still in scope at execution time. That makes RBAC necessary but structurally incomplete for production agent governance. Practitioners should treat RBAC as the outer guardrail, not the final authoriser.

Delegated execution identity is the named control concept this category needs. AI agents do not behave like static service accounts, because they can keep acting, chain tools, and propagate authority into sub-agents within one workflow. That means identity governance must reason over delegation chains, resource relationships, and tenant scope together, rather than relying on token scope or role membership alone. Practitioners should make delegated execution identity a core part of their authorization model.

ReBAC becomes the precision layer when authority is relational rather than positional. The central problem is not just whether an agent has access, but whether it has access for this delegator, this resource, and this business context now. Relationship-aware policy gives teams a way to encode that reality without scattering custom checks across every MCP or API integration. Practitioners should move high-risk agent flows toward relationship-driven decisions, not broad role grants.

Conditions are what keep delegated permissions from becoming permanent permissions. Amount thresholds, time windows, risk signals, and environment checks turn agent authorization into a runtime decision instead of a static grant. That matters because a delegated agent can be correct at one moment and unsafe at the next as context changes during execution. Practitioners should combine RBAC, ReBAC, and conditions as a single policy model rather than as separate controls.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint research.
• For a broader view of the control problem, OWASP NHI Top 10 frames the agentic risk surface that RBAC alone does not cover.

What this signals

Delegated execution identity will become a design requirement, not an architecture preference. Teams that keep treating agent permissions as a thin extension of human RBAC will keep missing the real control point, which is per-action delegation. The practical shift is toward policy decisions that can inspect the human, agent, resource, tenant, and runtime context together, with OWASP NHI Top 10 as a useful external frame for the risk surface.

AI agent governance will expose how much of IAM still assumes stable, reviewable permissions. Once an agent can chain actions inside a workflow, the programme must know whether the policy engine sees the same authority that the business believes it delegated. That is especially true when only 52% of companies can track and audit the data their AI agents access, according to the 2026 AI Agents report.

Relationship-aware policy is becoming the operational bridge between identity and application control. The organisations that will move fastest are the ones that stop hardcoding agent exceptions into apps and instead centralise delegation logic in one policy layer. That keeps tenant isolation, tool-level enforcement, and auditability aligned as agent use expands.

For practitioners

• Model delegated agent identity explicitly Represent the human delegator, parent agent, child agent, resource, and tenant as separate policy inputs so authorization can evaluate the real execution chain instead of a generic token. Use the delegated chain as the audit object for every high-risk tool call.
• Enforce every tool invocation through a policy engine Route MCP and API actions through a centralized enforcement point so the decision is checked at runtime, not assumed from prior login or pre-approved scope. This is the place to validate delegated authority, resource ownership, and tenant boundaries.
• Apply condition checks to high-risk agent actions Add runtime controls for amount, time, environment, and risk so the same agent can be allowed for low-risk tasks but denied when the business context changes. Conditions are what stop delegated access from drifting into open-ended access.
• Test stale delegation and sub-agent overreach Run failure drills for expired human delegation, cross-tenant requests, and child agents that inherit more privilege than intended. These scenarios show whether relationship data and propagation logic are actually being enforced or only documented.

Key takeaways

• AI agent authorization fails when teams rely on login-time roles instead of runtime delegation checks.
• Relationship-aware policy is the control that makes delegated agent access precise enough for production use.
• RBAC, ReBAC, and conditions work together because no single layer can safely govern tool-chaining agents alone.

Key terms

• Delegated Execution Identity: The identity a system uses when an agent acts on behalf of a human or another agent. It includes the delegator, the executing agent, the target resource, and the policy context needed to decide whether the action is still within scope.
• Relationship-Based Access Control: An authorisation model that grants or denies access based on relationships between subjects, resources, tenants, and delegated roles. In agentic systems, it is useful because authority is often expressed through who acts for whom, not just through static role membership.
• Policy Enforcement Point: The control point where an access decision is actually applied. For AI agents, that means checking every tool call or API action at runtime so the policy engine can evaluate delegation, resource scope, and current conditions before the action executes.
• Runtime Condition: A live context check such as amount, time, environment, or risk score that affects whether access should be allowed now. For agents, runtime conditions prevent a delegated permission from becoming an open-ended permission across the whole workflow.

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 responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by PermitIO: RBAC vs ReBAC for AI Agents: Best Authorization Model for Secure Agentic Systems. Read the original.