Agent 365 Identity

Agent identity is a foundational concept in the Microsoft Agent 365 SDK. Each agent has its own unique, persistent enterprise identity, separate from human users or generic application registrations. This identity gives the agent privileges, authentication, roles, and compliance capabilities similar to a human employee.

Understanding agent identity components

When you register an agent with Microsoft Agent 365, three key components work together to provide your agent with its identity:

Agent blueprint (Agentic application)
Agent instance
Agent user

Agent blueprint (Agentic application)

The agent blueprint defines the agent's identity, permissions, and infrastructure requirements. It serves as the template for creating agent instances and includes:

Microsoft Entra application registration
Required API permissions (Microsoft Graph scopes)
Authentication configuration
Resource definitions (App Service Plan, Web App)

Agent instance

An agent instance represents a specific deployment of your agent blueprint. Each instance has:

Unique Microsoft Entra ID agent ID
Service principal for authentication
Instance-specific configuration
Federated identity credentials for Teams integration

Agent user

An agent user is the runtime identity that appears in your organization. Agent users are a specialized subtype of user identity designed specifically for agents. Key concepts you need to understand about agent users are their identity characteristics, organization integration, relationship model, and lifecycle.

Identity characteristics

Agent users have distinctive identity properties that differentiate them from traditional user accounts:

Marked as agentic in the directory
Receives tokens with idtyp=user (user identity type)
Has a unique agent user ID (Object ID) separate from the parent agent instance
Can't have traditional credentials (passwords, passkeys, MFA factors)
Must be created through an explicit API call from the parent agent instance
Has an immutable link to its parent agent instance (can't be re-parented)

Organizational integration

Agent users function as full members of your Microsoft 365 organization with the following capabilities:

Are synchronized to your Microsoft 365 tenant directory
Can be assigned licenses (Microsoft 365 E5, Teams Enterprise, Copilot)
Have their own mailbox and OneDrive storage (based on licenses)
Appear in the organizational chart and people cards
Can be @mentioned in Teams, documents, and other Microsoft 365 apps
Have their own unique principal name (for example, agent@yourtenant.onmicrosoft.com)

Relationship model

The connection between agent instances and agent users follows a strict parent-child pattern:

Each agent instance can have at most one agent user child
The agent user stores a reference to its parent agent instance
The parent agent instance maintains a reference to its child agent user (if one exists)
This bidirectional relationship enables proper lifecycle management and auditing

Lifecycle

Agent users are designed for immediate availability with automatic cleanup when no longer needed:

Support instant-on functionality and can be used immediately after creation

Note

Resource provisioning for agent users (mailbox, OneDrive) might take up to 24 hours after license assignment, though it typically completes within 10-15 minutes.
If the parent agent instance is deleted, the child agent user is also deleted
The relationship between agent instance and agent user is immutable and can't be changed

Important

Agent users require appropriate Microsoft 365 licenses to access services like Teams, Email, Calendar, SharePoint, and OneDrive. Common licenses include Microsoft 365 E5, Teams Enterprise, and Microsoft 365 Copilot. After assigning licenses, resource provisioning (mailbox, OneDrive) typically completes within 10-15 minutes but can take up to 24 hours in some cases.

Permissions and access control

Manage agent permissions at multiple levels to provide granular control over access rights and capabilities.

Default permissions

Agent users have specific permission characteristics:

Manage through conditional access policies
Exempt from MFA requirements (since they can't have traditional authentication factors)
Add to Entra ID groups, including the All Agent Users group
Control resource access through explicit permission grants and licenses

Permission management

Set permissions at different levels:

Agent blueprint level - Defines base permissions for all instances
Agent instance level - Specific permissions for the agent identity
Agent user level - User-specific permissions and access rights

Tip

For agents with agent user identities, use the agent user identity primarily for resource access. This practice provides consistent user-like behavior across Microsoft 365 services.

Authentication flows

Microsoft Agent 365 supports two authentication flows for agents, powered by Microsoft Entra Agent ID.

Agent identity authentication

Enables an agent to act with its own identity.

In this flow:

The agent authenticates by using its own credentials (agent blueprint credentials).
The agent operates independently with its own assigned permissions.
The agent has its own identity, separate from any user.
This flow is ideal for autonomous agent operations that don't require user context.

Use cases:

Autonomous agent operations (scheduled tasks, monitoring).
Sending emails or creating meetings from the agent's mailbox.
Creating and managing agent-owned resources.
Background processing without user interaction.

Learn more about registering and creating agents.

On-Behalf-Of (OBO) flow

Enables an agent to act on behalf of a user.