Somewhere in most Microsoft 365 tenants right now, someone outside IT has built a Copilot Studio agent. It answers HR questions, or drafts responses from a SharePoint knowledge base, or chains a few connectors together. What many IT teams haven't yet registered is that each of those agents now has its own identity in Microsoft Entra ID, created automatically, sitting in the same directory as every staff member and service account. That is not a problem. It is the fix for a problem, and it arrived whether or not anyone planned for it.
Microsoft rolled this out through the first half of 2026. Per Microsoft's Copilot Studio documentation (checked August 2026): before May 2026 each new agent got a standard Azure app registration; from the May 2026 rollout, Copilot Studio automatically creates a Microsoft Entra Agent ID for every new agent, and the environment-level opt-out was removed at the same time. Every new Copilot Studio agent receives a Microsoft Entra Agent ID at creation, full stop. For anyone accountable for identity or security posture, the question has shifted from whether agents should be governed as identities to whether yours actually are.
What a Microsoft Entra Agent ID actually is
An agent identity is an account in Microsoft Entra ID built specifically for AI agents. It is not a user account and not a classic app registration. Microsoft's design recognises that agents behave differently from both: they can be created and retired dynamically, sometimes in large numbers, and they act with a degree of autonomy that neither the workforce identity model nor the service principal model was designed to represent.
The platform introduces four object types worth knowing by name:
- Agent identity blueprint: the template an agent platform (such as Copilot Studio) registers in the tenant. Policies applied at the blueprint level are inherited by every agent identity created from it.
- Agent identity blueprint principal: the blueprint's representation in a given tenant, similar to how a multi-tenant application has a service principal in each tenant it operates in.
- Agent identity: the individual agent's account. This is what authenticates, holds permissions, and shows up in sign-in logs.
- Agent user: an optional, paired Microsoft Entra user account for scenarios where an agent must operate as if it were a human user, kept in a strict one-to-one relationship with its agent identity.
Two details matter for governance. First, every agent identity records a sponsor: the human user accountable for the agent's lifecycle and access decisions. When a Copilot Studio maker creates an agent, they are recorded as its sponsor. Second, agent authentication is logged in Microsoft Entra ID as agent activity, distinct from user and application sign-ins, so an investigation can attribute an action to a specific agent rather than a generic app registration.
What changed in 2026, and what it means for existing agents
Before this rollout, Copilot Studio provisioned a standard Azure app registration for each agent. Those worked, but Microsoft Entra treated them as ordinary applications, invisible to agent-specific governance. The 2026 change replaced that model for new agents: when the first agent is created after rollout, Copilot Studio adds a blueprint named Microsoft Copilot Studio agent identity blueprint to the tenant, and every agent identity it creates is a child of that blueprint. Deleting an agent in Copilot Studio deletes its Agent ID with it, so retired agents don't leave orphaned credentials behind.
Existing agents created before the rollout keep their app registrations for now. Microsoft has said it will migrate them in a future update, and governance tooling works across both identity types during the transition. There is a manual path today, but it is a recreate-and-deprecate process, not an in-place conversion: build a new agent with Agent ID enabled, reconfigure channels and connections by hand, run both in parallel, then decommission the old one. Microsoft's own guidance is blunt about production agents: for high-usage agents with Teams channels and flow dependencies, wait for the automated migration path rather than recreating them manually. Frontrow's read is the same. Inventory and classify now, recreate the medium-usage agents where the governance benefit justifies the effort, and leave production-critical agents alone until Microsoft ships the automated path.
Where agents appear in Entra, and what to look at first
Agent identities appear in their own area of the Microsoft Entra admin center, separate from enterprise applications, giving admins an inventory of agents operating in the tenant. Sign-in and audit logs record agent authentication events the same way they do for users. For a first pass over an unfamiliar tenant, three things are worth pulling up:
- 1The agent inventory itself. Compare what Entra shows against what the business believes exists. The gap is usually informative in both directions: agents nobody remembers building, and agents still running on legacy app registrations that don't appear as agents at all.
- 2Connector permissions. When a maker publishes a Copilot Studio agent, the Power Platform connectors it uses are attached to its Agent ID as API permissions. An Entra admin can now see what an agent can reach (SharePoint, Dataverse, a custom connector) without opening the Power Platform admin center.
- 3Legacy service principals. Pre-rollout agents can be identified by tags Copilot Studio stamped on their service principals, most reliably AgentCreatedBy:CopilotStudio. That tag sweep is how you find the shadow inventory.
Conditional Access, lifecycle, and the licensing reality
The point of giving agents real identities is that the existing identity security stack starts to apply to them. Conditional Access policies can target agent identities, including the connector permissions on a Copilot Studio agent, with conditions such as network location, device compliance, or risk. Policies can be applied at the blueprint level, so every agent created from that blueprint inherits them: a genuinely useful control given agents can be created by makers faster than a security team can review them. Microsoft Entra ID Protection extends risk detection to agents, flagging anomalous agent behaviour the way it flags risky user sign-ins.
On the lifecycle side, Microsoft Entra ID Governance treats agents as first-class citizens. Agent identities can be granted access through access packages with expiry dates and approval flows, requested by the agent itself, its sponsor, or an administrator. As an expiry approaches, the sponsor is notified and must actively extend or let access lapse. If a sponsor leaves the organisation, sponsorship transfers automatically to their manager, so no agent is left without an accountable human. That is a joiner-mover-leaver process for software, and it closes the classic failure mode where an automation keeps running for years on permissions nobody remembers granting.
The licensing line matters and is easy to misread. Agent ID itself, the platform for creating and managing agent identities, is available to all Microsoft Entra customers at no extra cost. Extending the Entra security features to agents (Conditional Access enforcement, ID Protection, ID Governance for agent lifecycles) requires Microsoft Agent 365, which is included in Microsoft 365 E7 and available as an add-on to E5, A5 and Business Premium. Budget owners should treat agent governance as a licensed capability to plan for, not a free by-product of the rollout.
The APRA angle: agents are identities, and identities are in scope
For APRA-regulated entities, the regulatory logic is straightforward even where the guidance doesn't yet name AI agents. CPS 234 requires information security controls proportionate to the threats facing information assets, and access control is at the centre of it. CPS 230 requires operational risk management across critical operations, including the technology that runs them. An AI agent that reads a knowledge base, writes to a system of record, or actions a workflow is exercising access, and a regulator reviewing an incident will ask the same questions of an agent that it asks of a user account: who authorised this access, when was it last reviewed, who was accountable, and where is the evidence.
Before Agent ID, honest answers to those questions were hard to produce for low-code agents. The access lived in a tangle of maker credentials, connection references and platform-managed service principals. With agents as directory identities, the answers become the standard ones: the sponsor field names the accountable person, access packages carry the approval and expiry record, and the audit log attributes actions to the specific agent. For entities that rely on an MSP or platform vendors to operate this, the supplier-risk dimension of CPS 234 applies too: the governance of agent identities is something to ask your provider to evidence, not assume.
MSP and multi-tenant considerations
For a provider operating across many client tenants, or an internal IT team inheriting environments after an acquisition, a few practical points:
- The blueprint model is per-tenant. Each client tenant gets its own Microsoft Copilot Studio agent identity blueprint when its first post-rollout agent is created, and blueprint-level Conditional Access must be configured tenant by tenant. Build it into the tenant baseline rather than treating it as a one-off.
- Run the discovery sweep in every tenant: the agent inventory in the Entra admin center for new-model agents, plus the AgentCreatedBy:CopilotStudio tag search for legacy service principals. Most tenants that enabled Copilot Studio before 2026 have both.
- Check sponsors against reality. The sponsor defaults to whoever created the agent. If that was a contractor, a departed staff member whose transfer chain leads somewhere unhelpful, or an MSP engineer's account, reassign sponsorship to an accountable person inside the client's business.
- Fold agent identities into the offboarding runbook. A leaver's agents don't stop working when their account is disabled; sponsorship transfers to their manager, who may have no idea what the agent does. The leaver checklist should surface any agents the person sponsored and force a deliberate keep, reassign or retire decision.
- Agree who owns agent approvals. Access package approval flows are only as good as the approvers behind them. For managed clients, Frontrow recommends naming this explicitly in the service scope: who approves an agent's access request, and against what criteria.