TL;DR: Three Microsoft Entra ID agent identity flows show how T1, TC, T2, and TR tokens carry app, user, and delegated claims across autonomous, on-behalf-of, and agent user patterns, according to Semperis. The governance problem is not just access design, but assuming token claims alone define safe agent behaviour.
At a glance
What this is: This is a walkthrough of three Entra ID agent identity token flows and the key finding is that token claims, scopes, and consent paths have to be governed together rather than treated as isolated artefacts.
Why it matters: IAM, PAM, and NHI teams need to understand these flows because agent identities can inherit delegated behaviour and app-only rights in ways that conventional access reviews and entitlement checks may miss.
Context
Entra ID agent identity governance fails when teams treat token claims as proof of safe behaviour. In practice, the security question is not just whether a token exists, but which identity issued it, which permissions it carries, and whether the delegation path makes those permissions broader than intended. That is the core NHI governance problem in this article.
The guide uses the same agent identity across three flows to show how Microsoft Graph issues different tokens for autonomous access, on-behalf-of access, and agent-user access. For identity teams, that matters because consent, inherited scopes, and app-only permissions can create approval paths that are easy to document but hard to reason about once the flow is running.
Key questions
Q: What breaks when Entra ID agent identities are managed like human accounts?
A: Human account governance assumes a stable person, predictable approval chains, and reviewable behaviour. Agent identities can act through tokens and APIs without those assumptions holding, so ownership, intent, and revocation become harder to prove. The result is a control gap between registration and effective privilege.
Q: Why do delegated agent flows create more governance risk than autonomous agent flows?
A: Delegated flows add user context, inheritable scopes, and consent logic on top of the agent identity, so authority can be composed from multiple approvals. That makes the effective privilege harder to reason about than an app-only call, especially when the same agent supports more than one execution path.
Q: What are the signs that agent identity consent is expanding beyond intended scope?
A: Look for agents that rely on both direct app permissions and inherited delegated scopes, especially when the same blueprint supports multiple flows. If the final access token reflects claims from separate approval steps, the runtime privilege is already broader than a single review item will show.
Q: How should security teams handle agent identity admin roles in Entra ID?
A: Treat agent identity admin roles as privileged until you verify the exact objects they can reach. Test whether the role can alter owners, credentials, or policy on any non-agent service principal, then restrict assignment to a small set of operators and require alerting on every ownership change.
Technical breakdown
How Entra ID token exchange separates blueprint, agent, and user claims
The article shows that Entra ID agent identity flows rely on a sequence of tokens rather than a single authentication event. T1 is used to bootstrap trust, TC represents the client side of the flow, T2 ties the exchange back to the agent-user path, and TR is the final access token issued to Microsoft Graph. The important technical point is that claims such as oid, azp, appid, aud, and scp identify different parts of the delegation chain. That means the token itself is not the whole policy decision, only the evidence of how the flow was assembled.
Practical implication: review token issuance paths, not just final claims, when validating Entra ID agent identity trust.
Why autonomous and on-behalf-of agent flows are not equivalent
Autonomous flow means the agent identity is acting with its own app-only permission set, while on-behalf-of flow adds delegated user context on top of inherited permissions. The article’s examples show that the same agent identity can operate either as a direct caller to Graph or as a delegated actor using user consent and inheritable scopes. That distinction matters because delegated claims can mask a broader effective privilege set than the user alone appears to have, especially when blueprint-level permissions and direct app permissions are both present.
Practical implication: classify each agent flow by whether it uses app-only rights, delegated rights, or both before approving access scope.
How consent and inherited scopes create hidden privilege paths
The guide demonstrates that consent is not a one-time administrative checkbox. In the on-behalf-of and agent-user examples, the agent identity depends on OAuth permission grants and inheritable scopes that are later reflected in the final access token. That creates a governance path where the original approval and the eventual runtime capability are separated by multiple tokens and claims. In Entra ID, this means privilege review has to account for both direct assignments and inherited delegated permissions, because the operational authority of the agent may be assembled from more than one approval event.
Practical implication: audit consent grants and inherited delegated permissions together so the effective privilege set is visible end to end.
NHI Mgmt Group analysis
Token claims are not a governance boundary: This article shows that agent identity safety cannot be inferred from the final access token alone. The same agent can arrive at Graph through app-only, delegated, or hybrid claim paths, which means the security boundary is the full token flow, not the token payload. Practitioners should treat claim inspection as evidence, not assurance.
Delegation chain transparency is the real control gap: Entra ID agent identities can combine blueprint permissions, user consent, and inherited scopes across several exchanges before a resource call occurs. That makes simple entitlement views incomplete, because they collapse multiple approval states into one apparent identity. The practical conclusion is that governance has to follow the chain from consent to issuance to use.
Effective privilege in agent identity systems is assembled, not assigned once: The article’s three flows make clear that an agent may accumulate authority from direct app permissions and from delegated scopes at different stages of execution. That breaks the assumption that one provisioning event defines the actor’s operational limits. Identity programmes need to reason about runtime authority composition, not static role assignment.
Runtime token composition is the named concept here: The important pattern is not merely token exchange, but the way Entra ID composes agent authority from T1, TC, T2, and TR across different trust relationships. This is where many reviews stop too early, because they validate the identity object without tracing how permission materialises during execution. Practitioners should build controls around token composition, not just identity registration.
Agent user flows make inherited privilege governance mandatory: When an agent operates with a user context, the resulting authority reflects both the agent parent and the delegated user path. That means user-focused access governance and NHI governance are no longer separate conversations. The programme implication is that Entra ID agent reviews must include the human delegation model as part of the machine identity review.
What this signals
Runtime token composition: Entra ID agent governance needs to move from static identity reviews to flow-based assurance. Once an agent can accumulate authority through multiple token exchanges, the relevant question is whether the issuance path is still governed at the same level as the resource it reaches.
Security teams should expect more hybrid identity paths where agent identities carry both app-only and delegated authority. That pushes Entra ID governance toward traceable consent management, explicit flow separation, and tighter review of inherited scopes rather than reliance on a single entitlement record.
For practitioners
- Map every agent identity flow end to end Trace T1, TC, T2, and TR issuance paths for each agent so you can see which claims, scopes, and principals are actually involved at runtime.
- Separate app-only and delegated access reviews Review autonomous flows separately from on-behalf-of and agent-user flows, because the governance questions differ when app permissions and inherited user context are both present.
- Audit consent grants and inherited scopes together Check OAuth permission grants, principal consent, and inheritable delegated permissions as one control surface instead of treating them as independent approvals.
- Document the parent identity for each agent user Record which agent identity sits behind the agent user and which user context is inherited, so accountability survives token exchange and delegated execution.
Key takeaways
- Entra ID agent identities can assemble authority through multiple token exchanges, so final claims alone do not prove safe behaviour.
- The article shows that app-only, delegated, and agent-user flows create different governance problems even when they use the same underlying agent identity.
- Security teams need to review consent, inheritance, and runtime token composition together if they want Entra ID agent governance to reflect actual privilege.
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 and MITRE ATT&CK address 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article focuses on Entra ID agent token flows and trust assembly during authentication. |
| NHI-05 — Overprivileged NHI | Agent identity access can combine app-only and inherited delegated permissions beyond a single entitlement view. | |
| Recommendation — Trace agent token flows to confirm authentication is bound to the intended blueprint, principal, and user context. Review direct and inherited permissions together to prevent agent identities from exceeding intended scope. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Authenticator Management for Services and Accounts | Agent identities are service-like non-human actors authenticating across token exchanges. |
| Recommendation — Apply IA-9 to govern service authenticator issuance, use, and lifecycle across agent flows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether permissions and authorisations match actual runtime authority. |
| Recommendation — Validate agent identity entitlements against the exact runtime flow that can exercise them. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s token-chain focus maps to credential use and movement across trusted identities and resources. |
| Recommendation — Map agent token misuse scenarios to credential access and lateral movement detection logic. | ||
Key terms
- Agent identity token flow: The sequence of tokens and claims used to establish, exchange, and exercise an agent identity in a platform such as Entra ID. It matters because authority may be assembled across several steps, so the final token alone does not fully describe the actor’s effective privilege.
- Delegated Scope: Delegated scope is the set of actions and resources a receiving agent is allowed to use on behalf of the originating actor. Effective scope should be narrower than the agent's raw capability and must be checked at every handoff, not just at session start.
- App-Only Permission: An app-only permission is access granted to an application or agent without a human user present in the transaction. For non-human identities, app-only permissions often carry the strongest operational risk because they can be used independently of interactive approval and may persist across runtime sessions.
- Consent Grant: A consent grant is the delegated approval a user gives an application to access data or APIs on their behalf. In OAuth environments, the grant can persist beyond the login session, so it becomes a governed access artefact rather than a one-time click.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org