Cut-paper illustration of an employee ID badge with a robot head, connected by dotted lines to an envelope, a calendar page, and a speech bubble.

On September 25, Microsoft announced its biggest Copilot update yet. CEO Satya Nadella called Copilot "a new OS for work," but the line that mattered most to me had nothing to do with the interface. It was this: Autopilot agents — Microsoft's always-on, long-running agents — now get their own governed Entra identity and agent user account, complete with a productivity license covering email, calendar, OneDrive storage, and Teams access. They show up on the org chart as themselves, instead of acting through shared service accounts or borrowed user credentials. Autopilot enters private preview by the end of the month.

The durable idea underneath the announcement is one I ran into personally last month. I wrote about a release workflow that needed my approval to proceed, and the fix turned out to be giving the workflow its own identity rather than borrowing mine. Microsoft just validated that pattern at enterprise scale. The question now is what happens when every agent in the tenant gets the same treatment.

What was actually announced

Microsoft structured the update around four components. Home merges Chat and Cowork in the Copilot app. Code generates apps, dashboards, and workflows from natural-language descriptions. Autopilot turns agents into persistent background workers that keep functioning without a new prompt per task. Code-generated apps run on the Copilot Managed Runtime, currently in public preview, which hosts applications inside the customer's own Microsoft 365 tenant boundary under IT governance.

The identity piece is the interesting one. Each Autopilot agent gets a persistent Entra identity and an agent user account — what Microsoft's documentation calls a "digital worker" identity — with its own email address, Teams presence, and a seat on the org chart. The agent runtime moves into the enterprise infrastructure layer, so the scaffolding for long-running agents (identity, state, execution boundaries, organizational context) is built into Microsoft 365 rather than assembled by hand. Billing for the agentic features runs on usage through Copilot Credits.

This is Entra Agent ID growing up

This didn't come out of nowhere. Microsoft introduced Entra Agent ID as first-class identity and access management for AI agents, and it became generally available on May 1, 2026 as part of Microsoft Agent 365. The model is straightforward: the same tenant, the same admin center, the same security policies govern agents alongside humans and workloads. Conditional Access, Identity Protection, and Identity Governance all gain agent-aware modes instead of being replaced by new tooling. Supported protocols include OAuth 2.0, MCP, and A2A.

The migration is already underway. Message center post MC1478488 kicked off self-service migration of Copilot Studio agents to Entra Agent ID on August 24, 2026, with automatic migration of remaining agents starting this month. The pitch: audit logging in Entra ID, agent lifecycle management, integration with Entra ID Governance, and connector permissions visible as API permissions on the agent identity — so admins can see what an agent can do without opening the Power Platform admin center. Those permissions can then be targeted by Conditional Access policies: network location, device compliance, risk conditions.

Why this kills the shared service account

The old pattern for giving an agent access was depressing in its familiarity: wire it through a shared service account, or worse, a borrowed user credential. Everyone in operations has seen where that leads. Audit logs point at a generic account and nobody can say which automation did what. Permissions accrete over years because removing them might break something nobody documented. Offboarding is "disable the account and pray nothing else was using it."

A first-class agent identity fixes the structural problem. The agent has a name, an owner, a scope, and a trail. Its permissions are visible where every other permission in the tenant is visible. Conditional Access treats it as the thing it is rather than as a human who never sleeps. This is the identity version of the lesson I keep relearning: the fix is rarely more cleverness, it's giving the thing its own boundaries.

The skeptical part: an identity is not governance

Minting the identity was the easy part. Here are the questions I'd want answered before letting agents hold Entra identities in a tenant I manage:

Who owns it when the sponsor leaves? Joiner/mover/leaver works for humans because HR tells us when someone leaves. Who tells Entra when an agent's purpose ends? Lifecycle Workflows for agent sponsors is still in preview, which tells you this problem is recognized but not solved.

How do you do least privilege for something autonomous? Access reviews assume a human can attest "yes, I still need this." An agent can't attest. So who reviews the agent's permissions — and on what evidence?

What's the cost model for a fleet? A productivity license per agent plus usage-based Copilot Credits. Fleets of agents get expensive in a way that's hard to forecast and hard to attribute to a cost center. Finance is going to have questions.

What's the blast radius? Netwrix found a 43% breach rate among organizations where AI had significantly expanded the number of identities needing access, compared with 11% where it hadn't. A Cloud Security Alliance survey found fewer than a quarter of organizations have a formally adopted policy for creating or removing the identities their AI systems run on. We're minting identities faster than we're governing them.

If I were writing the acceptance checklist for an agent identity in my tenant, it would look like this:

Check What it means Where to verify
Named sponsor A human owns the agent's lifecycle Agent identity owner field
Scoped permissions Only the API permissions the job needs API permissions on the agent identity
Conditional Access Policy targeting the agent identity Entra Conditional Access
Audit + alerting Sign-in and activity logs reviewed Entra audit logs, Sentinel
Defined offboarding What happens when the agent is retired Lifecycle workflow / runbook

Sources

The announcement is genuinely good news for anyone who's been hand-rolling agent identity with service accounts and hope. Microsoft validated the pattern, and the building blocks — audit logging, Conditional Access targeting, governance integration — are the right ones. But the history of identity management says the minting was never the hard part. It's the lifecycle. I'll be watching what happens when the first big tenant has to offboard a thousand agents whose sponsors left two reorgs ago.