An orchestrator agent in Microsoft Foundry accepts an end-user chat session and must call a downstream specialist agent that then invokes Microsoft Graph using the signed-in user’s permissions. The specialist must never use application-only permissions for mailbox data. Which authentication flow should you implement between the user, orchestrator, and specialist tools?
Select an answer to reveal the explanation.
Short Explanation
You need OBO because it proves the specialist is acting as the signed-in user, not a god-mode app. The orchestrator takes the user’s delegated token, swaps it for Graph scopes, and the specialist uses that delegated token. No shared service account, no ROPC, no app-only mailbox read.
Full Explanation
When a multi-agent chain must act as the interactive user against Microsoft Graph or similar APIs, the standard Azure AD / Entra ID pattern is the OAuth 2.0 On-Behalf-Of flow. The correct flow is the one where the orchestrator receives a delegated user token, exchanges it for a Graph-scoped token, and the specialist agent or tool calls Graph with that delegated token: the user authenticates to the front-end agent, the orchestrator receives a delegated access token, and that token is exchanged for a token audience-scoped to Graph with the minimum delegated permissions required. Downstream specialist agents and tools reuse that delegated context so mailbox operations are attributed to the user and limited by the user’s own rights.
The approach that issues a long-lived personal access token for each user and stores it in the specialist agent’s long-term memory for reuse across sessions is incorrect because long-lived personal access tokens in agent memory are hard to rotate, easy to exfiltrate via prompt injection, and do not follow modern Entra best practices for interactive Graph access.
The approach that configures the specialist agent with a client-credentials app registration that has Mail.Read application permission granted tenant-wide is incorrect because client-credentials with Mail.Read application permission is app-only access across many mailboxes, exactly what the scenario forbids.
The approach that embeds the user’s password in the agent session state so each tool call can perform resource-owner password credentials authentication is incorrect and insecure: resource-owner password credentials is deprecated for most scenarios, storing passwords in session state is a critical vulnerability, and it fails MFA and Conditional Access expectations.
Exam tip: Phrases like “on behalf of the signed-in user” and “no application-only permissions” point to delegated OAuth/OBO, not client credentials or shared secrets in memory.