Topic starter
14/07/2026 4:19 pm
TL;DR: Semperis' analysis of three Entra ID authentication flows finds T1, TC, T2, and TR tokens can carry app, user, and delegated claims across autonomous, on-behalf-of, and agent-user patterns. Security teams need to review consent, inheritance, and runtime token composition together, or final claims can look safer than the privilege actually is.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “Practice Checkpoint 4: Verifying Tokens and Claims in 3 Entra ID Authentication Flows”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Entra ID agent identities can assemble authority through multiple token exchanges, so final claims alone do not prove safe behaviour.
Glossary terms: Agent identity token flow, Delegated Scope, App-Only Permission, Consent Grant
What's in the full article
Semperis' full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Microsoft Graph walkthroughs for each Entra ID agent identity token exchange
- Decoded token claim examples for T1, TC, T2, and TR across the three flows
- The exact consent and permission-grant sequence used to assemble delegated authority
- Chapter-by-chapter context from the broader agent identity attack guide
👉 Read Semperis' guide on Entra ID agent identity token flows and token claim controls →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
30/07/2026 10:53 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Protecting Entra ID agent identities starts with token flow controls