Observe, govern, secure: what agent identity in Agent 365 is actually good for
Every policy, every risk score, every audit query, every data protection rule that you'll ever apply to an agent needs one thing first: a way to identify that agent. That's what Microsoft Entra Agent ID provides, and it's why agent identity matters more than its modest name suggests.
If you're responsible for security or governance in a Microsoft tenant, the control plane built for managing agents and what they can do in your tenant is Agent 365, and identity is what drives every part of it.
The control plane, briefly explained
Microsoft Agent 365 went GA on 1 May 2026. It's the control plane for agents: Microsoft's one place to see, govern, and shut off the agents it knows about. It's less a single product than a coordination layer across products you mostly already run: the Microsoft 365 admin center, Entra, Purview, and Defender. But while we're used to using these controls to govern, monitor and secure user and application access, Agent 365 gives us the ability to point it at a new population. This is what you can do with Agent 365:
- Observe. A central registry of the tenant's registered agents, in the Microsoft 365 admin center: what exists, who uses it, whether it's healthy or ownerless.
- Govern. Lifecycle management, access control, and compliance: the right permissions, policies, and reviews per agent.
- Secure. Entra enforcing risk-based access, Purview watching the data agents touch, Defender detecting threats against and through them.
Every item on that list assumes the same thing:
A registry needs entries that map to real, distinct agents. Access reviews need a principal whose access is reviewable. A risk score needs a subject. Purview can only attribute data activity to an agent if the agent is somebody.
An agent needs an identity for the entire system built around managing it to work.
Observe: an inventory you can query
Agent identities are discoverable and queryable in the Entra admin center and through Microsoft Graph, alongside the registry view in the M365 admin center.
Don't rely entirely on it to solve your shadow-AI problem, though. Agents built through governed channels show up but an agent someone built outside them has no Agent ID and appears in no registry. Agents on other platforms — AWS Bedrock or n8n, even locally hosted OpenClaw agents — can be brought under the same roof via workload identity federation (a supported way for Entra to trust an identity issued somewhere else, without stored secrets) or Microsoft's auth SDK, but someone has to know they exist in the first place, and onboard them. The inventory is only as complete as your creation channels are governed.
Govern: a human chained to every agent
If you have worked with AI and explored its awesome capabilities, as well as encountered its frustrating limits, you've come to a realisation everyone comes to, eventually: AI cannot be made accountable for what it produces, and it cannot be held responsible for the actions that it takes either. That's a human's job. Agent 365 has given us a control to ensure that we don't lose sight of that. Every agent identity is required to have a sponsor: a person accountable for its purpose, lifecycle, and access reviews. And in the identity governance capabilities for agents (still in preview right now), if the sponsor leaves the company, sponsorship transfers automatically to their manager. Automatic succession for agent accountability is generally a good idea and a step in the right direction. Remember that graveyard of service-accounts that nobody feels responsible for cleaning up? Yeah, no automatic succession is just how it got started.
The same preview layer extends the familiar governance tools to agents: access packages with time-bound assignments and approval workflows, access reviews, lifecycle workflows. Blueprints extend it from one agent to the class: all Copilot Studio agent identities are children of one tenant blueprint, designed to let controls applied at blueprint level reach every agent stamped from it, current and future.
Preview or not, the direction is clear: agents get governed like employees, not like config.
Secure: policies that can finally aim
Conditional Access can target agent identities: require network locations or risk conditions before a token is issued, with separate policy paths for agents acting autonomously and agents acting on a user's behalf. Identity Protection extends risk detection to agents, flagging risky ones the same way it flags risky users. Sign-ins and activity land in Entra logs, marked as agent activity.
And when something goes wrong, you have an incident response that works: disable the specific agent identity in the admin center, or use Conditional Access to block token issuance for whole categories of agents, reversibly and tenant-wide.
For the record-keeping crowd: where EU AI Act logging and oversight obligations apply, per-agent identity with per-agent logs is the natural substrate for meeting them.
Where the chain stops
A control plane this coherent invites over-trust, so remain vigilant.
Identity doesn't validate actions. The whole stack can give you an answer to which agent, with what access, under what policy, did what, but it cannot decide for you whether the action was right. That check stays human.
The estate is split until migration finishes. Agents created before July 2026 still run on app registrations. Microsoft has assured that governance works for both populations during the transition and migration will come, but today your inventory has two kinds of entries. Keep that in mind when you're trying to get control of your agent estate and design your approach accordingly.
Some of this is preview. Identity governance for agents: preview. Dataverse agent users: preview. The identity platform is available to all Entra customers and Agent 365 itself is GA but several of the most interesting controls around them aren't there yet.
The enforcement features carry licensing. Extending Entra's security features to agents takes Microsoft 365 E7, or E5 plus an Agent 365 add-on licensed per user.
Four questions to take to your own tenant
Pick one agent you know exists, a real one, in production or close to it and answer four questions from your admin tools alone:
- What can it access?
- Who is accountable for it?
- What did it do last week?
- How would you shut it off in five minutes?
With an agent identity in place, every one of those has a place to look: its permissions in Entra, its sponsor, its sign-in logs, its disable button. Without one, each answer is an archaeology project through service accounts, connection ownership, and someone's memory of who built what.

0 comments