Before May 2026, when a maker in Copilot Studio published an agent, Copilot Studio provisioned an Azure app registration behind it, and nobody outside Copilot Studio had much reason to notice. After May 2026, Copilot Studio creates a Microsoft Entra Agent ID automatically for every new agent, and it does this at creation, not at publish, according to Microsoft's documentation on using Entra agent identities in Copilot Studio. An agent gets a directory identity before a single maker has tested a single topic.
Agents stopped being a maker's business
Microsoft Agent 365 reached general availability on 1 May 2026, built on three pillars Microsoft calls observe, govern and secure, per Microsoft's own Agent 365 overview documentation. It surfaces in the Microsoft 365 admin center under Agent 365 and Agent registry, and Copilot Studio agents land in that registry the moment they exist. No opt-in, no configuration step. Copilot Studio also sends telemetry to the Agent 365 observability backend without any manual instrumentation, using a framework built on OpenTelemetry.
The first time an organisation creates an agent under this model, Copilot Studio adds something else to the tenant, a blueprint named "Microsoft Copilot Studio agent identity blueprint," with its own blueprint principal, carrying the fixed ID 25664c89-cea5-4ab6-b924-a54fd8a19ae0. Every agent identity Copilot Studio creates afterward derives from that blueprint. It's the same pattern Entra uses for any class of workload identity, and it means an admin who has never opened Copilot Studio can find, inspect and govern every agent it has ever produced from inside Entra.
Agents built before May 2026 don't inherit any of this automatically. They're still running on the old Azure app registration model, and there's no automated way to convert one. Microsoft's own migration guidance says an organisation has to create a new agent with Agent ID integration, reconfigure it by hand, and decommission the legacy agent separately. Self-service migration through Power Platform Advisor only started rolling out on 24 August 2026, and Microsoft describes that rollout as gradual.
So right now, in most tenants, some agents carry a real Entra identity and some are still running on the old model. The only way to know which is which is to check each one.
What an agent identity gives the admin
An Entra Agent ID turns an agent into a principal that can be found, owned, permissioned and reviewed the same way a service account can. Microsoft's identity governance documentation splits responsibility into two roles. Owners are technical administrators who handle operational management. Sponsors are business representatives accountable for why the agent exists and what happens to it. Every agent identity and every agent identity blueprint needs at least one sponsor. If that sponsor leaves the organisation, Entra ID reassigns sponsorship to the sponsor's manager automatically, without anyone filing a ticket.
Permissions attach the same way they do for a person. When a maker publishes an agent, Copilot Studio attaches API permissions to the agent's Entra Agent ID for every Power Platform connector it uses, and those permissions appear as first-class API permissions to anyone with admin rights over Entra or Microsoft 365. Agent identities can also be assigned to security groups, granted application OAuth permissions, and added to access packages, the same access package system that onboards a new hire into a finance system. A sponsor can request access on an agent's behalf, or an admin can assign it directly. When an access package assignment carries an expiry date, the sponsor is the one notified about the pending expiry, and the sponsor decides whether to request an extension or let the assignment lapse.
Conditional Access for agents isn't fully enforced yet. Applying it requires Microsoft Entra ID P1 or P2 plus a Microsoft Agent 365 licence per user, and Microsoft's own documentation, updated 19 June 2026, states that enforcement of that licensing requirement is coming soon rather than active now. Policies can target three patterns. An agent acting on behalf of a signed-in user. An agent acting as an application under its own credentials. An agent acting through an optional agent's user account, a one-to-one identity that can hold a mailbox and a Teams presence but can never hold a password or a privileged role.
Apply a policy at the blueprint level and it automatically covers every agent identity derived from that blueprint, including ones that don't exist yet. But the list of gaps in Microsoft's own known-issues documentation is long enough to matter. Conditional Access doesn't apply while a blueprint is acquiring a token to create an identity, and a policy scoped to a person's group membership doesn't extend to that person's agent's user account.
Decommissioning follows a timeline now
Microsoft's guidance for agent identity owners recommends sponsors attest every six to twelve months that each agent is still needed. If a sponsor doesn't confirm, the agent becomes a candidate for decommissioning rather than something that just keeps running because nobody remembered it existed. Deleting an agent inside Copilot Studio deletes its Entra Agent ID with it, which removes the agent's ability to authenticate anywhere in the tenant, Copilot Studio included.
Deletion itself is soft first. When the underlying app registration is removed, it moves to a recycle bin for 30 days, recoverable the whole time, and only converts to a hard delete once that window closes. Soft deleted objects still count against directory quota until they're permanently gone, and Microsoft caps third-party platforms using app-only permissions at 250 active agent identities per blueprint. A tenant that reaches that limit may need to force a permanent deletion just to make room for the next agent, rather than waiting for the 30 day window to run out.
What Purview logs
Audit logging is on by default across every tenant, and an admin can't switch off the underlying activity collection, only the audit logs downstream and how long they sit around, according to Microsoft's Copilot Studio logging documentation, updated 18 August 2026. The events that land in the log are specific, including BotCreate, BotDelete, three flavours of BotUpdateOperation covering name changes, authentication changes and publishing, and CopilotInteraction for the actual exchanges between a user and an agent.
Default retention is 180 days. CIAOps' review of Purview's Copilot audit logs, published 11 June 2026, put the maximum at 365 days for tenants on Microsoft 365 E5, with Audit Premium required to stretch past that. The same review flagged a real gap. Purview's logging is scoped to Copilot Studio agents only. It doesn't capture activity from Microsoft's own prebuilt agents or from SharePoint agents, even after those agents have been blocked through Agent 365. The registry can tell an admin an agent exists and can stop it from running. What the audit trail can tell a compliance team about what that agent did still depends on which kind of agent it was.
A Copilot Studio agent used to be something a maker built and something an admin glanced at once, if at all, in a release notes email. A handful of those was easy enough for a maker to carry alone. An agent that provisions its own Entra identity at creation, inherits a sponsor who gets reassigned automatically when that person changes jobs, and sits inside the same directory as every user account in the tenant requires more oversight than a maker can provide alone. Governing it belongs to whoever in the organisation owns identity, and most of those people haven't been told yet that they own agents too.