Agent identity concepts in Microsoft Foundry

An agent identity is a specialized identity type in Microsoft Entra ID that's designed specifically for AI agents. It provides a standardized framework for governing, authenticating, and authorizing AI agents across Microsoft services. This framework enables agents to securely access resources, interact with users, and communicate with other systems.

Microsoft Foundry automatically provisions and manages agent identities throughout the agent lifecycle. This integration simplifies permission management while maintaining security and auditability as agents move from development to production.

This article explains how agent identities relate to Microsoft Entra ID objects, how Foundry uses them when an agent calls tools, and how to apply least-privilege access with Azure role-based access control (RBAC). The same identity model applies to text-based prompt agents and voice-based prompt agents. In voice-based scenarios, Foundry manages the real-time voice runtime and WebSocket connection while the agent identity still authenticates downstream tools and resources.

Prerequisites

• Understanding of Microsoft Entra ID and OAuth authentication
• Familiarity with Azure role-based access control (RBAC)
• Basic knowledge of AI agents and their runtime requirements

For Foundry-specific RBAC roles and scopes, see Azure role-based access control in Foundry.

Agent identities and blueprints

Foundry uses Microsoft Entra ID agent identities to support two related needs:

• Management and governance: Give administrators a consistent way to inventory agents, apply policies, and audit activity.
• Tool authentication: Let an agent authenticate to downstream systems (for example, Azure Storage) without embedding secrets in prompts, code, or connection strings.

Agent identity blueprint

An agent identity blueprint models the agent and is the parent object for its associated agent identities. It provides the governing template for those identities.

The blueprint can also serve as the agent's sign-in point. By using the preview AgentBlueprint endpoint authorization scheme, clients get tokens for the agent blueprint audience to call the agent. This incoming access is separate from the agent identity's access to downstream resources. See Agent blueprint endpoint access and Configure agent blueprint access.

Foundry uses the blueprint to authenticate identity lifecycle operations and get access tokens for its associated identities at runtime. You don't need to configure a client secret or certificate for this flow.

Foundry provisions a federated identity credential on the agent identity blueprint for service-managed authentication. Agent Service uses it during the runtime token exchange. For the underlying credential model, see Agent identity blueprint credentials.

For the underlying Microsoft Entra object and its properties, see Agent identity blueprints.

Agent identity

An agent identity is a special service principal in Microsoft Entra ID, created under an agent blueprint. It represents an agent instance when it accesses downstream resources. The parent blueprint is authorized to impersonate that identity. For the underlying object, see Agent identities.

Security benefits

Agent identities help address specific security challenges that AI agents pose:

• Distinguish operations that AI agents perform from operations that workforce, customer, or workload identities perform.
• Enable AI agents to gain right-sized access across systems.
• Prevent AI agents from gaining access to critical security roles and systems.
• Scale identity management to large numbers of AI agents that can be quickly created and destroyed.

How Foundry provisions identities

Foundry creates and manages Microsoft Entra agent identities throughout the agent lifecycle. In the current agent object model, creating an agent provisions a unique agent blueprint and the identity for its default instance.

A newly created agent identity starts without resource permissions. Foundry doesn't automatically assign RBAC roles or other downstream permissions to it. You or your administrator grant the access it needs through the target service's authorization model. See Assign permissions to the agent identity.

The shared project identity remains available for legacy agents. For the differences between legacy agents, Agent Applications, and the current model, see Migrate from agent applications to the new agent endpoint and publishing experience.

How agents use their identity at runtime

When a tool uses agent identity authentication, the agent uses its identity to access the downstream resource.

Service-managed tool authentication

When the agent calls a tool, Foundry requests an access token for the downstream service and uses that token to authenticate the tool call.

This authentication method applies to text-based and voice-based prompt agents alike. Voice-based agents use the same agent identity to authenticate tool calls while Foundry manages the real-time speech session and Voice Live connection.

Runtime token exchange

For service-managed tool calls that use agent identity authentication, a multistep OAuth 2.0 token exchange occurs automatically between Agent Service, Microsoft Entra ID, and the downstream resource. Agent Service handles the exchange.

The exchange progresses through four stages:

1. Blueprint authentication: Agent Service presents the blueprint's OAuth credentials to Microsoft Entra ID. This step proves that Agent Service is authorized to act on behalf of the blueprint and its agent identities.

2. Agent identity token issuance: Microsoft Entra ID validates the blueprint credentials and issues a token for the specific agent identity. This token is distinct from human user or managed identity tokens - it identifies the agent as an independent actor in the directory.

