> ## Documentation Index
> Fetch the complete documentation index at: https://www.truefoundry.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent Governance with Microsoft Entra
> Governing agents when identities live in Microsoft Entra ID (Azure AD) — Entra Agent ID, the agent-aware On-Behalf-Of flow, and how the TrueFoundry gateway drives it.
Use this scenario when your enterprise is standardized on Microsoft Entra ID (formerly Azure AD): users sign in through Entra, workloads run as service principals, and agents are registered through **Microsoft Entra Agent ID**. TrueFoundry validates Entra-issued tokens on the inbound side and drives the On-Behalf-Of exchanges on the outbound side.
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](https://learn.microsoft.com/en-us/entra/agent-id/) before depending on specifics.
## What Entra gives you
| Building block | Role in the model |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Entra ID as IdP** | Authenticates users, issues ID and access tokens; the trust anchor for the tenant. |
| **[Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/)** | Agents as first-class directory objects — an **agent identity blueprint** (the parent registration holding the credential and declared delegated permissions) with **agent identities** as children of it. Agents created in Copilot Studio and Azure AI Foundry appear automatically. |
| **Agent-aware On-Behalf-Of** | Entra's profile of [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html): the agent exchanges the user's token for a downstream token whose subject is still the user, with **actor-facet claims** (`act`, `xms_act_fct`) identifying the agent. |
| **Entra ID Governance** | Lifecycle and access reviews extended to agent objects: ownership, entitlement management, certification (in preview for agents). |
| **Conditional Access** | Context rules (device, location, risk) applied to agent sign-ins like any other principal. |
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](/docs/agent-platform/agent-governance/scenarios/okta#pattern-2--third-party-mcp-whose-authorization-server-trusts-okta).
## The agent-aware OBO flow
The client app signs the user in through Entra and obtains a user access token audienced to the agent's **blueprint**.
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.
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).
With the TrueFoundry gateway in the path, the exchange is performed by the gateway rather than by each agent:
```mermaid theme={"dark"}
sequenceDiagram
participant Jane as Jane (user)
participant C as Client App
participant GW as TFY Gateway
participant Entra as Microsoft Entra ID
participant Agent as Agent (Entra Agent ID)
participant MCP as MCP Server (Entra-protected)
Jane->>C: Sign in via Entra
C->>GW: Invoke agent with Jane's Entra token
GW->>GW: Resolve agent identity (Entra-backed)
agent may act for Jane? allowed on target?
GW->>Entra: OBO exchange: assertion=Jane's token,
requested_token_use=on_behalf_of
Entra-->>GW: Composite token: sub=Jane, act=agent,
aud=MCP resource
GW->>MCP: Call tool with composite token
MCP->>MCP: Validate, enforce Jane's permissions
MCP-->>GW: Jane's data
GW-->>C: Result
```
## Setting it up with 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](/docs/platform/identity-providers).
[Register the agent](/docs/agent-platform/agent-governance/agent-registry#registering-an-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.
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*.
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](/docs/agent-platform/agent-governance/truefoundry-implementation#coming-soon).)*
## Division of labor: Entra vs. the gateway
| Concern | Entra | TrueFoundry gateway |
| ------------------------------------------------ | --------------------------------- | ----------------------------------------------------------------- |
| Agent exists as a directory object with an owner | Yes — Agent ID | Mirrored in the Agent Registry via the IdP-backed identity |
| User preserved + agent attributed in the token | Yes — OBO with actor-facet claims | Drives the exchange; enforces before minting |
| Who may call which agent / MCP / tool, per hop | — | Collaborator grants + access control at every hop |
| Multi-hop chains across agents and MCP servers | Single exchange at a time | Repeats the exchange per hop, stitching the chain |
| Non-Microsoft targets (no Entra trust) | — | Per-user OAuth or gateway-held credentials, with audit continuity |
| Content guardrails, tracing, kill switch | Conditional Access, sign-in logs | Guardrails, per-hop traces, grant revocation |
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.