Protecting Entra ID agent identities starts with token flow controls

At a glance

What this is: This walkthrough explains how Entra ID agent identity flows are built and how token claims differ across autonomous, on-behalf-of, and agent user paths.

Why it matters: It matters because identity teams need to govern agent permissions, delegation, and claim inheritance before these flows become production access paths.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Semperis's guide to Entra ID agent identity token flows and protections

Context

Agent identity in Entra ID is a non-human identity problem, not just an authentication exercise. The core issue is how an agent gets a token, what claims it carries, and which permissions are inherited versus directly assigned.

The article shows three distinct execution patterns: autonomous access for the agent itself, delegated on-behalf-of access, and agent user access with a human-style context. That distinction matters because identity governance must follow the actor type and the token boundary, not the application label.

Key questions

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.

Q: Why do agent user and on-behalf-of flows complicate IAM reviews?

A: They complicate IAM reviews because a machine-driven path can produce tokens that resemble normal user activity while carrying inherited or direct non-human privileges. That makes a simple sign-in review insufficient. Teams need actor-aware review logic that separates machine execution from human access before certification or investigation.

Q: What breaks when delegated consent is broader than the task actually needs?

A: The access model breaks because the agent can re-express broad consent into runtime privilege that outlives the original approval context. That widens blast radius and makes review outcomes misleading, especially when inherited permissions such as Group.Read.All are approved at a blueprint level and consumed elsewhere.

Q: How do organisations decide whether an agent session is acting as a user or as an app?

A: They should decide by correlating idtyp, appid, oid, scp, and the token exchange path rather than by looking at a single claim. A user-like token can still originate from a non-human identity, so governance must follow the relationship chain, not just the token shape.

Technical breakdown

How Entra ID agent identity token exchange works

The T1 token is the bridge between the agent identity blueprint and downstream access in Microsoft Graph. In the autonomous flow, claims such as oid, azp, aud, appid, and roles show whether the agent is acting under direct app-only permission or through a delegated path. The important control question is not whether a token exists, but which identity object owns the permission and whether that ownership is explicit at each exchange step.

Practical implication: map every token exchange to the identity object that owns the resulting privilege, then verify the claims against intended access scope.

Why delegated access changes the meaning of agent permissions

On-behalf-of flow turns a non-human identity into a delegated actor that inherits user context through consent and OAuth permission grants. That means the same agent can carry both app identity attributes and user-linked claims, which complicates accountability if permissions were approved at the blueprint level but exercised elsewhere. In governance terms, inherited delegated scope is not just a technical convenience. It is an access propagation mechanism that expands blast radius when consent is broad or poorly segmented.

Practical implication: review inherited delegated permissions separately from direct app-only permissions and treat consent scope as a governance boundary.

Agent user flow and the problem of parent-child identity linkage

The agent user flow shows a parent agent identity acting through an agent user with claims that resolve back to the agent identity as the parent. This is structurally different from a human session because the operating context is machine-driven, even when the token looks user-like. The governance risk is identity confusion: if the programme reads idtyp, oid, and appid without understanding their relationship, it may misclassify a non-human execution path as a normal user event.

Practical implication: build detection and review logic that distinguishes agent user context from human user activity before relying on token claims for approvals or investigations.

Threat narrative

Attacker objective: The objective is to turn a working agent identity into a reusable access path that can operate across direct, delegated, and user-context flows.

1. Entry occurs when the agent identity obtains the T1 token through the Entra ID token exchange path and is allowed to proceed into Graph access. Escalation occurs when delegated consent or app-only permissions expand the scope from blueprint identity to effective runtime privilege. Impact occurs when Graph tokens carry inherited or direct permissions that let the agent act with access broader than the original access model assumed.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token claims are not the control plane. This walkthrough shows that Entra ID agent identity flows can be decoded cleanly while still leaving governance ambiguity about who truly owns the privilege. Claims such as appid, oid, scp, and idtyp describe runtime state, but they do not by themselves prove that access was appropriate for the actor type. Practitioners should treat claims as evidence, not as authorisation policy.

Identity confusion is the real failure mode in agent user flows. When a machine-driven agent produces a token that resembles a user session, standard human IAM review logic can miss the distinction. That creates a governance blind spot where delegated and inherited access appears normal because the token format is familiar. The implication is that agent user activity must be segmented from human activity at the identity-governance layer, not just the detection layer.