3. Scoped token request: Agent Service presents the agent identity token back to Microsoft Entra ID and requests a new access token scoped to the audience of the downstream service. The audience is the OAuth resource identifier for the target service (for example, https://storage.azure.com for Azure Storage).

4. Authenticated tool call: Agent Service passes the scoped access token to the MCP server or A2A endpoint. The downstream resource validates the token and checks the agent identity's RBAC role assignments before granting or denying access.

The audience identifies the resource that accepts the token, which isn't necessarily the tool endpoint's URL. Authentication to that resource doesn't itself grant access. For connection settings and audience configuration, see MCP server authentication and A2A authentication.

Token acquisition in hosted-agent code

For hosted agents, the token service lets your code obtain tokens for the current agent instance's identity by default. The project managed identity isn't available to your hosted-agent code. For identity selection, Azure Identity behavior, and the token request contract, see Hosted agent token service reference.

Permissions and access boundaries

Authentication identifies the agent to the downstream service. The service's authorization model determines what that identity can do.

Application-only and delegated access

The access model determines whose authority governs a tool call:

• Application-only access: The agent acts under its own authority, without a signed-in user. Its access depends on the roles, application permissions, or other authorization policies granted to its identity.
• Delegated access: The agent acts on behalf of the signed-in user. The agent needs authorization for the requested delegated permissions, and the user needs access to the resource.

For the delegated actor model and consent requirements, see User delegation for tools and Microsoft Entra consent for delegated access.

Assign permissions to the agent identity

The downstream service determines how it authorizes access:

A service can require more than one authorization layer. When a tool uses agent identity authentication, grant access to the agent identity. Some tools connections might instead use a project managed identity authentication, and in that case, grant access to the project managed identity.

Apply least privilege to the identity used for each tool call. For Azure RBAC, prefer a resource or resource-group scope over subscription-wide access when it meets the agent's needs.

For example, an agent that accesses Azure Storage blobs through application-only authentication needs a suitable Azure RBAC role on the storage resource. An agent that queries Azure Cosmos DB can instead need a service-specific data-plane role. These authorization mechanisms are separate, even though both authorize the agent identity.

For Azure RBAC assignment procedures, use the object ID of the agent identity used for the tool call as the assignee. See Assign Azure roles using the Azure CLI. For Cosmos DB data-plane authorization, see Configure role-based access control for Azure Cosmos DB.

For permissions involved in hosted-agent deployment, including Azure Container Registry and Application Insights, see Hosted agent permissions reference.

Supported tools

Tools can use an agent identity for application-only access or as the actor in a delegated call. Support for one type of access doesn't imply support for the other. The following table summarizes supported integrations and links to their authentication guidance.

Agent identity acting on behalf of the user is in preview and requires agent blueprint endpoint access. For endpoint requirements, supported authentication types, delegated scopes, and consent, see Configure user delegation for tools.

Other tools and integrations can use different identities or authentication methods. Confirm support in the tool's documentation. Project managed identity authentication and a separate OAuth sign-in don't by themselves establish agent identity authentication.

Agent identity authentication doesn't change an external tool provider's data handling or retention policies. Calls to non-Microsoft tools can send data outside Microsoft services. Review and log that access according to your organization's policies.

Identity management and governance

In the current agent object model, each agent has its own agent blueprint and default instance identity from creation.

Foundry agent identities appear in the tenant-wide inventory in the Microsoft Entra admin center, alongside identities from Microsoft Copilot Studio and other services. This inventory lets administrators govern agents across services rather than only within a Foundry project.

Per-agent identities let you scope permissions and audit activity to individual agents. Legacy agents that share a project identity don't have that identity-level separation; see the migration guidance.

In this experience, you can enable built-in security controls, including:

• Conditional Access: Apply access policies to agent identities.
• Identity protection: Monitor and protect agent identities from threats.
• Network access: Control network-based access for agents.
• Governance: Manage expiration, owners, and sponsors for agent identities.

For more information about Microsoft Entra Agent ID features, see Microsoft Entra documentation.

Shared project identities and Agent Applications

Foundry still provisions a shared agent blueprint and agent identity at the project level. Legacy agents without a unique identity use this shared identity. Newly created agents receive their own blueprint and default instance identity instead.

Migrating from a legacy shared project identity or Agent Application to the current agent object model changes the agent identity. Assign the required downstream permissions to the new identity; existing role assignments don't transfer. See Migrate from agent applications to the new agent endpoint and publishing experience.

For legacy identities, deleting the Foundry project removes its shared agent blueprint and identity. Deleting a legacy Agent Application removes that application's distinct identity.

For legacy deployments, the Azure Developer CLI (azd) automatically assigns Foundry User to the shared project agent identity for compatibility. The default hosted-agent scenario doesn't require this assignment. Legacy Agent Applications have distinct identities that require separate manual role assignments.

The shared identity's Foundry role assignment doesn't grant permissions on Azure Container Registry, Application Insights, or custom resources. For the resource-specific permissions required by hosted agents, see Hosted agent permissions reference.

Related content

• Hosted agent token service reference
• Legacy agent applications in Microsoft Foundry
• Migrate from agent applications to the new agent endpoint and publishing experience
• Azure role-based access control in Foundry
• MCP server authentication
• Agent2Agent (A2A) authentication
• Microsoft Entra Agent ID documentation