How the broker gets an Entra token for an agent

Description and use

The broker obtains an Entra token for an agent by performing a three‑step exchange—refresh, T1 with fmi_path, and OBO—to produce a Graph access token that includes the agent’s identity and user’s object id, avoiding a shared client secret.

Problem

The broker must issue an Azure Entra token that Graph accepts for a specific user acting through a specific AI agent, without sharing a single client secret across all agents.

Outcome

The broker can now issue per‑agent Graph tokens that preserve auditability (azp and oid) and avoid shared secrets, enabling fine‑grained revocation and secure credential handling.

Workflow

• 1. Refresh: broker retrieves user refresh token from vault and redeems it with Entra.
• 2. T1: broker requests a token naming the agent blueprint and identity; Entra returns a token with fmi_path indicating the agent identity.
• 3. OBO: broker performs on‑behalf‑of exchange using the T1 token to obtain a Graph access token with the required scopes.

Evidence

The broker has to produce an Entra token that Graph or another API will accept, for the right user, acting through the right agent.

Source

Getting a Graph token for an agent takes three steps. The broker runs them in order, and each one has its own failure modes.

Source

The broker performs an on‑behalf‑of exchange, presenting the T1 token. The result is an access token whose audience is Graph and whose scopes are the ones the resource map allowed.

Source

The broker checks on the final token. These are the properties we assert in the end‑to‑end test: aud = https://graph.microsoft.com scp = User.Read azp = <the agent identity id> oid = <the user's object id>

Source

A client secret would make the broker look like a single application, and every agent would share its rights.

Source