Because app roles and group assignments describe standing entitlement, not the specific context of a single request. If the same agent can act for different users or tenants, the real decision is whether that request should receive the token at all. Issuance-time policy lets teams bound scope before the token exists.
Why app roles are too coarse for identity-aware agents
App roles are useful for standing entitlements, but they are the wrong control point when an agent acts on behalf of different users, tenants, or workflows. The deciding question is not just what the agent can do in general, but whether this specific request should be issued a token at all. Issuance-time policy applies context before access begins.
That distinction matters because identity-aware agents often operate in a delegated model. A single agent may be trusted to request access in one context and refused in another, even though the app role is unchanged. If you rely only on role assignment, you are encoding broad permission and hoping the runtime context will stay safe.
Issuance-time policy is therefore closer to a security gate than a permission label. It can evaluate the current user, tenant, request origin, target resource, time, device, or action type before a token is minted. That lets teams limit scope, prevent token overreach, and keep the agent from inheriting standing authority that it does not need for the current request.
How issuance-time policy changes the authorization model
Token issuance is where the system decides whether delegation should happen, not just what the agent may later present. That makes it the right place to enforce boundaries such as who the agent is acting for, which tenant is in scope, whether the target action is approved, and whether the access should be short-lived or narrowed to a single transaction.
App roles can still exist, but they become a coarse upper bound rather than the final decision. In practice, teams often use roles to describe a class of capability and issuance policy to decide whether the capability should be activated for a specific request. This is especially important when the agent’s authority is dynamic or when the same tool call can be safe in one context and unsafe in another.
For practitioners, the operational value is that issuance policy reduces the number of cases where the agent starts life with more access than the request demands. When the request changes, the policy can change with it. That is much harder to achieve with static roles alone, especially in multi-tenant or user-delegated systems.
What goes wrong when standing roles are treated as enough
Standing app roles tend to overgeneralize. They are usually assigned for the widest expected use case, which means they do not express the conditions under which access should be denied, narrowed, or reissued. For identity-aware agents, that creates a gap between nominal permission and acceptable use in the moment.
At scale, that gap turns into token sprawl, excessive scope, and weak tenant isolation. If an agent can reuse the same role across many contexts, a compromised or misrouted request can reach farther than intended. A better pattern is to decide scope at issuance and keep the token’s authority tightly bound to the specific request path.
Issuance-time policy also helps when access is acting as a trust boundary rather than a user convenience. The same app role might be appropriate for internal automation, but not for an agent handling external tenant data or high-impact actions. The policy can reflect that difference immediately, without waiting for a manual role redesign.
Risk and Threat Considerations
When role assignment is the only control, the main risk is privilege inflation. An agent may receive a token that is broader than the request requires, and that broad token can then be reused, replayed, or abused outside the original context. The problem is not just excessive permission, it is excessive permission issued at the moment of trust.
Failure mechanism: Static roles cannot reliably express request-specific constraints, so the token is minted with standing authority that exceeds the safe context. If the agent is delegated across users or tenants, a valid role can still produce an invalid access decision for that request.
Impact: The blast radius increases if the token is intercepted, misrouted, or used by the wrong workflow. That can lead to cross-tenant exposure, unauthorized actions, and harder-to-detect privilege misuse because the token itself appears legitimate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token issuance depends on credential lifecycle and scope control. |
| AC-6 — Least Privilege | Issuance-time policy enforces least privilege at the moment access is granted. | |
| IA-9 — Service Identification and Authentication | Identity-aware agents need request-bound service authentication, not only static roles. | |
| Recommendation — Bound and rotate agent credentials so issuance cannot create durable excess access. Minimize token scope to the exact request context before minting access. Authenticate agent-to-service calls with contextual constraints tied to the request. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The subject is about controlling access decisions for delegated agent requests. |
| Recommendation — Enforce access decisions at issuance, not only through standing role assignment. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Static roles can overgrant agent tokens relative to the current request. |
| Recommendation — Reduce standing scope so agents only receive the access needed for each request. | ||
Practitioner Guidance
What to verify: The issuance policy should inspect the same context that matters to the access decision, including caller, tenant, target resource, and requested action. If any of those signals are missing, treat the request as under-specified rather than falling back to the broad app role.
Decision rule: If the agent can act on behalf of multiple principals or tenants, make token issuance conditional on the current request context; if the role would be safe only in a single fixed context, the role alone is not sufficient for production access decisions.
What good looks like: The token issued to the agent is narrowly scoped, short-lived, and traceable to the exact request that caused it to exist. Standing roles still define capability, but issuance policy decides whether that capability is activated now.
Practitioner takeaway: Treat app roles as a coarse entitlement model and issuance-time policy as the real control that binds delegated authority to the current request. If you cannot explain why this request deserves a token now, you have not bounded the agent tightly enough.