Entra Agent ID Governance: Conditional Access and Lifecycle

Every agent your organization turns on this year is an identity you now have to govern. Copilot Studio makers, Foundry developers and the vendor whose “AI assistant” an employee consented to last Tuesday are all creating principals in your Microsoft Entra tenant, and most of them never cross an identity architect’s desk. Microsoft Entra Agent ID is Microsoft’s answer: a first-class identity type for AI agents with its own Conditional Access targeting, risk detections, sponsors, lifecycle workflows and log schema. This guide is the one I wish I had when the first fleet of agents showed up in a client tenant. It covers the concept model, the Conditional Access policies that actually enforce today, the lifecycle from creation to deletion, what an agent looks like in your logs, the permissions model, licensing, and a 30-60-90 day plan to get it under control.

Everything below is verified against Microsoft Learn as of late October 2026. Where Microsoft’s own pages disagree with each other, I say so.

The governance problem: agents are identities now

Microsoft’s own description of the problem is blunt. Application identities “carry the expectation of long-term stability, known ownership, and managed lifecycle”, while agents “are often created dynamically through automation, user actions in tools like Copilot Studio, or API orchestration” and “might be created and destroyed thousands of times per day” (What are agent identities?). Three failure modes follow from that mismatch, and I have seen all three in tenants this year.

Shadow agents. Before Agent ID, Copilot Studio and the earlier Azure AI Foundry created plain application service principals for agents. They still “appear alongside agent identity objects in the Microsoft Entra admin center” but “behave identically to other application service principals and don’t have the agent-specific behaviors” (Agent identities, service principals, and applications). Add the agents employees run on their own machines, like the ClawPilot wave I covered in the Project Lobster security guide, and your inventory is wrong before you start.

Orphaned principals. A service principal has an owner field that nobody fills in. When the developer leaves, the credential keeps working and nobody is accountable for whether the agent should still exist.

Policies that silently do not apply. Your “all users must use MFA” policy does not cover an agent acting as itself, and an agent cannot complete an MFA prompt anyway. Microsoft’s best-practices page tells you to “audit broad policies (like ‘All users must use MFA’) to ensure they don’t unintentionally block agent flows” and to create dedicated agent policies instead (Best practices for Microsoft Entra Agent ID).

Agent ID addresses all three with purpose-built objects. The rest of this guide is about using them deliberately rather than letting the platforms create them for you.

The Agent ID concept model

Agent ID adds four object types to the directory plus two administrative relationships. The table maps each one to the traditional Entra construct you already understand and to the agentType value you will see in the audit log (Agent identity blueprints, Agent ID logs).

Two behaviours in this model drive every design decision that follows.

The blueprint does the authenticating. Standard service principals present their own credentials. In the agent model “the blueprint acquires tokens on behalf of each agent identity, so the agent identity appears as the client in the resulting token and in audit logs, even though the blueprint performed the actual token exchange.” Microsoft draws the obvious conclusion: “A compromise of the blueprint’s credentials affects all agent identities under it, which is why blueprint count is a security boundary decision” (Agent identities, service principals, and applications). The planning guide’s default is “one blueprint per trust boundary” and “one agent identity per logical agent”; scale-out replicas, audit separation and memory isolation are explicitly not reasons to add blueprints (Plan your agent identity architecture).

Policy flows down from the blueprint. You can “apply Conditional Access policies to an agent identity blueprint that targets all agent identities created from that blueprint”, and “disabling an agent identity blueprint prevents all its agent identities from authenticating” (Agent identity blueprints). That makes the blueprint both your policy attach point and your kill switch.

One limit to note: an agent identity blueprint principal is “limited to a maximum of 250 agent identity creations” when it uses app-only permissions, and soft-deleted identities still count against that number until they are permanently deleted (How are agent identities created?, How agent identity deletion works).

Sponsors, owners and managers

Agent ID separates technical control from business accountability (Administrative relationships in Microsoft Entra Agent ID):

