TL;DR: AI agents chain tools, delegate to sub-agents, and keep acting after the first prompt, so authorization must answer who is acting, for whom, on what resource, through which tool, right now, according to PermitIO. RBAC sets boundaries, but ReBAC plus runtime conditions is the only model that can reliably govern delegated agent actions at execution time.
At a glance
What this is: This analysis compares RBAC and ReBAC for AI agents and concludes that runtime authorization needs relationship-aware policy, not role lookup alone.
Why it matters: IAM and security teams governing autonomous or delegated agent actions need authorization decisions that account for who delegated, which agent is acting, what resource is touched, and what conditions still hold.
Context
AI agent authorization is a governance problem, not just an access model problem. The question is no longer whether a principal can log in, but whether a delegated agent can take a specific action on a specific resource through a specific tool at the moment of execution.
RBAC can define broad boundaries, but agentic workflows introduce delegation chains, sub-agents, tenant scope, and runtime conditions that role checks cannot resolve cleanly. In practice, that makes relationship-aware authorization a control-plane requirement for AI agents, not an optional refinement.
The article's central claim is that production agent authorization usually combines RBAC, ReBAC, and conditions. That is a typical agentic systems problem, not an edge case.
Key questions
Q: What should teams do when AI agents act on behalf of real users?
A: Treat the agent as a scoped identity with explicit permissions, audit trails, and revocation rules. The human owner should be verified strongly, but the agent still needs its own access boundaries. That prevents delegated activity from becoming invisible shadow access.
Q: Why do role-based permissions fail for delegated agent actions?
A: Roles are too coarse for the moving parts in agentic workflows. A role can say what an agent class may attempt, but it cannot fully express who delegated the work, which resource is in scope, whether a sub-agent inherited the right context, or whether the action still fits current conditions.
Q: What breaks when token scope is the only control for AI agents?
A: When token scope is the only control, the agent remains free to act long after the original task context has changed. That creates a mismatch between what was approved at issuance and what is actually happening at runtime, which is exactly where overreach and unintended access appear.
Q: Should organisations enforce AI agent permissions at a gateway or inside each tool server?
A: Enforce them at a centralized policy layer, ideally at or near the gateway, so every MCP or API action is evaluated consistently. If each tool server applies its own logic, delegation, tenant scope, and runtime conditions will drift and auditability will suffer.
Technical breakdown
Why RBAC becomes incomplete in agentic authorization
RBAC works by assigning broad permissions to roles, which is useful when the actor and action are stable. AI agents break that assumption because the same workflow may involve human delegation, tool calls, sub-agent execution, and different tenant or resource scopes within one session. At that point, a role answer such as “refund agent” does not capture whether this agent may act for this user, on this object, through this tool, right now. RBAC still matters as a boundary layer, but it cannot express the full delegated execution context that agentic systems require.
Practical implication: use RBAC for coarse permission families, but do not treat role membership as a sufficient runtime authorization decision for agent actions.
How ReBAC models delegated agent identity
ReBAC represents authorization as relationships between subjects, delegators, resources, and tenants rather than only as static role labels. For AI agents, that means the principal is effectively a delegated execution identity: a human grants authority, an agent executes, a tool is invoked, and a resource is touched within an isolation boundary. This model aligns with how agentic systems actually behave because authorization can follow the chain of delegation and resource ownership instead of guessing from a single role or scope token. It also supports derived permissions when the relationship graph is the real policy source.
Practical implication: encode acts-for, tenant membership, and resource ownership relationships so the policy engine can evaluate delegated authority at the point of use.
Why runtime conditions are the missing control layer
Even relationship-aware authorization is not enough if the system ignores live context. Agentic decisions often depend on amount thresholds, time windows, risk signals, environment, and request metadata that can change between prompt and tool invocation. That is why the article treats conditions as a third layer alongside RBAC and ReBAC. The important technical point is that conditions turn authorization from a static grant into a per-call decision, which is essential when an agent can continue acting after the first prompt or pass work to a sub-agent. Without those checks, policy can be correct on paper and wrong in execution.
Practical implication: enforce contextual policy on every tool call so runtime risk, not just identity shape, determines the decision.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
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
Delegated agent identity is a different authorization object from a user or service account. The article is correct to treat the human delegator, the agent, the tool, the resource, and the tenant as one decision context. That is not a cosmetic extension of IAM, but a structural shift in what the policy engine must evaluate. Practitioner conclusion: agent authorization has to be modeled as delegated execution, not as a renamed user session.
RBAC is still the boundary control, but it cannot carry runtime trust alone. Role models answer which classes of actions an agent may ever attempt, yet agentic systems require a second question about whether the delegated relationship is valid for this exact call. That makes RBAC necessary but incomplete, especially where sub-agents or cross-resource workflows exist. Practitioner conclusion: use roles to constrain scope, then require relationship checks for every sensitive action.
ReBAC is the right precision layer because agent behaviour is relational by design. The article's strongest contribution is the reminder that AI agent authorization is not just about token scope, but about who acts for whom on what resource under which tenant boundary. That is exactly the kind of graph-shaped policy problem ReBAC was built to express. Practitioner conclusion: if your authorization data model cannot represent delegation edges, it will eventually over-permit agent actions.
Runtime conditions are the control that stops delegated access from becoming persistent trust. Amount, risk, and environment checks matter because agent workflows can change state faster than human review cycles can react. This is where many agentic systems drift into approval theatre: the policy was valid at grant time but stale at execution time. Practitioner conclusion: move the decisive check to the moment of tool invocation, not to onboarding or role assignment.
Relationship-aware authorization will become the default governance pattern for agentic systems. As MCP adoption expands and agents chain tools more freely, centralized policy enforcement becomes the only practical way to keep delegation visible and auditable. That does not replace identity governance; it makes identity governance more precise by binding authority to delegation, resource ownership, and runtime context. Practitioner conclusion: expect agentic authorization to converge on policy enforcement points, not embedded trust inside each tool server.
From our research library:
- 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Delegated execution identity: AI agents create a policy problem that is closer to relationship governance than to traditional user session control. When one principal can act on behalf of another, the authorization decision has to follow the delegation chain, the resource boundary, and the tenant boundary together. Security teams should expect their IAM and PAM assumptions to be tested at runtime, not only at provisioning time.
Static role models do not disappear in agentic systems, but they move down to the boundary layer. The real control point becomes the policy engine that can evaluate relationships and conditions on every tool invocation, which is why gateway-enforced authorization is becoming a practical requirement for production agents.
For practitioners
- Define delegated execution identities Model the human delegator, agent identity, tool action, and resource as separate decision inputs so policy can evaluate the real execution chain instead of a single token or role.
- Enforce relationship checks at the policy layer Store acts_for, member_of, and resource ownership relationships centrally, then require them in every sensitive tool decision so delegated authority is explicit and auditable.
- Add runtime conditions to tool calls Require contextual checks such as amount limits, tenant scope, risk score, and environment before approving high-risk actions performed by agents or sub-agents.
- Route every MCP action through a policy enforcement point Do not trust direct model-to-tool paths to self-govern access. Enforce each MCP or API call through a centralized gateway and decision engine so policy remains consistent.
Key takeaways
- AI agents change authorization from a role check into a delegated execution decision that must account for who delegated, what tool is used, and what resource is touched.
- The strongest evidence in the article is that RBAC alone cannot express runtime context, while ReBAC and conditions can model delegation, tenant scope, and live constraints more accurately.
- Practitioners should centralize policy enforcement and treat AI agent authorization as an execution-time control, not as a static access grant.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Delegated agent actions depend on identity and privilege boundaries that can be mis-scoped at runtime. |
| ASI02 — Tool Misuse | The article centers on tool calls that must be policy-checked rather than trusted by default. | |
| Recommendation — Model delegated agent authority so identity and privilege checks occur on every tool invocation. Gate every agent tool call through policy checks before execution. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about governing agent authorization decisions and accountability across delegated actions. |
| Recommendation — Establish governance for delegated AI actions and define who approves policy exceptions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime authorization for agents is fundamentally an access permissions and entitlement problem. |
| Recommendation — Apply entitlement controls so AI agent access is validated against current authorization context. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | RBAC baseline boundaries and delegated scopes both rely on least-privilege authorization. |
| Recommendation — Constrain agent permissions to the minimum rights needed for each delegated action. | ||
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: An access model where entitlements are justified by the current business relationship, such as employee, contractor, student, vendor, or service account status. In practice, the relationship defines scope, duration, ownership, and review requirements.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org