Microsoft Agent 365, Entra Agent ID and the Agent Registry: What Changes for a Microsoft 365 Admin

Microsoft Agent 365 is a control plane for the AI agents inside a Microsoft 365 tenant. It gives an administrator one registry listing every agent, lifecycle actions such as approve, block, reassign and delete, and security and data controls delivered through Microsoft Entra, Purview and Defender. Microsoft states it became generally available on 1 May 2026, licensed per user.

That is the short answer. The longer one is more useful, because most of this surface is only months old. It also introduces one idea that genuinely changes how a tenant is administered: an agent is not a feature you switch on. It is an account, with an identity, a lifecycle, a responsible human, and access that somebody granted it.

This article explains the three pieces an administrator has to hold: Microsoft Entra Agent ID, the agent registry, and Microsoft Agent 365 itself. It then covers the part nobody warns you about, which is where the controls you already run stop short of a non-human actor. Every fact here carries the link to the Microsoft page it came from, and we walked all of those links on 20 August 2026. Where two official pages contradict each other, we say so and cite both.

What Microsoft Agent 365 actually is

Microsoft frames the product around three verbs: observe, govern and secure. In practice that means a workload called Agents in the Microsoft 365 admin center. It is wired into Entra, Purview, Defender and Intune, so agent activity turns up in tools your security team already uses.

It is worth being clear about what it is not. Agent 365 does not build agents. Your agents are built elsewhere. That might be Microsoft Copilot Studio, Microsoft Foundry, Agent Builder inside Microsoft Copilot, SharePoint, the Microsoft 365 Agents Toolkit, or a platform with no Microsoft connection at all. Agent 365 is the layer that finds them, records them, and decides what they are permitted to do. Microsoft's own licensing FAQ draws the same line, describing Microsoft 365 Copilot as the AI capability and Agent 365 as the control over what that capability is allowed to do.

The admin center defines an agent as an AI-powered entity that carries out tasks or interactions on its own, or partly on its own, using instructions, context, knowledge sources and tools. Hold on to the word tools. It comes back later, and it is the second thing you get to block.

Microsoft Entra Agent ID: an agent is a security principal

This is the piece to learn first, because everything else follows from it.

Microsoft Entra Agent ID is the identity framework for agents. An agent identity is described as a special kind of service principal in Microsoft Entra ID. Take that literally and the administrative questions write themselves: who created it, who is accountable for it, what can it get to, and when does that access end.

An agent identity has these parts, and each one has an administrative consequence:

• An identifier. Entra generates an object ID that is unique inside your tenant, exactly as it does for other accounts.
• No credentials of its own. Agent identities do not hold passwords, and they do not use the sign-in methods people use — no multifactor prompt, no passkey, no authenticator app. They get tokens from their blueprint through federated identity credentials.
• A display name, which is the human-friendly name that turns up in the Entra admin center, in Teams, in Outlook and elsewhere.
• A sponsor. This records the person or group accountable for the agent, and Microsoft names one specific use for it: somebody to contact when a security incident happens.
• A blueprint. Every agent identity is stamped out from a reusable template.
• Optionally, an agent's user account. Some systems will only authenticate a real Microsoft Entra user account. For those, the agent gets a second account of that kind, marked as an AI agent, in a strict one-to-one pairing with its agent identity.

The agent identity blueprint gives an administrator the most control per action, so it is worth a minute. Picture a template for a kind of employee rather than for one employee. Microsoft's own worked example is a Sales Assistant Agent. One blueprint records the name, the publisher, the roles the agent offers, and the Microsoft Graph permissions its agents receive. Deploy the agent for five sales regions and you get five agent identities from that one blueprint. Because they share a blueprint, an Entra administrator can apply a Conditional Access policy to all of them at once, disable all of them at once, or revoke one permission grant across all of them. That is the difference between governing five agents and governing five thousand.

Two more facts that matter operationally. An agent identity is only ever issued tokens inside the tenant that created it. It cannot go and use resources in a different tenant. A blueprint itself can be multitenant, though, creating local agent identities wherever it is added. And agents come in two access shapes: autonomous, using rights granted directly to the agent identity, and delegated, acting on behalf of a person using that person's rights. Which one you are looking at changes who is accountable and which policies apply.

