Which OAuth flows do AI agents use in Microsoft Entra Agent ID?

How OAuth flow choice changes what the agent is allowed to do

In Microsoft entra agent id, the flow is not just an implementation detail. It determines whether the agent is borrowing a user’s delegated authority or operating as its own workload identity, which changes consent, scope design, token lifetime, and how you prove who initiated the call. The practical question is whether the action should be tied to a human principal or treated as autonomous service activity.

When the agent is acting on behalf of a person, the right pattern is a delegated OAuth flow, because the user’s authority and consent are part of the security decision. That matters for downstream authorisation checks, audit trails, and approval boundaries. When the agent acts independently, an application style flow such as client credentials is the cleaner model because the runtime is not pretending to be a user.

That distinction is why teams should avoid collapsing every agent interaction into one generic auth pattern. A user-facing Copilot-style action, an unattended background workflow, and a cross-system integration can all be “agentic” in conversation terms, but they are different trust relationships. If you blur them, you end up with overbroad scopes, unclear ownership of consent, and a weaker ability to explain why a given token was issued at all.

For identity foundations and delegation concepts, Agentic AI Identity Guide is the most direct reference point. It explains how AI agents get, use and lose identities, including delegated authority and token exchange.

For the OAuth mechanics behind autonomous versus delegated access, RFC 6749: The OAuth 2.0 Authorization Framework is the baseline standard. It anchors the difference between user-authorised access and client-authorised access that does not depend on an interactive human at runtime.

For token exchange and on-behalf-of style delegation, RFC 8693: OAuth 2.0 Token Exchange is the key technical reference. It is the most useful standard when an agent needs to carry forward a user context without reusing a raw human credential.

Where delegated and application flows usually fit in practice

Delegated flows fit best when the user is the business owner of the action, even if the agent executes the steps. Typical examples are drafting content, retrieving a user’s records, or carrying out an operation that should be recorded as user-initiated. The security test is whether the agent should be limited by the user’s permissions and whether the user can meaningfully consent to the operation.

Application or client credentials style flows fit best when the agent is performing a background job, orchestration task, or system-to-system function with no immediate human principal to bind to. In that case, the agent should authenticate as the application, receive only the permissions the workload truly needs, and be governed as a workload or service rather than as a proxy for a person.

This is also where scope discipline matters. If the same agent can operate in both modes, the safest design is to separate the calling contexts rather than let one token do everything. A delegated token should not silently become a standing workload credential, and a workload credential should not be used to simulate user consent. That separation is what keeps review, revocation, and incident response intelligible.

For autonomous workload identity patterns, Ultimate Guide to NHIs — What are Non-Human Identities covers the identity class that underpins application-style agent auth. It is useful when the agent should authenticate as a service, workload, or application rather than as a person.

For scope and consent hygiene in agent deployments, AI Agent Authorisation Guide explains how to apply least privilege, task-scoped access, and per-action decisions. Those principles are especially important when an agent can switch between delegated and autonomous calls.

For Microsoft Entra environments that are vulnerable to consent abuse, CoPhish OAuth phishing via Copilot Studio shows why consent boundaries and token handling cannot be treated as a formality. It is a practical reminder that the wrong flow or the wrong consent posture can turn a legitimate agent into a token-theft path.

What security teams should verify before they trust an agent flow

The first verification step is to trace the call path and ask a simple question: whose authority is actually present at the moment of access? If the answer is the user, the design should preserve delegation, consent, and traceability to that user. If the answer is the agent itself, the design should preserve workload identity, service ownership, and tightly bounded permissions.

The second verification step is scope review. Agents often start with narrow intent and end up with broad operational reach because their permissions are reused across tasks. Review whether the flow issues only the permissions needed for the specific action, whether consent is time-bound or standing, and whether any token can be replayed outside the intended audience.

The third verification step is operational evidence. You should be able to show which identity was used, which scopes were granted, which approval path applied, and what was done with the token. If you cannot distinguish user-delegated from autonomous calls in logs and incident records, you do not really know which OAuth flow is being used in practice.

Risk and Threat Considerations

OAuth flow confusion creates a real exposure because agents can inherit more authority than intended, especially when delegated access, standing consent, and reusable tokens are mixed together. The main risk is not just overpermissioning, it is loss of accountability: security teams may be unable to tell whether an action came from a person, an agent acting for a person, or an autonomous workload.

Failure mechanism: A design that reuses the wrong flow, broadens consent, or passes tokens across contexts can let an agent act outside the trust boundary that justified the grant in the first place.

Impact: That can enable excessive access, misleading audit trails, harder revocation, and token abuse if the credential or access token is intercepted or reused.

Practitioner Guidance

What to prioritise: Start by classifying each agent action as user-delegated or autonomous, then assign the OAuth flow from that classification instead of from convenience or platform defaults. The most common failure is using one identity pattern for two different trust models.

What to verify: Check that delegated calls are auditable back to a user principal and that autonomous calls are auditable back to the application identity. If the logging, consent model, or approval record cannot prove that distinction, the flow design is too ambiguous to trust.

Practitioner takeaway: The right OAuth flow is the one that preserves the real principal behind the action, because that is what keeps consent, privilege, and incident response aligned with how the agent actually operates.

Related resources from NHI Mgmt Group

• How are AI agents authorised to access resources in Microsoft Entra Agent ID?
• How do AI agents authenticate and obtain tokens with Microsoft Entra Agent ID?
• How do AI agents in Microsoft Entra ID obtain and use tokens?
• How do you secure third-party AI agents such as Amazon Bedrock with Microsoft Entra Agent ID?