Agent Default Inactivity Policy
The Agent ID default inactivity policy page updates links to related lifecycle policy and end-user agent management documentation.
Daily.Entra.NewsTrack documentation and Message Center changes for Microsoft Entra Agent ID.
Microsoft Learn documentation ↗The Agent ID default inactivity policy page updates links to related lifecycle policy and end-user agent management documentation.
The agent identity overview revises wording about automatically assigning identities to Microsoft Copilot Studio agents and creating the related identity blueprint.
The documentation adds a tutorial for configuring Microsoft Entra agent identities to authenticate to Azure Database for PostgreSQL flexible server and access data through group-based authorization, entitlement management, and conditional access.
The overview’s guidance on managing agent identities and viewing their access and activity information was updated.
The documentation now directs administrators to **Agent ID (Preview)** instead of **Agent IDs**, and updates the introductory wording about agent identity lifecycle risks.
The documentation describes a preview policy that notifies owners after 60 days of inactivity, disables identities after 90 days, and deletes them after 455 days. Administrators can enable it, configure its scope, and set fallback notification recipients.
The documented procedure now uses **Disable** > **Disable in all tenants** and specifies that the impact applies to multi-tenant blueprints.
The documentation now explains that globally disabling a blueprint can cause related agents in other tenants to fail or lose functionality. It also adds steps for disabling a blueprint in the Microsoft Entra admin center.
The documentation now states that when **Users can create agent blueprints** is set to **Yes**, any tenant user can create an agent identity blueprint and its principal. Otherwise, the Agent ID Developer and Agent ID Administrator roles can create them.
Starting November 4, 2026, default users in Microsoft Entra can create agent blueprints unless administrators disable this via the "Users can create agent blueprints" setting. Admins can restrict this by toggling the setting to No in the Entra admin center before rollout completes in late November.
Starting November 4, Microsoft Entra will stop automatically granting the AgentIdentity.CreateAsManager permission to agent blueprints. Admin consent will be required for agents to create identities. This change, rolling out worldwide in November 2026, enhances control and auditability of agent identity creation.
The article explains how to create policies for agent identities, including periodic reconfirmation, minimum sponsor requirements, inactivity monitoring, notifications, grace periods, and enforcement actions. The capability is in preview.
Adds a how-to article explaining Health Monitoring signals and alerts, log correlation, impact criteria, troubleshooting, and prerequisites for autonomous agent sign-ins. The monitoring and alerts are documented as being in preview.
A new how-to explains how to interpret Health Monitoring signals, correlate agent properties with sign-in and audit logs, and mitigate common failures. It also identifies the relevant non-interactive sign-in logs and documents licensing and role prerequisites.
The documentation now states that Conditional Access evaluates the signed-in user who is the token subject, including users targeted directly or through groups. Selecting an agent identity does not cover OBO traffic.
The documentation clarifies that policies scoped through the Users assignment do not apply to agent user accounts, regardless of whether they target all users, selected users, groups, directory roles, or external users. To protect agents, select Agents under Users, agents, or workload identities.
The documentation clarifies that Conditional Access policies targeting agent identities do not apply to on-behalf-of (OBO) traffic, because the user is the subject of that flow.
The documentation now identifies the agent identity, rather than the application or autonomous agent, as the subject in application-only access.
The Agent ID documentation now uses the correct anchor for the “Allow approved agents by using custom security attributes” policy example.
The policy example link now points to the `use-custom-security-attributes` section.
The Conditional Access Agent ID page now links to Microsoft Agent 365 plans and pricing instead of the Agent ID getting-started information.
The Microsoft Agent 365 licensing prerequisite bullet was reformatted for consistency.
The documentation now states that Microsoft Entra ID Conditional Access for agents requires an eligible license plan, including Microsoft 365 E7 with Agent 365 and Microsoft Entra Suite. The explanatory governance phrase was removed.
The licensing requirements now list Microsoft 365 E7, or Microsoft Agent 365 paired with at least Microsoft Entra P1 or Microsoft 365 E3.
The documentation now refers to real-time risk information, rather than session risk information, among the signals used to determine access.
The overview now explains policy decisions, evaluation timing, token subjects and audiences, and supported agent access patterns. It also adds links to related identity-management and policy guidance.
The agent identity targeting documentation now links to the relevant section on Conditional Access policies and agent identity blueprints.
The overview now explains how Conditional Access evaluates the token subject and resource, and distinguishes delegated, agent-identity, and agent-user-account scenarios. Licensing and network-control requirements remain documented.
The autonomous agents policy documentation now includes a section for custom security attributes in policies.
The page now covers agent identities and additional policy options, including custom security attributes, agent execution environments, device compliance, network locations, and agent risk. It also updates policy creation steps and links.
The article now documents the enhanced object picker for selecting agent identities and blueprints, updates policy-creation steps, and notes that an Agent 365 license will soon be required.
The article now focuses on Conditional Access for agents using their own identities, adds prerequisites, clarifies that policies target agent identities rather than users, and recommends report-only block policies for unapproved agents.
The article now covers selecting agent identities or agent user accounts, explains that conditions and controls depend on the token subject, and updates related links and terminology.
The documentation now states more clearly that an agent needs assigned OAuth delegated permissions to assist a user when accessing a target resource’s APIs.
The documentation now states that agent identities need delegated OAuth permissions for target resources, such as Microsoft Graph or an application, to assist users with API access.
The documentation now describes the linked guidance as covering delegated and application permissions for Microsoft Graph and applications.
The documentation corrects spelling errors, including “credentials,” and adds missing punctuation to a step describing token credentials and Azure SDK clients.
The documentation now identifies the resource role as applying to an AI agent’s service principal or agent ID and adds numbered steps for selecting API permissions, permission type, required permissions, and updating the configuration.
The n8n agent integration page no longer includes the `author` and `ms.author` metadata fields.
The documentation now describes blocked highly privileged directory roles for agent identities without the obsolete custom-role restriction wording.
The documentation now states that agent user accounts can be assigned custom roles, while privileged administrator roles remain restricted.
The authorization documentation now states that custom roles can be assigned to agents.
The documentation now distinguishes agents acting for signed-in users, using their own identity, or using an agent user account. It adds separate guidance links for autonomous agents and agent users and updates the listed licensing combinations.
The article now presents Conditional Access for autonomous agents as a scenario-based pattern, adds prerequisites, and recommends starting block policies in report-only mode. It also notes that an Agent 365 license will soon be required.
The article now uses a scenario-based structure, explains that conditions and controls depend on the token subject, and links separately to guidance for agent identities and agent user accounts. Terminology, metadata, and related links were also updated.
On August 24, 2026, we initiated the gradual roll out of self-service migrations to Microsoft Entra Agent IDs for Copilot Studio agents in Power Platform Advisor. Beginning on September 2026, automatic migrations of agents without Entra Agent ID to Microsoft Entra Agent ID were also initiated.
The AI Administrator and AI Reader descriptions were updated from “Microsoft 365 Copilot” to “Microsoft Copilot.” Their role IDs remain unchanged.
Sponsors can disable agent identities, modify sponsors, and soft-delete resources, but cannot enable or restore agent blueprints or identities.
The documentation now states that sponsors cannot re-enable disabled agents; an owner or administrator must help re-enable them.
The documentation now provides step-by-step My Access portal instructions for authorized users to request an access package for another user, including the US Government portal URL.
The documentation now shows different sample GUID values for the aud, appid, oid, sub, and tid claims.
On August 24, 2026, we initiated the gradual roll out of self-service migrations to Microsoft Entra Agent IDs for Copilot Studio agents in Power Platform Advisor. Copilot Studio agents created before May 2026 may still use legacy app-registration identities.
The Agent ID token claims documentation no longer includes one `tid` claim table row.
The user delegation section now spells out “on-behalf-of (OBO)” on first use. No feature behavior or requirements changed in the supplied diff.
The page description was shortened by removing the phrase “Key concepts.” The documented OAuth 2.0 protocols and token exchange patterns remain unchanged.
The autonomous agent authentication and authorization flow documentation now adds `using Microsoft.Identity.Web;` to a C# setup sample.
The best-practices documentation now uses the full “Microsoft Entra Agent ID” and “Microsoft Entra ID” names in two recommendations. The guidance itself is unchanged.
The documentation now recommends creating agent identities from an agent identity blueprint instead of using standard app registrations or service principals. It also adds .NET usage guidance and lists required roles and permission.
The documentation updates its C# examples, separating app-only, on-behalf-of-user, and user-identification scenarios. Samples now configure agent identity options and pass the credential to the Blob client correctly.
The code sample now uses `<your-tenant-id>` instead of `<your-tenant>` for the `TenantId` value.
The documentation updates its C# examples, including distinct method names for UPN and object ID calls, a revised controller constructor signature, and clearer user-data method names.
The documentation now spells out “on-behalf-of (OBO)” on first use in the token scenario guidance. The referenced method is unchanged.
The Agent ID Microsoft Graph documentation now labels sample variables as `usersAppOnly` and `usersOnBehalfOfUser`, clarifying the scenarios they represent.
The documentation adds Microsoft Graph and Microsoft.Identity.Web imports, changes sample calls from Applications to Users, and clarifies that configured scopes must match the Graph resources used. Examples use User.Read and User.ReadBasic.All.
The documentation adds an OpenID Connect using directive and renames two C# sample variables: `applications` to `applicationsForUser` and `me` to `meByOid`.
The `TenantId` example value changed from `<my-test-tenant>` to `<your-tenant-id>` for clearer documentation.
The third-party agents documentation now labels the sidecar setup link “Configure Microsoft Entra ID Auth SDK for agent identities” instead of “Configure Entra ID Auth SDK.”
The documentation updates the C# sample’s imports, endpoint structure, downstream API call, and model declarations to provide valid create-agent-identity code.
The documentation now uses `<your-tenant-id>` instead of `<my-test-tenant>` in the token endpoint and `TenantId` code examples.
The error-code documentation now separates quota, blueprint, blueprint principal, agent identity, and agent identity creation errors, with clearer descriptions and table headings.
The documentation replaces inconsistent tenant placeholders with `<your-tenant-id>` and standardizes `<agent-blueprint-clientid>` to `<agent-blueprint-client-id>` in code samples.
The delete-agent-identity article no longer contains a TODO asking engineering to confirm whether cascade cleanup removes associated agent user accounts.
The page no longer includes a TODO questioning support for enumerated scopes versus `allAllowed`/`none`. The diff provides no evidence of a product or feature change.
The guide updates “Entra” to “Microsoft Entra” in the diagram alt text, setup heading, and TENANT_ID descriptions. No technical procedure or feature change is shown.
The documentation now spells out “on-behalf-of” before introducing the OBO acronym in the OAuth 2.0 authentication description.
The n8n integration page now consistently calls the pattern “Microsoft Entra ID Auth SDK (sidecar)” instead of “Microsoft Entra Auth SDK.”
The article now consistently refers to the sidecar integration as the Microsoft Entra ID Auth SDK instead of the Microsoft Entra Auth SDK. The integration guidance is otherwise unchanged.
The interactive agent authentication and authorization documentation now includes `using Microsoft.AspNetCore.Authentication.JwtBearer;` in its C# setup samples.
The documentation now consistently uses `<your-tenant-id>` instead of `<my-test-tenant>` or `<your-test-tenant>` in PowerShell, OAuth URLs, and JSON examples.
The key concepts page now labels the link “Microsoft Entra Agent ID OAuth protocols” instead of “oauth protocols.”
The document title was normalized by removing an extra space after the metadata colon. No substantive guidance or product behavior changed.
The page’s `ms.topic` metadata was changed from `how-to #Required; leave this attribute/value as-is` to `how-to`. The topic classification remains unchanged.
The documentation now identifies app-only tokens as using client credentials, expands on-behalf-of to OBO, and consistently uses the `agent-identity-client-id` placeholder in request examples.
The documentation replaces “Entra ID Auth SDK” with “Microsoft Entra ID Auth SDK” in two descriptions. The endpoint formats and behavior are unchanged.
The documentation now explains that agents should use an agent identity blueprint and the `#Microsoft.Graph.AgentIdentity` object, rather than standard app-registration APIs. It also lists supported creation channels, roles, permissions, and .NET usage.
The agent identity architecture planning page now links to the correct interactive agent authentication article instead of the previous broken path.
The Amazon Bedrock integration guide now consistently uses “Microsoft Entra ID Auth SDK (sidecar)” in its description, explanations, container reference, and links. No behavior or availability change is described.
The documentation now expands MCP, A2A, and OBO on first use to improve clarity and retrievability.
The documentation now refers to the “Microsoft Entra ID Auth SDK (sidecar)” instead of the “Microsoft Entra SDK auth sidecar.” The token-validation guidance is otherwise unchanged.
The page’s bullet describing platforms and services that create agents retains the same wording and examples, including Copilot Studio, AWS Bedrock, and n8n. No substantive content change is shown.
The page updates image accessibility text, refines wording about agent identities, and standardizes the name “Microsoft Entra ID Auth SDK (sidecar)” for third-party agent integrations.
The Agent ID documentation now refers to the linked SDK as the “Microsoft Entra ID Auth SDK” instead of “Entra ID Auth SDK.”
The documentation now lists how an agent with its own identity can communicate through Outlook email, OneDrive and SharePoint comments, Teams chats, and Teams channels, including the permissions required for inbound and outbound communication.
The documentation now explicitly states that child agent identities, like their parent blueprints, cannot initiate interactive `/authorize` flows. Interactive consent attempts return `AADSTS82014`; required delegated permissions must be preauthorized instead.
The documentation now explains that Tc must target the agent identity blueprint, while T1 targets the token-exchange resource and is validated as bound to the blueprint and child agent identity. It also states that agent identities cannot use interactive consent and must have delegated permissions preauthorized through inheritable blueprint permissions.
The documentation now lists two license options: Microsoft 365 E7, or Microsoft Agent 365 paired with Microsoft Entra P1 or Microsoft 365 E3.
The documentation replaces the Microsoft Entra ID P1/P2 license requirement and the note that an Agent 365 license would soon be required with a direct Agent 365 license requirement.
The documentation replaces standalone Entra licensing options for agents with guidance that Microsoft Agent 365 is required. It states that Agent 365 is included with Microsoft 365 E7 and available as an add-on to Microsoft E5, A5, Business Premium, or Defender Suite plus Purview Suite.
In Microsoft Agent ID, the agent's identity, blueprint, and blueprint principal may all have sponsors associated with them. In addition, agents can have an [agent's user account](agent-users.md) created in order to access user-oriented services. While the Entra user has a sponsor relationship, there are differences between the user account sponsors and sponsors of the agent identity, blueprint, or blueprint principal.
Starting soon, ID Protection for agents will require a [Microsoft Agent 365 license](https://www.microsoft.com/microsoft-agent-365#plans-and-pricing) to extend protection to agents through [Microsoft Entra Agent ID](../agent-id/what-is-microsoft-entra-agent-id.md#how-to-get-started).
In this flow, the agent can't reuse the user's original token because it was issued for a different audience. Instead, the agent uses the OBO flow to exchange tokens with Microsoft Entra ID, obtaining a new token scoped to the target resource. This token exchange is also evaluated by Conditional Access, letting admins enforce granular controls over which resources agents can access on behalf of the user.
Learn how to map your AI agent architecture to Microsoft Entra Agent ID, including blueprints, agent identities, and an agent's user account.
Learn how agent registry experiences are converging under Microsoft Agent 365, what the change means for Microsoft Entra Agent ID, and how to view all agents in your organization.
Describes how to use an AI coding agent to automate the onboarding process for Microsoft Entra Agent ID, including blueprint creation, credential configuration, and agent identity provisioning.
Learn how to authenticate users, configure authorization, and implement the On-Behalf-Of flow for interactive agents to access resources on behalf of users.
Learn operational best practices for designing, securing, and governing AI agent identities with Microsoft Entra Agent ID, including blueprint design, credential management, access controls, and monitoring strategies.
Understand the difference between required resource access declarations and inheritable permissions for agent identity blueprints in Microsoft Entra Agent ID.
Learn how to integrate third-party AI agents with Microsoft Entra Agent ID for secure authentication using sidecar and federation patterns.
Starting soon, ID Protection for agents will require a [Microsoft Agent 365 license](https://www.microsoft.com/microsoft-agent-365#plans-and-pricing) to extend protection to agents through [Microsoft Entra Agent ID](../agent-id/what-is-microsoft-entra-agent-id.md#how-to-get-started).
Learn how to manage agent identities across your organization. View, disable, govern, and monitor agents using the Microsoft Entra admin center and Conditional Access.
Learn how to manage agent identities in the end user experience within Microsoft Entra. View, control, and take action on agents you own or sponsor with ease.
Learn how audit and sign-in activities associated with agent identities are logged in Microsoft Entra ID.
Learn how to recreate Microsoft Copilot Studio agents with Microsoft Entra Agent ID for enhanced governance and security. No in-place migration path exists today.
Learn how to migrate AI agents from standard Microsoft Entra app registrations to Agent ID for agent-specific governance and security.
Use this decision guide to choose the right identity type, operation pattern, and blueprint and agent identity structure for your AI agents in Microsoft Entra Agent ID.
Learn how to use the Microsoft Entra Auth SDK (sidecar) to secure an Amazon Bedrock AI agent with its own identity for calling downstream APIs.
Deploy n8n on Azure Container Apps and secure AI agent workflows with Microsoft Entra Agent ID and Microsoft Graph MCP Server for Enterprise.