• Owners are “technical administrators responsible for operational management”, can be users or service principals (not groups), and are optional. Only owners can re-enable a disabled identity or restore a soft-deleted one.
• Sponsors are “business representatives accountable for the agent’s purpose and lifecycle decisions”. A sponsor is required on every agent identity and blueprint. Users and selected group types (dynamic membership groups, assigned Microsoft 365 groups) qualify, up to 100 sponsors with no more than 5 groups. Sponsors can disable, soft-delete and change sponsors, but cannot modify authentication settings or restore.
• Managers apply to the agent’s user account and can request access packages for it, but cannot modify or delete the agent.

In delegated creation, “the calling user automatically becomes the sponsor if no sponsors are explicitly specified”, and admins with Agent ID roles are deliberately not made sponsors by default. The Copilot Studio maker who clicks Create is therefore the sponsor of record for that agent, which is exactly the accountability you want, provided you later review it.

Where the agent registry went

If you read about the Entra Agent Registry earlier in 2026, know that it has moved. Microsoft is “converging these registry experiences under Agent 365”: Agent 365 “becomes the unified registry and control plane for agents” while “Microsoft Entra continues to provide the identity foundation through Agent ID”. The complete inventory, “including agents without a Microsoft Entra agent identity”, lives in the Microsoft 365 admin center under Agents > All agents, viewable with the AI Reader role and no specific license. The Entra admin center keeps identities, blueprints, permissions, Conditional Access, governance and security signals under Entra ID > Agents (Agent Registry convergence with Microsoft Agent 365). For a wider look at how Microsoft is folding agent governance into Entra, see my May 2026 Entra ID roundup on passwordless defaults and governance convergence.

Conditional Access for agents

Conditional Access evaluates a policy “whenever Microsoft Entra ID issues or refreshes an access token”, and every token has one subject and one audience. For agents the subject depends on the access pattern, and you must create a separate policy for each pattern the agent uses (Conditional Access for agents).

What signals exist

For agents acting as themselves, the policy toolkit is narrower than for humans, and that is the point: “because this agent accesses resources with its own identity, there’s no remediation and the only available option is blocking access” (Secure agent users with Conditional Access). What you can use today:

• Assignment targets: All agent identities, individual agent identities or blueprint principals via the enhanced object picker, All agent users (Preview), or Select agent identities based on attributes using custom security attributes.
• Agent risk (Preview): Low, Medium or High, fed by Entra ID Protection.
• Agent execution environments (Preview): scopes a policy to “agent user sessions initiated from endpoints”, which is what makes device and network controls safe to deploy.
• Device compliance and compliant network: available for agent user accounts running on Intune-managed Windows 365 Cloud PCs for Agents, with the Global Secure Access client for the network signal.
• Target resources: All resources, specific resources, or All agent resources for policies about humans signing into agents.

The templates

Microsoft ships three agent templates: Block access for high-risk agent identities, Autonomous agent access policy and On behalf of agent access policy (What’s new in Microsoft Entra Agent ID). A separate article gives three tenant-wide block policies for incident response: block agent identity authentication, block agent’s user account authentication, and block users signing into agents (Disable agent identities in your tenant). Every one of them should start in report-only mode. Conditional Access for agents requires “Microsoft 365 E7” or a “Microsoft Agent 365 license paired with at least Microsoft Entra P1 or Microsoft 365 E3” (Conditional Access for agents).

Example policies

1. Allow only approved agents. This is the policy I deploy first. Microsoft’s recommended approach is attribute-driven: create an attribute set AgentAttributes with an attribute AgentApprovalStatus (values such as New, In_Review, HR_Approved, IT_Approved), then build a policy under Entra ID > Conditional Access > Policies that includes All agent identities, excludes Select agent identities based on attributes where AgentApprovalStatus contains HR_Approved, targets All resources, and grants Block (Secure autonomous agents with Conditional Access). Unapproved agents can exist in the tenant, but they cannot get a token until someone tags them. Policies “automatically apply to every agent with matching attributes, including ones added in the future”.

2. Block high-risk agent identities. Include All agent identities, target All resources, set Conditions > Agent risk (Preview) to High, grant Block. This is the agent equivalent of your risky-user policy, and it is what turns the Confirm compromise button in ID Protection into an immediate block (ID Protection for agents).

