Cloud IAM roles are granted ahead of time and are usually too coarse for user-specific agent actions. Token-issuance policy can evaluate user, tenant, and requested scope together before access exists, which is the point where delegation should be constrained.
Why cloud IAM roles are the wrong control boundary for agentic delegation
cloud iam roles are useful for standing access, but they are a poor fit for per-request delegation because the role is already granted before the agent knows the user, tenant, and action context. The real security question is not whether the agent can authenticate to cloud services, but whether it should receive a token for this specific request at all. Token issuance is where that decision belongs.
A role answers, “what identity can generally do in this environment?” Token issuance policy answers, “should this user, for this tenant, asking for this scope, get a token right now?” That shift matters because agentic systems act on behalf of different users, across different data boundaries, and often through the same backend integration. A single coarse role cannot express that variability safely.
Agentic systems also need the issuance step to be policy-aware because access often crosses products, tenants, and tool chains. If you rely only on cloud roles, the agent can end up holding a reusable capability that outlives the immediate task. AI Agent Authorisation Guide covers this pattern well: task-scoped and just-in-time decisions are more defensible than broad standing privilege when agents can act for multiple users.
What token-issuance policy changes in the access flow
Token issuance policy moves the control point forward to the moment access is created. At that point, the system can evaluate user identity, tenant membership, requested scope, resource audience, and policy constraints together. That gives you a chance to deny or narrow access before the token exists, instead of trying to contain misuse after a broadly privileged role has already been assigned.
This is especially important for delegated access patterns such as on-behalf-of flows, agent-to-tool calls, and scope exchange. RFC 8693: OAuth 2.0 Token Exchange defines the delegation mechanism, and RFC 8707: Resource Indicators for OAuth 2.0 shows how tokens can be constrained to the intended resource. For agentic systems, those checks are not optional extras, they are the point where authority should be reduced to the minimum necessary.
Cloud roles still matter underneath, but they should be the coarse trust anchor, not the final authorisation decision for every action. When an agent operates in multiple contexts, the policy engine needs enough context to issue a bounded token for one request, one tenant, or one tool, rather than a general capability that can be replayed elsewhere.
Why this matters for safety, blast radius, and auditability
Without token-issuance policy, a role can become an overbroad standing permission that the agent carries far beyond the original user request. That creates a larger blast radius if the agent is confused, misled, or later compromised. It also makes it harder to prove that a given action was authorised for a specific user and scope, because the access decision happened too early and too generically.
Token-aware controls help reduce replay and misuse risk as well. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens show how stronger token binding can limit the value of a stolen token. In agentic systems, that matters because the access path is often automated, repeatable, and fast-moving.
For cloud-heavy environments, a workload identity posture may still be the right foundation, but it does not replace request-level policy. Cloud Workload Identity Guide is useful background here: workload identities and cloud roles provide the runtime principal, while token issuance policy decides whether the agent should receive a token for this exact operation.
Risk and Threat Considerations
When token issuance is too permissive, agentic systems inherit the weaknesses of broad standing access, especially over-scoped delegation, cross-tenant leakage, and token replay. The practical failure mode is simple: the agent gets a valid token that is larger, longer-lived, or more reusable than the task requires, and that makes later misuse much easier.
Failure mechanism: A cloud role grants baseline capability, but the issuance layer fails to narrow the token to the current user, tenant, audience, or action. That leaves the agent holding a capability that can be reused outside the intended context, or applied to resources that were never part of the original request.
Impact: Unauthorized data access, privilege escalation through delegation, cross-tenant contamination, and weaker forensic attribution. If the token can be replayed or forwarded, the compromise radius expands from one request to an entire integration path.
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 API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic delegation can overgrant access when identity and privilege are too coarse. |
| ASI02 — Tool Misuse | Token issuance must restrict which tools or resources an agent can reach on each request. | |
| Recommendation — Enforce per-action policy checks before an agent receives delegated capability. Scope tokens to the intended tool or resource before execution. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Request-time scope decisions prevent agents from invoking functions they should not reach. |
| Recommendation — Apply function-level authorization at token issuance for every privileged call. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Issuance policy enforces what access exists before the token is minted. |
| IA-5 — Authenticator Management | Token lifecycle and binding are central when delegated credentials are minted per request. | |
| Recommendation — Enforce authorization rules at issuance rather than relying on broad standing roles. Issue short-lived, tightly bound credentials and rotate or revoke them promptly. | ||
Practitioner Guidance
What to verify: Confirm that the access decision is made at token issuance, not only at cloud-role assignment. The policy should inspect the user, tenant, requested scope, resource audience, and any on-behalf-of or delegation context before minting credentials.
Decision rule: If the agent can act for different users or tenants, treat cloud IAM roles as the baseline infrastructure permission and require a separate issuance policy for each request path that can affect customer data or privileged actions.
What good looks like: The agent receives narrow, short-lived, audience-bound tokens that are traceable to a specific delegated request, and the same backend role cannot be reused as a blanket authorisation substitute.
Practitioner takeaway: Roles establish where an agent may operate in general, but issuance policy determines whether a specific delegated action should exist at all, and that is the control boundary that keeps agentic access safely constrained.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org