AI Agent Identity with Microsoft Entra Agent ID: Issuing and Governing Agent Identities

Agents as directory objects

For years, the only way to give software an identity in Entra was a service principal — which represents an app, not something that acts for a person. Entra Agent ID changes that. An agent is modelled as an agent identity blueprint: a parent registration that holds the credential and the declared delegated permissions, with individual agent identities as children. Agents built in Copilot Studio and Azure AI Foundry get these automatically, and Entra ID Governance adds ownership, access reviews, and certification for them (in preview).

This is the directory-native version of the idea we describe in what AI agent identity is: the agent is a principal you can own, review, and govern — not an anonymous key.

Agent-aware on-behalf-of

The piece that makes Entra Agent ID useful for agents, not just apps, is its profile of RFC 8693 token exchange. The agent exchanges the user's token for a downstream token that keeps the user as sub and carries actor-facet claims (act and xms_act_fct) identifying the agent. The exchange runs in three steps:

1. The client signs the user in through Entra and receives a user token audienced to the agent's blueprint.
2. The agent calls the Entra token endpoint with grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer and requested_token_use=on_behalf_of, passing the user token as the assertion plus its own client assertion.
3. Entra validates the audience chain and returns a composite token audienced to the downstream resource — sub = the user, act = the agent.

The result is the same two-subject token the whole agent-identity model depends on, described in agent identity and on-behalf-of delegation — only here Entra, not the gateway, mints it.

How TrueFoundry fits

Entra says who the agent is; TrueFoundry decides what it may do and makes the call path enforceable. Four steps connect them:

1. Register Entra as an identity provider under Platform → Identity Providers, with the tenant's issuer, audiences, and JWKS, so the gateway can validate Entra-issued tokens.
2. Register each agent as identity-provider-backed, mapping claim values from the agent's Entra token (for example its application/client ID). The agent authenticates to Entra via client credentials or a managed identity and presents the JWT to the gateway.
3. Grant access in TrueFoundry with collaborator grants: who can call the agent, whom it can act for, and which MCP servers and models it can reach.
4. Configure outbound OBO on MCP servers — under Auth Data → OAuth2, set Grant Type to Token Exchange (on-behalf-of), point it at the tenant token endpoint, and set the audience to the target resource. The gateway performs the exchange per call.

Where teams get this wrong

• Assuming Entra alone governs the call. Entra issues the identity and can mint the composite token, but it does not decide which MCP servers or models an agent may reach, and it does not stitch multi-hop chains. That enforcement is the gateway's job.
• Forgetting non-Microsoft targets. Entra's OBO reaches Entra-protected resources. A Jira or Snowflake MCP server still needs brokering or per-user OAuth — the gateway handles those alongside the Entra path.
• Treating preview features as settled. Entra Agent ID is evolving and partly in preview; verify current behaviour against Microsoft's documentation before a production rollout.
• Ignoring Conditional Access for agents. Agent sign-ins can be covered by Conditional Access — use it, rather than assuming an agent identity is exempt from the controls you apply to people.

Already issuing agent identities in Entra?

Govern their path

A worked example

An enterprise standardises on Entra for everything and wants its agents in the directory too. A planner-agent gets an Entra agent identity (blueprint plus child), and the team registers Entra as an identity provider in TrueFoundry and the agent as identity-provider-backed, mapping its client ID. They grant the relevant users Agent Access, add the agent as a collaborator on the Entra-protected MCP servers it needs, and set those servers' outbound auth to Token Exchange (on-behalf-of). Now a user request produces an Entra composite token (sub = user, act = agent), the gateway validates it, authorizes the pair, drives the OBO exchange to each target, and records every hop. When the agent needs a non-Microsoft tool, the gateway brokers that credential without changing the Entra path.

Gotchas worth knowing

• Entra Agent ID is partly in preview. Features like Governance certification for agents are evolving — check Microsoft's docs for current state.
• Copilot Studio and Foundry agents get Entra Agent IDs automatically and can be registered in TrueFoundry as embedded (governance-only) agents to govern their outbound MCP calls.
• The composite token is audienced to the downstream resource; the gateway narrows audience and scope per hop, so confirm the target audiences line up.
• Per-hop exchange is marked as rolling out soon; for multi-agent chains, confirm how delegation is stitched in your version.
• Non-Microsoft targets need the gateway's brokering — Entra OBO alone won't reach them.

The rest of the Entra Agent ID toolkit

On-behalf-of is the headline, but Entra Agent ID is a set of capabilities, and knowing the whole set helps you decide what Entra covers and what still needs a gateway:

• Entra ID as the identity provider — the agent blueprint and its child identities live in the directory, authenticated like any other principal.
• Entra ID Governance for agents — ownership, access reviews, and certification, so an agent identity is subject to the same periodic review as a human account (in preview).
• Conditional Access for agent sign-ins — the same policy engine that gates employee logins can gate an agent's, rather than treating the agent as exempt.

These make the agent a managed directory object, not just an authenticated one — which is the part a security team cares about. What none of them do is decide, at call time, which MCP servers and models the agent may reach, or stitch a multi-agent chain together. That is the enforcement the gateway adds.

Who does what

The cleanest way to reason about an Entra-plus-gateway deployment is to split responsibilities explicitly, so you are not expecting either side to do the other's job:

Read the table as a division of labour, not a competition: Entra answers “who is this agent and whose request is it carrying?”, and the gateway answers “may this pair do this, here, now — and prove it later?”

A note on Copilot Studio and Foundry agents

If you already run Copilot Studio or Azure AI Foundry agents, you have Entra Agent IDs whether you set them up or not — both create them automatically. You do not have to proxy those agents' inbound traffic through TrueFoundry to govern them; register them as embedded (governance-only) agents, and the gateway governs their outbound MCP calls while Microsoft continues to host the agent. That is the practical on-ramp: adopt Entra Agent ID where Microsoft already issues it, and put the gateway on the tool-call path to make it enforceable. The Foundry-specific setup is covered in governing Microsoft Foundry agents and the no-code case in governing Copilot Studio agents.

Related reading

• Agent Identity and On-Behalf-Of Delegation — the two-subject token model
• Governing Microsoft Foundry Agents — the Foundry-specific setup
• Governing Microsoft Copilot Studio Agents — the no-code sibling
• TrueFoundry and Okta Cross App Access — the Okta-backed alternative
• What Is an MCP Gateway? — governing the tool calls themselves

Conclusion

Entra Agent ID solves the identity half of the problem: agents become directory objects with owners, access reviews, and an agent-aware on-behalf-of flow that keeps the user as sub and names the agent as the actor. What it does not do is decide which tools and models an agent may reach, stitch multi-hop chains, or reach non-Microsoft targets. That is the TrueFoundry Gateway's half: it validates the Entra token, enforces per-hop grants, drives the exchange, brokers the awkward targets, and traces every call.

Together they give you what a directory-native enterprise actually wants from agents — identity you issue in Entra, and a call path you can govern and audit everywhere it goes.

Pair Entra Agent ID with a governed call path.

Book a demo