Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Important
You need to be part of the Frontier preview program to get early access to Microsoft Agent 365. Frontier connects you directly with Microsoft’s latest AI innovations. Frontier previews are subject to the existing preview terms of your customer agreements. As these features are still in development, their availability and capabilities may change over time.
Agent identity is a foundational concept in the Microsoft Agent 365 SDK. Each agent gains its own unique, persistent enterprise identity, separate from human users or generic application registrations. This identity equips the agent with 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)
The agent blueprint defines the agent's identity, permissions, and infrastructure requirements. It serves as the template for creating agent instances and includes:
- Azure AD application registration
- Required API permissions (Microsoft Graph scopes)
- Authentication configuration
- Resource definitions (App Service Plan, Web App)
Agentic app instance
An agentic app instance represents a specific deployment of your agent blueprint. Each instance has:
- Unique agentic app ID (Azure AD application)
- Service principal for authentication
- Instance-specific configuration
- Federated identity credentials for Teams integration
Agentic user
An agentic user is the runtime identity that appears in your organization. Agentic users are a specialized subtype of user identity designed specifically for agents. Key concepts you need to understand about agentic users are their identity characteristics, organization integration, relationship model, and lifecycle.
Identity characteristics
Agentic 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 user ID (Object ID) separate from the parent agent instance
- Cannot 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 (cannot be re-parented)
Organizational integration
Agentic 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 (e.g.,
agent@yourtenant.onmicrosoft.com)
Relationship model
The connection between agentic instances and agentic users follows a strict parent-child pattern:
- Each agentic instance can have at most one agentic user child
- The agentic user stores a reference to its parent agent instance
- The parent agent instance maintains a reference to its child agentic user (if one exists)
- This bidirectional relationship enables proper lifecycle management and auditing
Lifecycle
Agentic 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 agentic users (mailbox, OneDrive) may take up to 24 hours after license assignment, though typically completes within 10-15 minutes.
If the parent agent instance is deleted, the child agentic user is also deleted
The relationship between agent instance and agentic user is immutable and cannot be changed
Important
Agentic 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
Agent permissions are managed at multiple levels to provide granular control over access rights and capabilities.
Default permissions
Agentic users have specific permission characteristics:
- Can be managed through conditional access policies
- Exempt from MFA requirements (since they cannot have traditional authentication factors)
- May be added to Entra ID groups including "All Agentic Users" group
- Resource access is controlled through explicit permission grants and licenses
Permission management
Permissions can be set at different levels:
- Agent blueprint level - Defines base permissions for all instances
- Agent instance level - Specific permissions for the agent identity
- Agentic user level - User-specific permissions and access rights
Tip
For agents with agentic user identities, use the agentic 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 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
On-Behalf-Of (OBO) flow
Enables an agent to act on behalf of a user.
In this flow:
- The agent receives a user's delegated token
- The agent exchanges this token to perform actions as if the user is performing them
- The agent operates with the user's permissions and context
- This flow is ideal for scenarios where the agent needs to access resources with user-specific permissions
- Provides strong auditing when agentic identity is used in reactive flows
Use cases:
- Accessing user-specific data (emails, calendar, files)
- Performing actions that require user consent
- Scenarios where user context and permissions are required
Next steps
Now that you understand authentication flows and agent identity concepts, create your agent blueprint and instance.