Per-hop RBAC becomes too coarse when a role can describe the actor but not the delegation context. If the policy needs to express who is acting, on whose behalf, which resource is in scope, how long access lasts, and which workflow triggered the request, role checks will be blunt. Those conditions require attribute-based evaluation, not static role membership.
When per-hop roles stop capturing delegation context
Per-hop RBAC becomes a poor fit once the policy question is no longer simply “what can this role do?” but “what is this agent allowed to do in this exact handoff?” In agentic systems, each hop can change the effective trust context: the actor may be a tool, an orchestrator, or a delegated sub-agent; the scope may be narrower than the parent workflow; and the decision may depend on time, tenant, task, or provenance. That is why coarse roles often look clean in design but fail at runtime. OWASP’s guidance on agentic applications is useful here because it treats multi-step execution as a trust problem, not just an access-list problem, and the same pressure shows up when static roles are asked to represent dynamic delegation chains. OWASP Top 10 for Agentic Applications 2026
The practical sign is that teams start adding exceptions, overlay rules, or manual approvals to make the role model work. At that point, the policy engine is compensating for missing context rather than enforcing a true decision boundary. In practice, many security teams notice this only after an agent has already been granted a role broad enough to satisfy several workflows, rather than during the first design review.
How to tell the policy is too blunt for the workflow
Per-hop RBAC is usually too coarse when one role has to cover multiple distinct delegation states. A single role may be acceptable for a human operator with stable duties, but agentic access decisions often need to distinguish between “invoked by the primary orchestrator,” “delegated by another agent,” and “acting under a short-lived task grant.” If those states all collapse into one role, the policy cannot express the actual security intent. That creates two predictable failure modes: over-permission, where the role is widened until it covers the hardest case, or operational friction, where the role stays narrow and the workflow breaks.
Useful warning signs include:
- Role names multiply to encode workflow details that should be attributes or claims.
- Approvals are added because the role cannot represent scope, time, or delegation lineage.
- Different tools under the same role still need different limits, yet the policy cannot separate them.
- Auditors have to read logs or tickets to understand why access was allowed, which means the policy is not self-describing.
That is where attribute-based evaluation becomes the better fit: it can inspect the actor, the resource, the trigger, the time window, and the delegation chain in one decision. NIST AI risk guidance is relevant because the core issue is governance of AI-enabled action, not just user entitlement. NIST AI Risk Management Framework If those attributes are unavailable or untrusted, then even a well-designed role model will produce decisions that are technically consistent but operationally unsafe.
The guidance breaks down when the environment cannot reliably assert delegation context, because then the policy cannot distinguish a legitimate handoff from an unsafe reuse of authority.
Where coarse roles still work, and where they do not
Tighter policy models often increase engineering and governance overhead, so organisations have to balance simplicity against decision accuracy. That tradeoff is real: if every hop needs rich context, the identity substrate, logging, and authorization service must all be trustworthy and available.
Coarse per-hop RBAC can still be acceptable when the workflow is stable, low-risk, and the same access outcome is valid regardless of who triggered the step. It also works better when the agent only performs bounded, repetitive actions with little variation in resource scope. In those cases, a role can be a practical shortcut rather than a security flaw.
It becomes a poor fit when any of the following are true:
- The same role would grant access across unrelated datasets, tenants, or tools.
- The permission should change based on the calling workflow or upstream approval.
- The agent acts on behalf of different principals and must preserve that distinction.
- Temporary grants matter more than standing role membership.
For broader identity-bound execution paths, the closest parallel is non-human identity governance, where static role assignment is often less informative than ownership, credential scope, and lifecycle state. The OWASP non-human identity guidance is relevant when agent permissions are carried by service-like identities rather than by human-centric job roles. OWASP Non-Human Identity Top 10 The common mistake is to treat role explosion as a naming problem, when it is usually a signal that the access model no longer matches the way the system makes decisions.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Agentic Access Control | Per-hop delegation is central to agentic authorization scope. |
| Recommendation — Model delegation context as attributes, not static role membership. | ||
| NIST AI RMF | MAP — Measure, Analyze, and Manage | The issue is governance of AI-enabled decisions and their risk context. |
| Recommendation — Assess whether access decisions capture task context before approving autonomy. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Agent permissions often ride on non-human credentials and short-lived access. |
| Recommendation — Tie agent access to credential scope and lifecycle rather than broad roles. | ||
| CIS Controls v8 | 6 — Access Control Management | Coarse roles are an access-control design weakness that needs tighter governance. |
| Recommendation — Review entitlements for scope creep and replace blunt roles where context matters. | ||
| NIST CSF 2.0 | PR.AA-04 — Identity Management, Authentication, and Access Control | Authorization must align with the actual actor and access conditions. |
| Recommendation — Enforce access decisions that reflect the actor, resource, and use context. | ||
Practitioner Guidance
What to verify: Check whether each hop can prove who initiated the request, what delegation it inherited, and what resource scope was intended. If those three facts are not available at decision time, RBAC is probably doing work it cannot do safely.
Decision rule: Keep RBAC only where the same entitlement is valid across the workflow. If access must vary by task, provenance, or time window, treat that as a signal to move the decision boundary to attributes, claims, or short-lived grants instead of adding another role.
What practitioners underestimate: The real problem is often not “too few roles” but “too little decision context.” Once teams start encoding exceptions in tickets or middleware, the policy has already become harder to audit and easier to misuse.
Practitioner takeaway: Coarse per-hop RBAC is usually acceptable only when delegation context does not change the safety of the action; once it does, the authorization model must become context-aware or it will drift toward either over-broad access or brittle exception handling.