Finally, a licensing detail that is easy to miss and sits on the Entra pages rather than the Agent 365 ones. Microsoft states that every Microsoft Entra customer has access to Agent ID. Stretching Entra's security features across agents is what requires Microsoft Agent 365. Identity for agents and protection for agents are not the same purchase.

How agents get into your tenant

Three routes, and only one of them begins with an administrator.

They are built inside your tenant. The agent registry is the centralised list, and it sorts agents into four groups: Microsoft agents, external partner-built agents, agents published by your organisation, and agents shared by their creator. Three counters sit above the list — total agents, agents without owners, and unmanaged agents, that last one meaning agents created or managed outside Agent 365 and therefore without its risk protection and observability.

When somebody in your organisation publishes an agent, it needs administrator approval before it becomes available across the tenant. Those land on a Requests tab in one of three states: pending review, pending update or pending activate. You get two decisions: publish it to the store, or reject the submission. Publishing runs a wizard where you choose the audience, apply a policy template, and grant the permissions the agent asked for. Pending update is the quietly important one: while an update waits for you, your users carry on with the previous version.

They are synchronised in from somewhere else. Connected platforms lets you authenticate to an outside AI platform and pull its agents into the registry. Six platforms were listed when we read that page on 20 August 2026: Databricks Genie, Amazon Bedrock, Oracle Generative AI Agents, Salesforce Agentforce, Google Vertex AI and Anthropic Claude Managed Agents. Microsoft says more are being added, and notes that scheduling those synchronisations is planned for a future release — today you press Sync agents. Agents built with Microsoft Foundry, Copilot Studio or Agent Builder are integrated automatically, so this route is for everything else.

Nobody told you about them. The Shadow AI page exists for consumer AI apps and standalone agents that were never approved. Microsoft documents it as a public preview feature, part of the Frontier programme, and warns that its behaviour may change before general availability. Read its capability table carefully before you rely on it. On 20 August 2026 that table listed seven consumer AI tools. Detection was available for all seven. Blocking was available for exactly one of them, OpenClaw. Seeing something and stopping it are separate capabilities here. Viewing Shadow AI agents also requires a Microsoft 365 E5 licence, Intune enrolment for managed Windows devices, and opting in to Frontier.

What you can actually control

Here is the full list of governance and lifecycle actions available from the registry: install and uninstall, block and unblock, delete, start and stop, assign a new owner, publish to store, and reject submission. Start and stop are unique to Microsoft Foundry agents. They act on the underlying Azure compute rather than on how the agent appears to your users, which is also why they need the Azure AI Owner role.

Alongside those, the agent settings page holds the tenant-wide controls. They cover which categories of agent are allowed at all, security templates that preset policies for new agents, who may share agents and how, which users can interact with agents, whether feedback goes back to developers, and tags.

Rules let you apply an action in bulk. It is worth knowing how narrow that is right now: Microsoft documents two supported scenarios. One installs Microsoft's own agents. The other reassigns ownerless Agent Builder agents to the previous owner's manager.

One thing to check before you plan a process around any of this: who can press the buttons. Plenty of roles can view insights and the registry — Security Reader, Global Reader, Reports Reader, AI Reader, Security Administrator and User Experience Success Manager among them. Only two roles can install agents, change them, approve them and manage their configuration: AI Administrator and Global Administrator. If your security team is expecting to approve agents from a Security Administrator role, that will not work.

Blocking an agent and blocking a tool are different decisions

This is the distinction we see people get wrong most often, and it is the one that changes an incident response.

Blocking an agent restricts access to that one agent across the organisation, so no user can use it. Every tool that agent was calling stays live for every other agent in the tenant. You have stopped one worker; the building is unchanged.

Blocking a tool does the opposite. Tools in Agent 365 are the AI-powered services and Model Context Protocol (MCP) servers your agents call, listed under Agents > Tools. Blocking one stops it being called at all — by any agent, and by any workflow. Every agent keeps running. All of them lose one capability at the same moment. You have locked one door in a building where everyone still has their pass.

Choose accordingly. A misbehaving agent is an agent-level block. A tool that turned out to expose more than you thought is a tool-level block. That one will touch agents whose owners have no idea why their agent suddenly cannot do part of its job.

There is a wrinkle in the agent block that deserves testing rather than assuming. Microsoft states that blocking an agent built with Agent Builder or Copilot Studio affects it in Microsoft Copilot and in host products such as Outlook and Teams. Block an agent built with SharePoint or Microsoft Foundry, and the same page says only its availability in Microsoft Copilot Chat is affected. In our reading, "blocked" is not one uniform state. It depends where the agent was built, so verify it in your own tenant before you write it into a runbook.