Delegated consent widens blast radius faster than most access reviews can follow. The on-behalf-of path shows how a blueprint-level permission choice can be re-expressed through user context and then exercised by the agent. This is a classic NHI governance problem: the original approval event is separated from the actual privilege consumption event. Security teams should stop assuming consent review alone is enough to explain runtime access.

Autonomous agent identity creates an access graph, not a single account. The article’s three flows demonstrate that one working agent identity can produce multiple token relationships across blueprint, agent identity, and agent user objects. That means lifecycle governance, entitlement review, and incident investigation all have to follow the relationship graph, not a single principal record. Practitioners need graph-aware governance because the access path is the real asset.

Runtime visibility must be tuned for agent identity behaviour, not just sign-in events. In this model, the same identity can behave differently depending on whether access is direct, delegated, or user-contextual. That is why conventional sign-in-centric oversight is incomplete. The correct posture is to validate which actor type is operating, how the token was minted, and whether the resulting privilege matches the intended governance boundary.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly identity remediation can lag behind exposure.
• The 52 NHI Breaches Analysis helps teams connect visibility gaps to real breach patterns and prioritise the access paths most likely to be abused.

What this signals

Agent identity governance will increasingly look like graph governance. Once Entra ID agents can move through blueprint, agent, and user-context flows, the programme question becomes how well you preserve relationship context across review, detection, and offboarding. That is the same structural issue that appears in broader NHI programmes, where visibility is still weak and lifecycle state is often fragmented.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, identity teams cannot assume access boundaries are stable simply because a token was minted correctly. The practical response is to tie actor classification to every governance workflow, including recertification and incident triage.

For practitioners

• Map each Entra ID token flow to an owning identity object Document which principal owns T1, TC, T2, and TR in your tenant, then compare those objects to the permissions actually exercised in Graph. Use that mapping to identify where privilege is direct, inherited, or consent-driven.
• Separate agent user activity from human session review Create detection and review rules that classify idtyp, appid, oid, and scp combinations before they enter human access review queues. This prevents machine-driven sessions from being certified as ordinary user activity.
• Reassess inherited delegated permissions as blast-radius multipliers Inventory OAuth2 permission grants that allow an agent to act on behalf of a user or agent user, then limit broad scopes such as Group.Read.All where the delegation chain is not operationally required. Treat consent as a privileged governance event, not a formality.
• Instrument Graph access for actor-type awareness Log and alert on token claims that identify whether access is app-only, delegated, or user-contextual, and route those events into identity governance workflows rather than only SOC monitoring. The goal is to preserve actor context through investigation and recertification.

Key takeaways

• Entra ID agent flows show that non-human access can take direct, delegated, and user-contextual forms within the same identity model.
• The key governance risk is not token issuance itself, but misclassifying machine-driven activity as ordinary user behaviour during review and investigation.
• Identity teams need actor-aware controls that follow the relationship graph and consent path, not just the token claims visible at runtime.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• On-Behalf-Of Flow: A token or session pattern where one identity acts for another while preserving evidence of delegation. For agents, the value is not just access propagation. It is the ability to show that the action was performed under a specific authority and within a specific scope.
• Delegated Consent: The authorisation a user or administrator gives to an application to act on their behalf. Once granted, that consent can outlive a password reset or even off-boarding unless it is explicitly reviewed and revoked, creating long-lived access that security teams must govern.
• Token claim: A token claim is a statement embedded in an authentication token that describes something about the caller, such as scope, role, or permitted resources. For NHI and workload identity use cases, claims can become the basis for authorization decisions if they are tightly governed and validated.

What's in the full article

Semperis's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step token acquisition sequences for each Entra ID agent identity flow.
• Decoded claim-by-claim examples showing how oid, azp, appid, idtyp, and scp change by flow.
• Configuration steps for blueprint permissions, consent, and inheritable delegated scopes.
• Practice checkpoints that let you validate the model directly in a tenant.

👉 Semperis's full guide includes the claim-level walkthroughs and practice checkpoints behind each agent identity flow.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 or identity governance programme, it is worth exploring.