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 integrates automatically with Microsoft Entra Agent ID to create and manage agent identities for agents throughout their lifecycle. This integration simplifies permission management while maintaining security and auditability as agents move from development to production.

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

Key concepts

The Agent ID platform framework introduces formal agent identities and agent identity blueprints in Microsoft Entra ID to represent AI agents. You can use this framework to securely communicate with AI agents. This framework also enables those AI agents to securely communicate with web services, other AI agents, and various systems.

Agent identity

An agent identity is a special service principal in Microsoft Entra ID. It represents an identity that the agent identity blueprint created and is authorized to impersonate.

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.

Authentication capabilities

Agent identities support two key authentication scenarios:

Attended (delegated access or on-behalf-of flow): The agent operates on behalf of a human user. It uses delegated permissions that the user grants. The agent can then act under the user's authority to access resources or APIs as that user.
Unattended: The agent acts under its own authority. It acts as a service or an application identity by using its app-assigned roles, RBAC, or Microsoft Graph permissions. Or it acts as an agentic user: an autonomous identity with user-like claims that allow the agent to authenticate and operate independently.

Agent identity blueprint

An agent identity blueprint serves as the reusable, governing template from which all associated agent identities are created. It corresponds to a kind, type, or class of agents. It acts as the management object for all agent identity instances of that class.

Blueprint functions

Agent identity blueprints serve three essential purposes:

Type classification: The blueprint establishes the category of agent, such as "Contoso Sales Agent." This classification enables administrators to:

Apply Conditional Access policies to all agents of that type.
Disable or revoke permissions for all agents of that kind.
Audit and govern agents at scale through consistent, blueprint-based controls.

Identity creation authority: Services that create agent identities use the blueprint to authenticate. Blueprints have OAuth credentials that services use to request tokens from Microsoft Entra ID for creating, updating, or deleting agent identities. These credentials include client secrets, certificates, or federated credentials like managed identities.

Runtime authentication platform: The hosting service uses the blueprint during runtime authentication. The service requests an access token by using the blueprint's OAuth credentials. It then presents that token to Microsoft Entra ID to obtain a token for one of its agent identities.

Blueprint metadata

For example, an organization might use an AI agent called the "Contoso Sales Agent." The blueprint defines information such as:

The name of the agent type: "Contoso Sales Agent."
The publisher or organization responsible for the blueprint: "Contoso."
The roles that the agent might perform: "sales manager" or "sales rep."
Microsoft Graph permissions or delegated scopes: "read the signed-in user's calendar."

Foundry integration

Foundry automatically integrates with Microsoft Entra Agent ID by creating and managing identities throughout the agent development lifecycle. When you create your first agent in a Foundry project, the system provisions a default agent identity blueprint and a default agent identity for your project.

Shared project identity

All unpublished or in-development agents within the same project share a common identity. This design simplifies permission management because unpublished agents typically require the same access patterns and permission configurations. The shared identity approach provides these benefits:

Simplified administration: Administrators can centrally manage permissions for all in-development agents within a project.
Reduced identity sprawl: Using a single identity per project prevents unnecessary identity creation during early experimentation.
Developer autonomy: After the shared identity is configured, developers can independently build and test agents without repeatedly configuring new permissions.

To find your shared agent identity blueprint and agent identity, go to your Foundry project in the Azure portal. On the Overview pane, select JSON View. Choose the latest API version to view and copy the identities.

Distinct agent identity

When an agent's permissions, auditability, or lifecycle requirements diverge from the project defaults, you should upgrade to a distinct identity. Publishing an agent automatically creates a dedicated agent identity blueprint and agent identity. Both are bound to the agent application resource. This distinct identity represents the agent's system authority for accessing its own resources.

Common scenarios that require distinct identities include:

Agents ready for integration testing.
Agents prepared for production consumption.
Agents that require unique permission sets.
Agents that need independent audit trails.

To find the distinct agent identity blueprint and agent identity, go to your agent application resource in the Azure portal. On the Overview pane, select JSON View. Choose the latest API version to view and copy the identities.