3. Agent user accounts. For digital-worker agents, block Medium and High agent risk, and where the agent runs on a Cloud PC for Agents, add Agent execution environments (Preview) > Agent user sessions initiated from endpoints with Require device to be marked as compliant or Require compliant network. Without the execution-environment condition, cloud-native agents “are blocked with no path to compliance” (Secure agent users with Conditional Access).

4. Tenant-wide emergency block. When you need a reversible hold on all agent authentication, the Graph payload is small enough to keep in your incident runbook:

POST https://graph.microsoft.com/beta/identity/conditionalAccess/policies
Content-type: application/json

{
  "displayName": "Block all agent identities from accessing resources",
  "conditions": {
    "clientApplications": {
      "includeAgentIdServicePrincipals": ["All"],
      "excludeAgentIdServicePrincipals": []
    },
    "applications": {
      "includeApplications": ["All"],
      "excludeApplications": []
    }
  },
  "grantControls": { "operator": "AND", "builtInControls": ["block"] },
  "state": "enabledForReportingButNotEnforced"
}

Flip state to enabled only after you have read the report-only results.

What cannot be enforced yet

Know the boundaries before you promise them to an auditor (Conditional Access for agents):

• Policies do not apply when a blueprint acquires a Graph token to create agent identities, or during the intermediate exchange at the AAD Token Exchange Endpoint: Public resource. Agent tasks themselves are protected because they run under the agent identity.
• Nothing applies while Security defaults are enabled.
• An agent that calls an API with an API key bypasses Entra entirely, so Conditional Access never sees it.
• “Policies scoped through the ‘Users’ assignment don’t apply to agent user accounts”, whether they target all users, groups, roles or externals. Group-based include and exclude of agent users is not supported either.
• A policy on an agent identity or blueprint “covers only the agent identity, not the agent’s user account.”
• Agents cannot satisfy MFA, terms of use or other interactive controls, so a grant other than Block only makes sense for agent users on managed endpoints.

Permissions: least privilege for agents

Agent identities support both application permissions and delegated permissions, can be assigned Azure RBAC roles and Entra built-in roles, and can inherit delegated scopes from their blueprint. Blueprints cannot hold Azure RBAC roles (Agent identities, service principals, and applications). Three mechanisms matter for least privilege.

Inheritable permissions on the blueprint. Per resource app you choose Enumerated scopes (list them) or All allowed scopes, with a cap of 10 resource apps per blueprint and 40 scopes per resource app for enumerated lists. Microsoft’s advice is to “start with enumerated scopes using only essential permissions, then expand as needed” (Manage agent identities in your organization).

Platform-blocked Graph permissions. Because of “the autonomous nature of agents”, a list of high-risk Graph permissions “can’t be granted to agent identities through Microsoft Graph or Microsoft Entra admin center”. The application-permission block list includes Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, Sites.FullControl.All, Sites.ReadWrite.All, Sites.Read.All, Files.ReadWrite.All, Files.Read.All, Chat.Read.All and BitlockerKey.Read.All, among others (Microsoft Entra Agent ID APIs in Microsoft Graph). If an agent design “needs” tenant-wide SharePoint read, the platform is telling you to redesign it around delegated access or a scoped resource.

Access packages for the rest. Entitlement management can grant agent identities security group memberships, delegated and application API permissions, and Entra roles, with approval, expiry and sponsor notifications. Set the policy’s Who can get access to For users, service principals, and agent identities in your directory and choose All agents (Governing agent identities).

Agent identity, managed identity or service principal?

This is the question every Azure team asks, so here is the decision table I use, built from Microsoft’s planning guide and the Foundry identity concepts (Plan your agent identity architecture, Agent identity concepts in Microsoft Foundry).

Microsoft is explicit that az ad app create, New-MgApplication and POST /applications are the wrong tools for an agent and even publishes an AGENTS.md snippet to stop AI coding assistants from doing it (Best practices for Microsoft Entra Agent ID).

Lifecycle: from creation to decommissioning

Creation paths

