The product story is an assistant that books your meetings. The architectural story is one sentence, and it is the more important of the two: "Every agent operates under its own governed Entra identity, not a shared, anonymous service account, so the work it does is attributable to a known actor" [1].
That line comes from Microsoft's June 2 announcement of Scout, written by Omar Shahine, Corporate Vice President of Microsoft Scout. The announcement introduced a category alongside the product — Autopilots, defined as "always-on agents that work autonomously, with their own identity, and act on your behalf" [1]. Scout is the first one.
Two months on, the meeting-scheduling features have been widely covered and the identity claim has been mostly ignored. It should be the other way around.
What the product actually does
Scout stays active in the background across Teams, Outlook, OneDrive, and SharePoint, spanning cloud, desktop, and web, connected to chats, email, calendar, and contacts. It can extend through desktop apps to browsers, local resources, and Model Context Protocol servers [1].
The behaviors are ordinary coordination work: scheduling and coordinating meetings across time zones, flagging important meetings and generating prep material, identifying upcoming deliverables and blocking calendar time for them, spotting risks like stalled decisions [1].
Underneath, it is built on OpenClaw open-source technology and powered by Work IQ, which learns user priorities and workflow patterns over time [1].
And it is gated hard. Scout is in private preview for select customers and Frontier organizations, requiring Frontier enrollment, Intune configuration, opt-in attestation, and a GitHub Copilot license [1][2]. Nobody is running this at scale yet.
Always-on is what forces the identity work
The reason the identity decision matters is contained in the word "unprompted."
A request/response assistant acts only when a human is present. The human types, the assistant responds, and the human owns the action — attribution is implicit in the session. You do not need a separate identity for a tool that only moves when you push it.
An Autopilot acts at three in the morning with nobody watching. It blocks time on a calendar, moves a file, flags a risk. There is no session to attribute the action to and no human in the room to own it. Attribution has to become structural — a property of the actor rather than an inference from context.
That is the problem Microsoft's Entra-per-agent decision solves, and it is why the phrase "with their own identity" appears in the category definition itself rather than in a security appendix.
Why shared service accounts break
Anyone who has run an incident review against a shared service account knows the failure mode.
The logs show that something authenticated as svc-automation read four thousand documents at 2 a.m. That is the entire forensic record. Which agent? Acting for whom? Under what task? The account is, as the announcement puts it, anonymous — not in the sense of being unauthenticated, but in the sense that authentication tells you nothing about the actor.
Give each agent a first-class directory identity and three things change at once.
Attribution becomes possible. The record names the agent, not the pool it belonged to.
Permissions become scopable per agent. A shared account has to hold the union of every permission any consumer needs, which means every consumer inherits the maximum. Per-agent identities let each one carry only what it uses.
Revocation becomes an operation instead of a project. Disabling a shared service account takes down everything using it, so nobody does it during an incident — they scope down and hope. Disabling one agent's identity affects one agent.
Microsoft layers additional controls on top: credentials scoped to specific tasks and redacted from logs, and enforcement of Purview policies, sensitivity labels, and data-loss-prevention controls "without bypassing them" [1]. That last clause is the interesting one, because bypassing DLP is exactly what a well-intentioned automation account typically ends up doing — it is granted broad access so it can work, and the policy engine sees a trusted service rather than a user.
These are Microsoft's claims about Microsoft's product, and they describe a design rather than an audited outcome. Worth taking seriously; not worth taking as verified.
Why attribution is not an abstract concern
Separately, and with no connection to Microsoft or Scout, Check Point's July 13 research provides the counterfactual for what happens when autonomous systems act at scale and nobody can reconstruct it afterward.
A single operator ran "Claude Code and GPT-4.1 in parallel" against nine government agencies in Mexico, exposing 400 million records through "more than 5,000 executed commands" with "minimal human direction between steps" [3].
Five thousand commands, minimally supervised. Every question a responder would ask about that incident is an identity question: which actor executed which command, what was it authorized to reach, and when did its authorization change. Those questions have answers only if attribution was built in beforehand.
Check Point also reports that the average organization runs 10 AI applications per month, many without formal approval [3]. That is the shape of the problem per-agent identity is aimed at — not a single rogue agent, but a growing population of them, arriving faster than anyone's inventory.
Work IQ is the other half of the design
Identity answers who acted. Work IQ is Microsoft's answer to a different question: how does an always-on agent know what is worth acting on?
Work IQ is described as the context engine, learning user priorities and workflow patterns over time [1]. That framing is the necessary complement to autonomy. An agent that acts unprompted needs a model of what matters to you, or it will act constantly and wrongly — flagging every meeting as important, blocking time for every deliverable, escalating every stalled thread. The value of an unprompted agent is entirely in its restraint, which is the same conclusion the agent-memory research arrived at from the opposite direction: knowing when not to interrupt is the feature.
The extension surface is worth noting too. Scout can reach through desktop apps to browsers, local resources, and Model Context Protocol servers [1]. That is an always-on agent with a documented path to arbitrary MCP tooling — which is powerful, and which is also exactly why the per-agent identity and the task-scoped credentials are doing load-bearing work rather than decorative work. The broader an agent's reach, the more the identity boundary is the only boundary.
The tension worth naming
Scout is built on OpenClaw [1]. This site documented OpenClaw's security crisis in March — 250,000 stars and 900 malicious skills in the ecosystem.
That is not an indictment of Microsoft's choice. Building an enterprise product on widely-adopted open source is normal, and the governance layer described in the announcement is precisely the kind of thing that a raw open-source runtime lacks. But it is worth stating plainly: the identity and policy controls are doing real work here, and part of what they are working against is the openness of the foundation underneath.
The obvious pushback
"This is vendor governance theater." The strongest version of this objection: Microsoft has commercial reasons to describe its agent platform as enterprise-grade, and every claim in the announcement is self-reported. True. What makes the identity claim more credible than most is that it is checkable — Entra identities either exist per agent or they do not, and any customer in the preview can verify it in their own directory. It is a structural claim, not a performance claim.
"It is private preview, so who cares." Fair for anyone making purchasing decisions. Less fair for anyone making architecture decisions, because the pattern is portable. You do not need Scout to give each of your agents a distinct identity in whatever directory you already run.
"Identity is the easy part." This is the objection with the most substance. Provisioning an identity per agent is straightforward. Deciding what each identity should be allowed to do, keeping that current as the agent's job changes, and reviewing the accumulated permissions of a growing agent population is the hard, ongoing work — and no announcement solves it.
What identity does not solve
Attribution is not intent.
A correctly-identified agent can still be wrong. Purview enforcement stops policy violations, not bad judgment — an agent with exactly the right permissions, acting exactly within policy, can still block the wrong week on your calendar, escalate the wrong risk, or share the right document with the wrong person. Identity tells you who did it. It says nothing about whether it should have been done.
What identity buys is the ability to find out afterward, and to stop it precisely rather than broadly. That is not the whole problem. It is the part you cannot skip.
What to do this week
Count your agents. Then count your identities. If the second number is smaller than the first, you have agents whose actions are not individually attributable — and you will discover which ones during an incident rather than before.
The rest follows from there: scope each identity to what its agent actually uses, and check whether your policy engine sees your agents as distinct actors or as one trusted service that stopped being questioned a long time ago.
Autonomy without attribution is not automation. It is a set of actions nobody can account for, running on a schedule.
References
[1] Omar Shahine, Microsoft — Introducing Microsoft Scout: Your always-on personal agent — (2026-06-02). Blog
[2] Microsoft Learn — Microsoft Scout (Frontier) overview. Documentation
[3] Check Point Research — AI Security Threats in 2026: Insights from Check Point Research — (2026-07-13). Article