Merge pull request #12284 from MicrosoftDocs/main

Auto Publish – main to live - 2026-03-26 22:10 UTC

Author: learn-build-service-prod[bot]

docs/agent-id/identity-platform/agent-autonomous-app-oauth-flow.md

@@ -68,4 +68,4 @@ The following is a sequence diagram for the app-only flow:
 
 - [Oauth2.0 flows for agents](./agent-oauth-protocols.md)
 - [On-behalf-of flow in agents](./agent-on-behalf-of-oauth-flow.md)
-- [Agent user flow in agents](./agent-user-oauth-flow.md)
+- [Agent's user account flow in agents](./agent-user-oauth-flow.md)

docs/agent-id/identity-platform/agent-identities.md

@@ -38,7 +38,7 @@ An account used by an AI agent is referred to as an **agent identity**. Much lik
 
 - **Blueprint**. All agent identities are created from a reusable template called an agent identity blueprint. The agent identity blueprint establishes the kind of agent and records metadata shared across all agent identities of a common kind.
 
-- **Agent user (optional)**. Some agents need access to systems that strictly require a Microsoft Entra user account be used for authentication. In these cases, an agent can be given a second account, called an **agent user**. This second account is a user account in the Microsoft Entra tenant that is decorated as an AI agent. It has a different `id` than the agent identity, but a 1:1 relationship is always established between an agent identity and its agent user.
+- **Agent's user account (optional)**. Some agents need access to systems that strictly require a Microsoft Entra user account be used for authentication. In these cases, an agent can be given a second account, called an **agent's user account**. This second account is a user account in the Microsoft Entra tenant that is decorated as an AI agent. It has a different `id` than the agent identity, but a 1:1 relationship is always established between an agent identity and its agent's user account.
 
 These are the basic components of an agent identity that enable secure authentication and authorization. The full object schema of an agent identity is available in Microsoft Graph reference documentation.
 

docs/agent-id/identity-platform/agent-oauth-protocols.md

@@ -63,4 +63,4 @@ There are three agent oauth flows:
 
 - [Agent on-behalf of flow](./agent-on-behalf-of-oauth-flow.md): Agents operating on behalf of regular users (interactive agents).
 - [Autonomous app flow](./agent-autonomous-app-oauth-flow.md): App-only operations enable agent identities to act autonomously without user context.
-- [Agent user flow](./agent-user-oauth-flow.md): Agents operating on their own behalf using user principals created specifically for agents.
+- [Agent's user account flow](./agent-user-oauth-flow.md): Agents operating on their own behalf using user principals created specifically for agents.

docs/agent-id/identity-platform/agent-on-behalf-of-oauth-flow.md

@@ -96,4 +96,4 @@ Agent identities can inherit delegated permissions from their parent agent ident
 
 - [Oauth2.0 flows for agents](./agent-oauth-protocols.md)
 - [Autonomous app flow in agents](./agent-autonomous-app-oauth-flow.md)
-- [Agent user flow in agents](./agent-user-oauth-flow.md)
+- [Agent's user account flow in agents](./agent-user-oauth-flow.md)

docs/agent-id/identity-platform/agent-owners-sponsors-managers.md

@@ -12,7 +12,7 @@ ms.reviewer: jawoods
 
 # Administrative relationships in Microsoft Entra Agent ID (Owners, sponsors, and managers) 
 
-The Microsoft agent identity platform introduces an administrative model that separates technical administration from business accountability, ensuring operational control and compliance oversight without excessive permissions. This document explains the administrative relationships for Microsoft Entra Agent ID identity types. This guidance applies to [agent identities](/graph/api/resources/agentidentity?view=graph-rest-beta&preserve-view=true), [agent identity blueprints](/graph/api/resources/agentidentityblueprint?view=graph-rest-beta&preserve-view=true), [agent identity blueprint principals](/graph/api/resources/agentidentityblueprintprincipal?view=graph-rest-beta&preserve-view=true), and [agent users](/graph/api/resources/agentuser?view=graph-rest-beta&preserve-view=true). The article covers owners, sponsors, and managers and their importance in maintaining secure operations.
+The Microsoft agent identity platform introduces an administrative model that separates technical administration from business accountability, ensuring operational control and compliance oversight without excessive permissions. This document explains the administrative relationships for Microsoft Entra Agent ID identity types. This guidance applies to [agent identities](/graph/api/resources/agentidentity?view=graph-rest-beta&preserve-view=true), [agent identity blueprints](/graph/api/resources/agentidentityblueprint?view=graph-rest-beta&preserve-view=true), [agent identity blueprint principals](/graph/api/resources/agentidentityblueprintprincipal?view=graph-rest-beta&preserve-view=true), and [agents' user accounts](/graph/api/resources/agentuser?view=graph-rest-beta&preserve-view=true). The article covers owners, sponsors, and managers and their importance in maintaining secure operations.
 
 The administrative relationships available in Agent ID include:
 
@@ -60,7 +60,7 @@ Sponsors are usually business owners, product managers, team leads, or stakehold
 
 ## Manager
 
-Managers are individual users responsible for an agent identity within the organizational hierarchy. For agents that are active in user scenarios, consider setting a manager on the agent user. Managers can request access packages for their agent users, and will see agents designated as reporting to them in the Microsoft Entra admin center. Managers don't have authorization to modify or delete agents; owners, sponsors, or administrators are required to take those actions.
+Managers are individual users responsible for an agent identity within the organizational hierarchy. For agents that are active in user scenarios, consider setting a manager on the agent's user account. Managers can request access packages for their agents' user accounts, and will see agents designated as reporting to them in the Microsoft Entra admin center. Managers don't have authorization to modify or delete agents; owners, sponsors, or administrators are required to take those actions.
 
 ## Requirements and constraints
 

docs/agent-id/identity-platform/agent-service-principals.md

@@ -78,4 +78,4 @@ Agent service principals support both application permissions (for app-only oper
 
 Agent service principals maintain distinct identities in audit logs and sign-in reports. When an agent identity performs operations, the logs show the agent identity as the acting client while indicating the relationship to the parent agent identity blueprint.
 
-Sign-in logs differentiate between agent identity blueprints, agent identities, and agent users. This differentiation enables clear role identification (client, credential, subject) depending on the specific operation being performed. This enables audit trails for agent operations.
+Sign-in logs differentiate between agent identity blueprints, agent identities, and agents' user accounts. This differentiation enables clear role identification (client, credential, subject) depending on the specific operation being performed. This enables audit trails for agent operations.

docs/agent-id/identity-platform/agent-token-claims.md

@@ -60,13 +60,13 @@ You'd notice that the token includes a few claims that aren't previously seen in
 | ----------------- | ------------------------------------------------------------------------------------- |
 | `tid`             | Tenant ID of the customer tenant where the agent identity is registered. It's the tenant where the token is valid.            |
 | `sub`             | Subject (the user, service principal, or agent identity being authenticated)         |
-| `oid`             | Object ID of the subject. User object ID for user delegation scenarios. Agent ID service principal OID for app-only scenarios. Agent user OID for user impersonation scenarios.          |
+| `oid`             | Object ID of the subject. User object ID for user delegation scenarios. Agent ID service principal OID for app-only scenarios. Agent's user account OID for user impersonation scenarios.          |
 | `idtyp`           | Type of entity the subject is. Values are `user`, `app`.                               |
 | `tid`             | Tenant ID of the customer tenant where the agent identity is registered.              |
 | `xms_idrel`       | Relationship between the subject and the resource tenant. Learn [more](#xms_idrel).   |
 | `aud`             | Audience (the API that the agent is trying to access)                                 |
 | `azp` or `appid`  | Authorized party / actor. The application ID of the agent identity. Enables proper client attribution in audit logs.     |
-| `scp`             | Scope. Delegated permissions for user-context tokens. Only present in user delegation and agent user scenarios. Empty or `/` for app-only scenarios                                            |
+| `scp`             | Scope. Delegated permissions for user-context tokens. Only present in user delegation and agent's user account scenarios. Empty or `/` for app-only scenarios                                            |
 | `xms_act_fct`     | Actor facets claim. Learn [more](#xms_tnt_fct-xms_sub_fct-and-xms_act_fct-claims).    |
 | `xms_sub_fct`     | Subject facets claim. Learn [more](#xms_tnt_fct-xms_sub_fct-and-xms_act_fct-claims) . |
 | `xms_tnt_fct`     | Tenant facets claim. Learn [more](#xms_tnt_fct-xms_sub_fct-and-xms_act_fct-claims) .  |
@@ -153,9 +153,9 @@ In this scenario, the agent identity acts using its own identity. The access tok
 | `aud`         | Resource audience for the token                          |
 | `scp`         | Empty or `/` (unscoped).                          |
 
-### Agent identity acts autonomously via agent user
+### Agent identity acts autonomously via agent's user account
 
-In this scenario, the agent obtains a token using the agent user associated with its agent identity. The access token includes the following claims:
+In this scenario, the agent obtains a token using the agent's user account associated with its agent identity. The access token includes the following claims:
 
 | Claim Name  | Description                                         |
 | ------------- | --------------------------------------------------- |
@@ -164,7 +164,7 @@ In this scenario, the agent obtains a token using the agent user associated with
 | `xms_idrel`   | `1` (indicating a member user; others possible too) |
 | `azp` / `appid` | Application ID of the agent identity   |
 | `scp`         | Delegated permissions granted to the agent identity      |
-| `oid`         | Object ID of the agent user                       |
+| `oid`         | Object ID of the agent's user account                       |
 | `xms_act_fct` | `11` (Agent identity)                           |
-| `xms_sub_fct` | `13` (Agent user)                                  |
+| `xms_sub_fct` | `13` (Agent's user account)                                  |
 | `aud`         | Resource audience for the token                      |

docs/agent-id/identity-platform/agent-tokens.md

@@ -19,7 +19,7 @@ These tokens enable secure communication between:
 
 - Agent identity blueprints and their agent identities
 - Agent identities and resource APIs
-- Agent users and the services they interact with
+- Agents' user accounts and the services they interact with
 - Complex delegation chains involving multiple agent entities
 
 ## Token claims entity identifiers
@@ -61,18 +61,18 @@ In this scenario, tokens have the following key characteristics:
 - Enable unscoped access within granted permission boundaries. Delegated permissions aren't applied.
 - Support fully autonomous background operations
 
-### Tokens in agent user impersonation scenarios
+### Tokens in agent's user account impersonation scenarios
 
-Agent user impersonation scenarios enable agent users to operate like human users. These tokens support scenarios where agents need user-like context but with controlled, predefined identities.
+Agent's user account impersonation scenarios enable the agent's user account to operate like a human user. These tokens support scenarios where agents need user-like context but with controlled, predefined identities.
 
 In this scenario, tokens have the following key characteristics:
 
-- Use specialized agent user identities
+- Use specialized agent's user account identities
 - Maintain user-context behavior patterns
 - Include scoped delegated permissions
 - Require explicit assignment to agent identities
 
-In this scenario, the agent identity blueprint impersonates the agent identity, which then impersonates the assigned agent user. Access is scoped to delegated permissions assigned to the agent identity, ensuring the agent can't exceed its granted permissions even when operating with user context. Agent users can only be used when assigned to an agent identity and can't authenticate independently.
+In this scenario, the agent identity blueprint impersonates the agent identity, which then impersonates the assigned agent's user account. Access is scoped to delegated permissions assigned to the agent identity, ensuring the agent can't exceed its granted permissions even when operating with user context. The agent's user account can only be used when assigned to an agent identity and can't authenticate independently.
 
 ## Nonagentic API integration
 
@@ -112,7 +112,7 @@ Example of the validation process would be to do the following actions:
     HttpContext.User.GetParentAgentBlueprint()
     ```
 
-- Check if a token was issued for an agent user identity.
+- Check if a token was issued for an agent's user account identity.
 
     ```csharp
     HttpContext.User.IsAgentUserIdentity()

docs/agent-id/identity-platform/agent-user-oauth-flow.md

@@ -1,17 +1,17 @@
 ---
-title: Agent user impersonation protocol
-description: Learn how agent identities operate with user context through agent users using the agent user impersonation protocol with OAuth 2.0 token exchange.
+title: Agent's user account impersonation protocol
+description: Learn how agent identities operate with user context through an agent's user account using the agent's user account impersonation protocol with OAuth 2.0 token exchange.
 titleSuffix: Microsoft Entra Agent ID
 ms.topic: concept-article
 ms.date: 10/30/2025
 ms.custom: agent-id-ignite
 ms.reviewer: jmprieur
-#Customer intent: As a developer implementing agent user scenarios, I want to understand the agent user impersonation protocol so that I can enable agents to operate with user context and delegated permissions.
+#Customer intent: As a developer implementing agent's user account scenarios, I want to understand the agent's user account impersonation protocol so that I can enable agents to operate with user context and delegated permissions.
 ---
 
-# Agent user impersonation protocol
+# Agent's user account impersonation protocol
 
-Agent user impersonation enables agent identities to operate with user context through agent users, combining user permissions with autonomous operation. In this scenario, an agent identity blueprint (actor 1) impersonates an agent identity (actor 2) that impersonates an agent user (subject) using FIC. Access is scoped to delegations assigned to the agent identity. Agent user can be impersonated only by a single agent identity.
+Agent's user account impersonation enables agent identities to operate with user context through an agent's user account, combining user permissions with autonomous operation. In this scenario, an agent identity blueprint (actor 1) impersonates an agent identity (actor 2) that impersonates an agent's user account (subject) using FIC. Access is scoped to delegations assigned to the agent identity. The agent's user account can be impersonated only by a single agent identity.
 
 [!INCLUDE [Use Microsoft SDKs](./includes/use-microsoft-libraries.md)]
 
@@ -21,7 +21,7 @@ Agent user impersonation enables agent identities to operate with user context t
 
 Then following are the protocol steps.
 
-:::image type="content" source="media/agent-user-oauth-flow/agent-user-flow.png" alt-text="Diagram showing the illustration of agent user token acquisition flow for agents.":::
+:::image type="content" source="media/agent-user-oauth-flow/agent-user-flow.png" alt-text="Diagram showing the illustration of agent's user account token acquisition flow for agents.":::
 
 1. The agent identity blueprint requests an exchange token (T1) that it uses for agent identity impersonation. The agent identity blueprint presents client credentials that could be a secret, a certificate, or a managed identity token used as an FIC.
 
@@ -41,7 +41,7 @@ Then following are the protocol steps.
 
     Where TUAMI is the MSI token for user assigned managed identity (UAMI). This returns token T1.
 
-1. The agent identity requests a token (T2) that it uses for agent user impersonation. The agent identity presents T1 as its client assertion. Microsoft Entra ID returns T2 to the agent identity after validating that T1 (aud) == Agent identity parent app == Agent identity blueprint.​
+1. The agent identity requests a token (T2) that it uses for agent's user account impersonation. The agent identity presents T1 as its client assertion. Microsoft Entra ID returns T2 to the agent identity after validating that T1 (aud) == Agent identity parent app == Agent identity blueprint.​
 
     ```
     POST /oauth2/v2.0/token
@@ -66,18 +66,18 @@ Then following are the protocol steps.
     &scope=https://resource.example.com/scope1
     &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
     &client_assertion={T1}
-    &assertion={T2}
+    &user_federated_identity_credential={T2}
     &username=agentuser@contoso.com
-    &grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
+    &grant_type=user_fic
     &requested_token_use=on_behalf_of
     ```
 
 1. Microsoft Entra ID then issues the resource token.
 
 ### Sequence diagram
 
-The following sequence diagram shows the agent user impersonation flow
+The following sequence diagram shows the agent's user account impersonation flow
 
-:::image type="content" source="media/agent-user-oauth-flow/agent-user-flow-token-sequence.png" alt-text="Diagram showing the token sequence of agent user token acquisition flow for agents.":::
+:::image type="content" source="media/agent-user-oauth-flow/agent-user-flow-token-sequence.png" alt-text="Diagram showing the token sequence of agent's user account token acquisition flow for agents.":::
 
-Agent user impersonation requires credential chaining that follows the pattern agent identity blueprint → Agent identity → Agent user. Each step in this chain uses the token from the previous step as a credential, creating a secure delegation pathway. The same client ID must be used for both phases to prevent privilege escalation attacks.
+Agent's user account impersonation requires credential chaining that follows the pattern agent identity blueprint → Agent identity → Agent's user account. Each step in this chain uses the token from the previous step as a credential, creating a secure delegation pathway. The same client ID must be used for both phases to prevent privilege escalation attacks.