Blueprints enter a tenant through five channels, and each has a different control point (How are agent identities created?).

Once a blueprint principal exists, it is itself a creation channel: it is automatically granted AgentIdentity.CreateAsManager, which “can’t be revoked”, so “to prevent a principal from creating agent identities, you must disable it or remove the principal from the tenant.” Creating agent user accounts requires the separate AgentIdUser.ReadWrite.IdentityParentedBy permission that an administrator must grant explicitly.

Copilot Studio now “automatically creates a Microsoft Entra Agent ID for each new agent you create” under a tenant-wide Microsoft Copilot Studio agent identity blueprint, the maker is recorded as sponsor, connector permissions appear as API permissions on the agent identity, and the environment-level opt-out is gone (Manage Entra Agent IDs in Copilot Studio). Microsoft’s pages disagree on the cutover date: the Copilot Studio article says May 2026, the Entra migration guide says 18 March 2026. Either way, agents created before the cutover still run on app registrations, and “there is no automated or in-place migration path”; the Entra guidance is to recreate medium-usage agents and leave production-critical ones alone until Microsoft ships a migration (Recreate Copilot Studio agents with Microsoft Entra Agent ID).

Microsoft Foundry provisions “a default agent identity blueprint and a default agent identity for your project” when the first agent is created; all unpublished agents share it, and publishing an agent creates a dedicated blueprint and identity bound to the agent application. The blueprint trusts the project’s managed identity through a federated credential, so no secret is stored, and RBAC roles must be assigned to the agentIdentityId, then re-assigned when an agent is published and gets a new identity (Agent identity concepts in Microsoft Foundry).

Non-Microsoft agents use one of two patterns: the Microsoft Entra ID Auth SDK sidecar, a companion container that acquires tokens so the agent “never handles credentials directly”, or workload identity federation, which exchanges AWS STS or GCP Workload Identity tokens for Entra tokens against a preconfigured federated identity credential (Integrate third-party agents with Microsoft Entra Agent ID). Both end in a real agent identity that your Conditional Access and logging cover.

Attestation and access reviews

Microsoft’s governance baseline is simple to state: “have sponsors attest every 6-12 months that each agent is still needed and properly configured” through access reviews that include agent identities, and run “a quarterly review process to identify agents with missing sponsors, outdated metadata, or no recent activity” (Best practices for Microsoft Entra Agent ID). Access package assignments with an end date reinforce this: as expiry approaches the sponsor is notified and can extend (triggering a new approval) or let it lapse, in which case “the agent identity loses access to the target resources” (Governing agent identities). Sponsors and owners do their part from the My Account and My Access portals, so you are not routing every renewal through the identity team.

Lifecycle workflows for sponsors

When a sponsor leaves, “Microsoft Entra ID automatically reassigns sponsorship to the sponsor’s manager.” Lifecycle Workflows makes the hand-off visible with three tasks, all classified as mover and leaver tasks and only available under those templates: Send email to manager about sponsorship changes, Send email to cosponsors about sponsor changes, and Transfer agent identity sponsorships to manager. Configure them under ID Governance > Lifecycle workflows > workflows as a Lifecycle Workflows Administrator (Agent identity sponsor tasks in Lifecycle Workflows). Add them to your existing leaver workflow rather than building a new one; the trigger is the human’s departure, not the agent’s.

Decommissioning

Disable before you delete. Disabling an agent identity or blueprint “prevents the blueprint principal or its agent identities from authenticating, but leaves all objects in place”; sponsors can do it from My Account, admins from Entra ID > Agents. Deleting a blueprint or blueprint principal soft-deletes it and triggers an asynchronous cascade that soft-deletes every child agent identity and agent user account. Objects are restorable for 30 days, the cleanup “might not run immediately”, and “restoring the agent identity blueprint principal doesn’t reverse cascade deletions that already occurred.” In the audit log the cascade shows as Delete service principal initiated by an application named Delete Agent Identities Task with a blank app ID, which is expected (How agent identity deletion works). For Copilot Studio agents, deleting the agent in Copilot Studio deletes the agent identity too.

Logging and monitoring

What an agent action looks like in the audit log