Tool authentication

Agents access remote resources and tools by using agent identities for authentication. The authentication mechanism differs based on the agent's publication status:

Unpublished agents: Authenticate by using the shared project's agent identity.
Published agents: Authenticate by using the unique agent identity that's associated with the agent application.

When you publish an agent, you must reassign RBAC permissions to the new agent identity for any resources that the agent needs to access. This reassignment ensures that the published agent maintains appropriate access while operating under its distinct identity.

Supported tools

Currently, the tools that support authentication with an agent identity are:

Model Context Protocol (MCP): Use your agent's identity to authenticate with MCP servers that support agent identity authentication.
Agent-to-Agent (A2A): Enable secure communication between agents by using agent identities.

Configure MCP tool authentication

To configure an MCP tool to authenticate by using an agent identity:

Ensure that you have an MCP server that you want to configure as a tool for your agent.
Get the ID for the agent identity. In the Azure portal, go to your Foundry project. On the Overview pane, select JSON View and choose the latest API version. Copy the agentIdentityId value.
Create a connection to your remote MCP server that uses AgenticIdentityToken as the authentication type. The Audience box specifies which service or API the token is intended to access. For example:
- For an MCP server that lists blobs in your storage account, set the audience as https://storage.azure.com.
- For an Azure Logic Apps MCP server, set the audience as https://logic.azure.com.
You can create the connection by using either the REST API or the Foundry portal:
- REST API
- Foundry portal
To get an access token, run the commands az login and then az account get-access-token.
```
PUT https://management.azure.com/subscriptions/{{subscription_id}}/resourceGroups/{{resource_group}}/providers/Microsoft.CognitiveServices/accounts/{{account_name}}/projects/{{project_name}}/connections/{{mcp_connection_name}}?api-version={{api_version}}
Authorization: Bearer {{token}}
Content-Type: application/json

{
    "tags": null,
    "location": null,
    "name": "{YOUR_CONNECTION_NAME}",
    "type": "CognitiveServices/accounts/projects/connections",
    "properties": {
    "authType": "AgenticIdentityToken",
    "group": "ServicesAndApps",
    "category": "RemoteTool",
    "expiryTime": null,
    "target": "{YOUR_MCP_REMOTE_URL}",
    "isSharedToAll": true,
    "sharedUserList": [],
    "audience": "{YOUR_AUDIENCE}",
    "Credentials": {},
    "metadata": {
        "ApiType": "Azure"
    }
    }
}
```
1. Sign in to Microsoft Foundry. Make sure the New Foundry toggle is on. These steps refer to Foundry (new).
2. Select Build.
3. Select Agents.
4. Select the agent that you want to use.
5. Under Tools, select + Add.
6. On the Custom tab, select Model Context Protocol (MCP).
7. Under Authentication, select Microsoft Entra. Under Type, select Agent identity.
8. Fill in the endpoint and audience information, and then select Connect.
Assign to the agent identity the required permissions for its actions by using the agentIdentityId value that you copied. For example:
- For an MCP server that lists blob containers, assign the Storage Blob Data Contributor role at the Azure Storage Account scope.
- For an Azure Logic Apps MCP server, assign the Logic Apps Standard Reader role on the Logic App resource.
Connect the tool. If you're using code, create an agent with the MCP tool. (For details, see the MCP documentation.) If you're using the Foundry portal, the MCP tool is automatically added to the agent.

When the agent invokes the MCP server, it uses the available agent identity to obtain an authorization token from the scope URI. It then passes the token to the MCP server for authentication.

Manage agent identities

You can view and manage all agent identities in your tenant through the Microsoft Entra admin center. Go to the tab for agent identities to see an inventory of all agents in your tenant, including Foundry agents, Microsoft Copilot Studio agents, and others.

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 the Microsoft Entra documentation.

Publish and share agents in Microsoft Foundry

Feedback

Was this page helpful?

Last updated on 2025-12-02