Two further notes on the destructive end. Deletion is irreversible and removes the agent along with its associated files. Microsoft says it can take up to 24 hours to reach everyone who had access. During that window users may still see the agent listed, but they cannot use it. Reassigning an owner is a hard handover too. The new owner gains full edit and delete rights, plus access to files the earlier owner uploaded. The person who owned it before is left with nothing, not even read access.

For tools you build yourself, the bring your own MCP server flow is documented as a preview feature. A developer uses the Agent 365 CLI to register a remote MCP server. An administrator then reviews the declared tools and either approves or rejects them. Only after that can building surfaces use the server. Microsoft lists Visual Studio Code, GitHub Copilot CLI, Claude Code and Copilot Studio as supported clients during the preview, and says Microsoft 365 declarative agents and Azure AI Foundry are not supported yet.

Where your existing controls do not reach an agent

This is the section we would read first if we were taking over a tenant, and it is the reason this article exists. Microsoft's Purview documentation for Agent 365 is unusually candid. Several of its notes describe places where a control you already run does not behave the way it does for a person. All of these come from the same page, Use Microsoft Purview to manage data security and compliance for Microsoft Agent 365.

Your organisation-wide label permissions probably do not cover agents. Where a sensitivity label applies encryption, that encryption has to name the agent instance and give it both VIEW and EXTRACT usage rights. Microsoft names the two configurations that are not sufficient: a label set to add all users and groups in your organisation, or to add any authenticated users. Those are extremely common settings. An agent meeting such a file does not inherit access from them.

Files have to be shared with an agent by name. Before an agent instance can open a file, Microsoft states, somebody has to share that file with it explicitly. There is no ambient membership that quietly does this for you.

What an agent creates comes out unlabelled. New content produced by Agent 365 does not inherit sensitivity labels from the items it was built from, so it is not automatically labelled and not automatically encrypted. Think about what that means for an agent whose whole job is to summarise confidential material into a new document.

A blocked agent does not know it was blocked. This is the note we found most consequential. Data loss prevention does work on agents: you name the agent instance in the policy the way you would name a user. But Microsoft records that the agent instance is never told a block occurred. Its owner therefore has to watch the policy actively, and work out what the block does to whatever the agent tries next. A person who is blocked sees a dialog and stops. An agent carries on into the next step of its workflow with a gap where the data should have been.

One capability is simply not supported. In Purview's own capability table for Agent 365, everything is ticked except encryption without sensitivity labels, which is marked as not supported.

Two more, from the registry side rather than Purview. The Risks column in the agent registry shows only high-severity risks. A zero there means no high risks right now, not a clean agent, because lower-severity findings live in the security portals. That count can also lag those portals by up to an hour.

Then check who on your team can follow the Review link into them, because the published table is uneven. An AI Administrator gets partial access in Microsoft Entra, and none in Defender or Purview. Security Administrator, Security Reader and Global Reader can reach Defender and Entra. Purview alerts need an Insider Risk Management role inside Purview on top of all that.

Our own view, stated as ours. Many teams assume that having DLP and sensitivity labels already covers them. The gap between that assumption and what these pages actually say is the biggest risk in an early agent rollout. None of it is hidden. It is just spread across four products' documentation, and it only becomes visible when you go looking for the exceptions rather than the features.

What it costs, and where the official pages disagree

Start with the shape, which every page agrees on. Agent 365 is licensed per user, not per agent. Microsoft's licensing FAQ is explicit on three points. Agents do not require licences of their own. Blueprints, agents and agent instances are not separate licensing units. And one licensed user has no fixed cap on how many agents they can oversee. The licence follows the human associated with the agent: the user, the owner, the sponsor or the manager.

On price, that same FAQ gave two list prices when we read it on 20 August 2026. Microsoft 365 E7 is listed at $99 per user per month. A standalone Agent 365 licence is listed at $15 per user per month. List prices are not what an enterprise agreement pays, and prices move. Treat these as a starting point for a conversation with your licensing contact, not as a quote.

For the qualifying bases, the clearest answer is the FAQ's own answer to what all the options are for licensing one user. Every product name below is that page's, unchanged:

The base a user already holds	What has to be added
Microsoft 365 E7	Nothing — Agent 365 comes with it
Microsoft 365 E5, A5 or Business Premium	Add Agent 365
Microsoft 365 with Defender Suite and Purview Suite	Add Agent 365
Office 365 E3 with EMS E3 (Enterprise Mobility and Security), plus the Defender Suite and the Purview Suite	Add Agent 365
Microsoft 365 with Defender Suite Edu and Purview Suite Edu	Add Agent 365
Office 365 A3 with EMS A3, plus the Defender Suite Edu and Purview Suite Edu	Add Agent 365
M365 F1 or F3 with Defender and Purview Suite FLW	Add Agent 365
Office 365 F3 with EMS E3 (K), plus Defender and Purview Suite FLW	Add Agent 365

Now the disagreements. We found three, and we are reporting all three rather than resolving them for you, because resolving them is your licensing desk's job and not ours.

One: how hard the base requirement is. The Agent 365 overview page puts it softly, saying the product "works best" where a tenant already runs Microsoft E5, and calling that "a pre-requisite". The licensing FAQ puts it as a rule. It lists prerequisites by customer type, and states plainly that users who fall short of them are not eligible for Agent 365 at all. Its own example of a user who falls short is Microsoft 365 E3 plus Copilot. A third page, Governing Agent Identities, describes a different combination again for the governance features: Microsoft 365 E7, or an Agent 365 licence alongside Microsoft 365 E3, or at minimum Microsoft Entra P1. Those three sentences do not describe the same requirement.

Two: which capabilities a base plan already includes. The Agent 365 service description carries a feature table whose first column covers First Line Worker plans together with Microsoft 365 Enterprise, Business and Education. That column answers Yes to registry inventory, to basic governance actions, to automating lifecycle actions with conditions-based rules, and to synchronising agents from external platforms. The licensing FAQ puts registry sync, automated agent lifecycle actions, and the Graph API in its list of capabilities that require an Agent 365 licence. Both pages are current and official. They contradict each other on three specific features.

Three: a page that disagrees with itself. The same licensing FAQ answers one question with two lists: what a Microsoft cloud subscription includes, and what needs a licence. Audit logs and eDiscovery for agent activity appears in both of them. We are not guessing which list is correct.

One principle every page does repeat is the tiering. A Microsoft cloud subscription gets you the foundations: core admin governance actions, the registry, agent identity and basic usage insights. Deeper observability, governance and security controls are what a licence buys. Two more planning notes from the FAQ. It says Agent 365 carries no consumption-based cost yet, which is a word worth watching. And Windows 365 for Agents is a separate purchase, billed by the hour at $0.40 per virtual machine, rather than part of Agent 365.

A short note on the certification, if you administer this

You did not come here for an exam, so this is brief.

Microsoft now tests this surface. AB-650 — its full name is Administering Microsoft 365 and AI Services — leads to the Microsoft 365 Certified: AI Services Administrator Associate credential, and it is in beta as of August 2026. One of its three skill areas covers AI services across Microsoft 365, and the study guide weights it at 35–40% of the exam. When we counted that outline's sub-bullets while building our question bank, 24 of the exam's 58 sat in that one area. That is our own measurement, not a Microsoft-published figure. We took it from the outline last updated 27 July 2026, fetched on 19 August 2026. Those bullets name the things this article covers. Entra Agent ID lifecycle workflows. Access packages and Conditional Access for agents. Agent owners, agent settings and the registry. Reviewing requests and publishing or rejecting them. Blocking agents, and managing tools.

On the free practice assessment, Microsoft's wording stays conditional and we will not tidy it up. The exam page says none is available at the moment. It adds that one usually appears "within 8 weeks" of an exam leaving beta and reaching general availability.

If you want to test whether this material has actually stuck, our AB-650 practice exams cover exactly this scope. Every question is traceable to the official Microsoft page behind it, and no dumps are involved. In our experience building that bank, the agent questions are where general Microsoft 365 experience helps least. The surface is too new for instinct, and the exceptions above are precisely what gets tested. For the exam itself rather than the product, start with our AB-650 exam guide. If you are weighing this against the fundamentals-level credential, our AB-650 versus AB-900 comparison is the honest version.

---

Independent study material. ciply.io is not affiliated with, endorsed by, or sponsored by Microsoft.