Agent activity “is logged under the base identity type from where the activity originates”, so you will not find an “agent” category. You find agents by the agentType property on initiatedBy, performedBy and targetResources, where any value other than notAgentic means agent involvement, and by blueprintId, which ties an identity back to its blueprint (Agent ID logs).

Two practical notes. Through Graph, include the Prefer: include-unknown-enum-members header or the newer values come back as unknownFutureValue. And Microsoft Graph activity logs do not yet separate agents; agent requests are logged as applications with the agent identity in the app ID column, so correlate on ID.

Sign-in logs

Agent sign-ins carry the agentSignIn event type and “might appear across each of the four sign-in log types” because agents can use delegated or app-only tokens. In the admin center, go to Entra ID > Monitoring & health > Sign-in logs as at least a Reports Reader and filter on Agent type (Agent ID user, Agent Identity, Agent Identity Blueprint, Not Agentic) or Is Agent = Yes. For autonomous agents start from Service principal sign-ins, not the user tabs (Investigate Agent ID autonomous sign-ins). The Graph equivalent:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and agent/agentType eq 'AgentIdentity'
Prefer: include-unknown-enum-members

Without an event-type filter the signIns API returns only interactive user sign-ins, which is the single most common reason people conclude their agents “aren’t logging”.

ID Protection detections for agents

Entra ID Protection evaluates agents with its own detections. All of them are offline today, a Learning Mode suppresses behavioural alerts for agents without enough history, and in OBO flows “risky activity is attributed to the user rather than the agent” (ID Protection for agents).

The Risky Agents report (Security Administrator, Operator or Reader) offers Confirm compromise, Confirm safe, Dismiss risk and Disable, detections are retained for 90 days, and the riskyAgents and agentRiskDetections Graph collections expose the same data. Pay particular attention to Suspicious credential usage: it is the detection that catches someone quietly adding a secret to your blueprint.

Getting agent logs into Sentinel and alerting

Agent sign-ins and audit events ride the same diagnostic settings as everything else. Under Entra ID > Monitoring & health > Diagnostic settings, as a Security Administrator, send audit, sign-in and risk categories to a Log Analytics workspace; doing so “automatically enables the Microsoft Entra data connector within Microsoft Sentinel” (Integrate Microsoft Entra logs with Azure Monitor logs). Budget for it: Microsoft’s planning figures are about 2 KB per audit event and 11.5 KB per sign-in event, and chatty agents generate a lot of sign-ins (Activity log integration options). Risk data for agents can be exported through the same mechanism.

Entra Health Monitoring adds an Agent ID autonomous sign-ins scenario (preview) with a Large increase in Agent ID autonomous sign-in failures alert; it needs Entra ID P1 or P2 to view signals and a non-trial P1/P2 tenant with at least 100 monthly active users to receive alerts (Investigate Agent ID autonomous sign-ins). In your SIEM, the alerts Microsoft recommends are credential expiration, agents blocked by Conditional Access or ID Protection (AADSTS53003 is the Conditional Access block code), excessive failed token acquisitions, and unexpected permission or role changes, plus any blueprint credential change that happened outside your deployment pipeline (Best practices for Microsoft Entra Agent ID).

Licensing and cost

The licensing story changed during 2026 and older Learn pages still carry the earlier “P1 for Conditional Access, P2 for ID Protection” wording. The current position, from the licensing page updated in June 2026 and the Conditional Access and Governance pages updated since, is this (Microsoft Entra licensing, Conditional Access for agents, Governing agent identities).

List prices, so you can size it: Microsoft’s US Entra pricing page shows Entra ID P1 at $7, P2 at $10, Entra ID Governance at $7 and Entra Suite at $12 per user per month, all paid yearly, and Microsoft 365 E7 at $99 per user per month (Microsoft Entra pricing). Agent 365 is sold per user; the Canadian Agent 365 page I pulled lists CAD $20.40 per user per month on an annual commitment, and recommends the license “for all users who interact with, own, manage, or sponsor agents” (Microsoft Agent 365). Entra Suite requires an underlying P1. I could not find a per-agent or per-transaction Agent ID meter on any Microsoft page, so plan on per-user licensing rather than consumption billing for the identity layer; the consumption costs you will see are Log Analytics ingestion and whatever Foundry or Copilot Studio charge for the agents themselves.

