Three weeks ago we wrote that a Dynamics 365 agent is exactly as privileged as the role it inherits, because Copilot Cowork runs as the signed-in user. That was the whole security model, and the practical consequence was that your role design had quietly become a runtime control.
On 25 September Microsoft changed the shape of the problem.
What actually shipped
The new Copilot app arrived with three things in it: Home, where Chat and Cowork meet and requests get routed between them; Code, which builds small internal tools from a description, runs in a sandbox and can be hosted in your own tenant; and Autopilot.
Autopilot is the one worth your attention. Microsoft describes it as a cloud-hosted digital teammate that works without waiting to be prompted. You give it a name, a role and a goal. It watches channels, follows up on threads, runs recurring work, and picks a project back up days later. The example in the announcement is running a full supplier review.
The line that matters is about where it lives. Autopilot sits in your tenant with, in Microsoft's words, "its own identity, memory, computer and workspace". You @mention it the way you would mention a colleague.
Autopilot moved to private preview at the end of September. Alongside it: Today, a proactive command centre, in private preview this month; the Microsoft Copilot Managed Runtime in preview; Dynamics 365 and Power Platform grounding going to public preview over the coming month; and Fabric IQ generally available for Chat and Cowork.
What that changes
Until now, an enterprise agent did its work wearing somebody else's badge. That had one real virtue: the blast radius was knowable, because it was exactly one person's access. It also had an obvious flaw, which is that nobody designed that person's role with an agent in mind.
An agent with its own identity is the better answer. It can be scoped for the job it actually does rather than inheriting whatever a human accumulated over four years. It can be observed as itself. When something goes wrong, the trail leads to a thing rather than to a confused conversation about whether Priya ran that or her assistant did.
But it is not a smaller governance problem. It is a different and larger one, because you have gone from one population of identities to two, and the second one grows faster, never resigns, and does not appear on anyone's headcount.
What it does not change
Microsoft is unusually direct about the work this creates. Entra Agent ID exists so that, in its own words, "agents have a responsible person providing oversight throughout the agent lifecycle and an agent's access doesn't persist longer than needed."
Read that as a specification and it asks for four things you already owe your human joiners:
- Sponsorship and ownership — a named person accountable for each agent, not a team inbox.
- Lifecycle workflows — so access expires rather than accumulating.
- Least privilege at creation — rights to the apps and resources the task needs, and nothing adjacent.
- Conditional Access and risk detection — policies that target agent identities, and alerting on behaviour like reaching for unfamiliar resources or a burst of sign-in attempts.
Agent 365 is the registry that tells you what exists. Entra Agent ID is what gives each one an identity, permissions and protections. Those are two different jobs and it is worth not conflating them: an inventory tells you how many agents you have, which is the question most organisations cannot answer yet. It does not tell you whether any of them should.
Where the work has moved
Into joiners, movers and leavers — for software. Most organisations run this badly for people. The access review is annual, the leaver process depends on a manager remembering, and dormant accounts persist. Now there is a second population with the same lifecycle and none of the natural checkpoints. Nobody notices an agent has stopped being useful. It does not get bored.
Into the question of what happens when the responsible person leaves. If every agent has a named sponsor, then your leaver process has a new step: reassign or retire everything that person sponsored. Ask whoever is proposing this what that step looks like. If the answer is that it has not come up, you have found the gap before it finds you.
Into deciding which agents deserve an identity at all. A thing that reads a queue and calls a tool does not need a mailbox, a calendar and a seat. Issue identity where an agent genuinely acts on its own behalf, and resist it everywhere else, because every identity you create is one you have to govern, review and eventually remove.
Into naming. This sounds trivial and is not. If an agent appears in a channel and is @mentionable, people will treat it as a colleague. What it is called, and whether its name makes clear that it is software, decides how much scrutiny its output gets.
One practical caution
Autopilot is in private preview. Preview is the right place to learn what this changes in your organisation and the wrong place to put a process the business depends on. The sensible move this quarter is not a deployment: it is finding out how many agents already exist in your tenant, and who, if anyone, is answerable for each.
Most organisations we talk to cannot answer that today, and the number is never zero.
What we would do first
Inventory before identity. Use the registry to find what is already running, and give every agent a named sponsor and an expiry date even if the only thing that changes this month is a spreadsheet. Then pick one agent that genuinely needs to act on its own behalf, scope it to the one process, and run it for four weeks with the sponsor actually reviewing what it did.
An agent with its own badge is an employee-shaped object that no one interviewed, nobody onboarded, and no one will remember to off-board. The technology for that arrived in September. The process for it is still yours to build.