Entra Agent ID and its governance integration are evolving quickly (parts are in preview). The flows below reflect the documented model as of mid-2026 — verify feature status against Microsoft’s Entra Agent ID documentation before depending on specifics.
What Entra gives you
The structural difference from Okta: Entra profiles token exchange as OBO within the tenant and carries the actor natively in the issued token — so inside one Entra tenant you get user preservation and agent attribution without a separate cross-app protocol. Cross-domain access to non-Microsoft resources still needs ID-JAG-style brokering or per-user OAuth, exactly as in the Okta patterns 2–3.
The agent-aware OBO flow
1
The user authenticates and the client gets a user token
The client app signs the user in through Entra and obtains a user access token audienced to the agent’s blueprint.
2
The agent exchanges it for a downstream token
The agent identity calls Entra’s token endpoint with
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, requested_token_use=on_behalf_of, the user token as the assertion, and its own client assertion.3
Entra validates the audience chain and mints the composite token
The result keeps the user as
sub, names the agent in the actor-facet claims, and is audienced to the downstream resource (an MCP server fronted by an Entra app registration, Microsoft Graph, or another API).Setting it up with TrueFoundry
1
Register Entra as an identity provider in TrueFoundry
Under Platform → Identity Providers, add your Entra tenant (issuer, audiences, JWKS). This lets the gateway validate Entra-issued user and agent tokens. See Identity Providers.
2
Register each agent with an identity provider-backed identity
Register the agent and choose Identity provider-backed on the Agent Identity step, mapping the claim values from the agent’s Entra token (for example, its Agent ID application/client ID) to this agent. The agent authenticates to Entra — client credentials or a managed identity — and presents that JWT to the gateway.
3
Grant access in TrueFoundry
Collaborator grants work identically to every other scenario: who may call the agent, whom it may act for, which MCP servers and models it may reach. Entra decides identity; TrueFoundry decides and enforces the call path.
4
Configure OBO on the outbound side
On MCP servers protected by Entra app registrations, set Auth Data → OAuth2 with Grant Type = Token Exchange (on-behalf-of), pointing at your tenant’s token endpoint with the target resource as Audience — the gateway performs the OBO exchange per call, so agents never handle the exchange themselves. (Per-hop exchange at the gateway is rolling out — see coming soon.)
Division of labor: Entra vs. the gateway
Agents that live in Copilot Studio or Azure AI Foundry get their Entra Agent ID automatically. Registering them in TrueFoundry as embedded (governance-only) agents brings their outbound calls to MCP servers under the same gateway governance, even though Microsoft hosts the agent runtime itself.