A 30-60-90 day governance rollout

What to do about it

1. Inventory first: pull All agents from Agent 365 and Agent identities from Entra, and reconcile them against what the business thinks it is running.
2. Assign a named sponsor and a technical owner to every blueprint and agent identity, and record the decision in the object’s description.
3. Decide your blueprint boundaries deliberately: one per trust boundary, one agent identity per logical agent, and no plain app registrations for agents.
4. Replace client secrets on blueprints with managed identities or certificates, store private keys in Key Vault, and rotate at least annually.
5. Deploy the high-risk block and the attribute-based allow-list in report-only, read the results for two weeks, then enforce.
6. Review every broad user policy for unintended agent impact, and create separate policies for agent user accounts because user assignments do not reach them.
7. Grant permissions through inheritable scopes and access packages, start with enumerated scopes, and treat the blocked Graph permission list as a design constraint.
8. Add the three agent sponsor tasks to your leaver and mover lifecycle workflows.
9. Stream sign-in, audit and risk logs to Log Analytics, confirm Sentinel sees agentType, and alert on blocks, failures and credential changes.
10. Put sponsor attestation on a 6-12 month cycle and orphan hunting on a quarterly one, and track the legacy Copilot Studio and Foundry service principals until Microsoft ships a migration path.

Follow the running changes in my Entra ID What’s New series; the agent surface in Entra is moving monthly.

Need a second pair of hands? Big Hat Group provides Azure consulting for organizations in the United States and Canada, from a two-week agent identity assessment to a full Entra Agent ID and Conditional Access rollout. Book a discovery call to talk through your environment.

Sources

• What is Microsoft Entra Agent ID? (Microsoft Learn)
• What are agent identities? (Microsoft Learn)
• Agent identity blueprints in Microsoft Entra Agent ID (Microsoft Learn)
• Agent identities, service principals, and applications (Microsoft Learn)
• Learn about the agent’s user account (Microsoft Learn)
• Administrative relationships in Microsoft Entra Agent ID (Microsoft Learn)
• Plan your agent identity architecture (Microsoft Learn)
• Best practices for Microsoft Entra Agent ID (Microsoft Learn)
• How are agent identities created? (Microsoft Learn)
• Manage agent identities in your organization (Microsoft Learn)
• Disable agent identities in your tenant (Microsoft Learn)
• How agent identity deletion works (Microsoft Learn)
• Agent Registry convergence with Microsoft Agent 365 (Microsoft Learn)
• What’s new in Microsoft Entra Agent ID (Microsoft Learn)
• Integrate third-party agents with Microsoft Entra Agent ID (Microsoft Learn)
• Recreate Copilot Studio agents with Microsoft Entra Agent ID (Microsoft Learn)
• Manage Entra Agent IDs in Microsoft Copilot Studio (Microsoft Learn)
• Agent identity concepts in Microsoft Foundry (Microsoft Learn)
• Conditional Access for agents in Microsoft Entra (Microsoft Learn)
• Secure autonomous agents with Conditional Access (Microsoft Learn)
• Secure agent users with Microsoft Entra Conditional Access (Microsoft Learn)
• ID Protection for agents (Microsoft Learn)
• Governing agent identities (Microsoft Learn)
• Agent identity sponsor tasks in Lifecycle Workflows (Microsoft Learn)
• Microsoft Entra Agent ID APIs in Microsoft Graph (Microsoft Learn)
• Microsoft Entra Agent ID logs (Microsoft Learn)
• Investigate Agent ID autonomous sign-ins (Microsoft Learn)
• Integrate Microsoft Entra logs with Azure Monitor logs (Microsoft Learn)
• Microsoft Entra activity log integration options (Microsoft Learn)
• Microsoft Entra licensing (Microsoft Learn)
• Microsoft Entra pricing (Microsoft)
• Microsoft Agent 365 (Microsoft)