You are building a multi-agent assistant that helps employees query their own Microsoft Graph mail and calendar. Downstream tools must only see data the signed-in user is already allowed to access. Agents run as Azure-hosted services and call Graph on the user’s behalf. Which authentication pattern should you implement for the agent-to-Graph calls?

Multi-agent solutions often need user impersonation without collecting credentials. For Azure-hosted agents calling Microsoft Graph on a user's behalf, OAuth 2.0 on-behalf-of (OBO) is designed for middle-tier services: the client presents a user access token; the agent service exchanges it, using its own confidential client credentials, for a new token scoped to downstream APIs such as Microsoft Graph. Delegated permissions ensure Graph enforces the same access the user already has. The single application-only client credentials flow with Application.ReadWrite.All so agents can read every mailbox elevates to tenant-wide access, breaks least privilege for personal data, and would let the agent read mailboxes the user should not reach. The approach that embeds each user's username and password in agent session state and performs the resource-owner password credentials grant is legacy, incompatible with modern MFA, discouraged, unsafe in agent sessions, and must not be stored in agent state. The approach that issues long-lived personal access tokens for Graph and stores them in agent long-term memory creates secret sprawl, weak lifecycle control, is difficult to rotate, hard to attribute, and is unsuitable as primary agent auth. Combine OBO with short token lifetimes, continuous access evaluation where available, and careful handling of token caches so session memory does not become a secret store.