Microsoft Agent 365 and Entra Agent ID: What It Governs, and the Half It Doesn't
- Microsoft Agent 365 gives each AI agent its own Entra Agent ID for identity, lifecycle and access management. Entra Agent ID is the identity platform underneath it, extending Entra to agents.
- Copilot Studio creates an Entra Agent ID automatically for every new agent, visible and manageable in the Entra admin center. That is a genuinely important default: identity is issued at creation rather than retrofitted.
- Entra ID Governance for agent entitlements brings the human-identity playbook to agents - scoped permissions, ownership accountability, and time-bound access - plus agent sponsorship and lifecycle workflows so an agent does not keep access longer than needed.
- This is the strongest available answer to *who is this agent and who is accountable for it* - and it is the right foundation. It is also top-down by construction: it governs agents that exist because someone registered them in Microsoft's control plane.
- The gap is everything installed rather than registered. Claude Code, Cursor, MCP servers, skills, hooks, CLIs and browser extensions do not appear in Entra, because nobody created them there. They arrive per developer, per repository, per machine.
- Treat the two as complementary halves: Entra Agent ID for agents you provision, endpoint discovery for agents that appear. Neither substitutes for the other, and most organisations currently have only the first.
The most consequential thing Microsoft has shipped in agent security is not a detection feature. It is a default: Copilot Studio now creates a Microsoft Entra Agent ID for every agent you create. Identity at creation, not identity retrofitted later. Anyone who lived through a decade of service accounts nobody owned will recognise how much of the problem that removes before it starts.
Microsoft Agent 365 is the management surface, giving each agent its own Entra Agent ID for identity, lifecycle and access management; Entra Agent ID is the identity platform providing those capabilities. Around them, Entra ID Governance for agent entitlements extends the controls Microsoft already applies to employees: scoped permissions, ownership accountability, time-bound access, agent sponsorship, and lifecycle workflows so an agent does not retain access longer than it needs. This guide covers what that genuinely solves, and the part of the fleet it does not reach.
What it solves well
Four problems that have plagued non-human identity for years, addressed properly rather than partially.
- Attribution. Each agent gets a distinct identity instead of running as a shared service principal or borrowing a developer's credentials. Without this, every downstream control - logging, least privilege, revocation - is guesswork, because two agents behind one identity cannot be told apart.
- Ownership. Agent sponsorship and ownership give every agent an accountable human. This is the control that actually determines whether governance survives contact with reality: an artifact with no owner is an artifact nobody will decommission, review, or answer for.
- Time-bound access. Lifecycle workflows expire access rather than assuming it should persist. Agents are frequently created for a project and outlive it by years, and standing access is how a proof-of-concept becomes permanent shadow infrastructure.
- Scoped permissions. Entitlements per agent rather than a broad grant it might one day need. An agent's blast radius is the set of things it can reach, so scoping is the difference between a contained incident and an enterprise one - see least privilege for AI agents.
Taken together this is a real implementation of what the non-human identity governance discipline has been asking for. If your agents are built in Copilot Studio and run in Microsoft's ecosystem, adopt it. There is no argument to make against it and no reason to build a parallel scheme.
The structural boundary
Every capability above depends on one precondition: the agent exists as a registered object in Microsoft's control plane. Entra can issue an identity, assign an owner, scope entitlements and expire access for an agent that was *created* somewhere it can see. That is what makes the model work, and it is also exactly where it stops.
A large share of agents in a typical engineering organisation were never created anywhere. They were installed. A developer installs Claude Code or Cursor. A project adds an MCP server to a config file. A repository ships a skill, a hook, or a tasks.json entry. Someone adds a browser extension. None of these produce a directory object, none have an owner recorded anywhere, and none appear in an Entra report - not because Entra is deficient, but because there was never a registration event to observe.
| Agent arrives by... | Example | Visible in Entra Agent ID? |
|---|---|---|
| Registration | Copilot Studio agent | Yes - identity issued at creation |
| Registration | Agent published to Agent 365 | Yes |
| Installation | Claude Code, Cursor, Copilot CLI on a laptop | No |
| Installation | MCP server added to mcp.json or .cursor/mcp.json | No |
| Repository content | Skill, hook, .claude/settings.json, .vscode/tasks.json | No |
| Browser | AI extension with page and clipboard access | No |
This is not a hypothetical distinction. Every significant agent-layer incident of 2026 landed in the second half of that table. CVE-2026-10591 rewrote ~/.kiro/settings/mcp.json from hidden text on a web page. DuneSlide overwrote Cursor's sandbox binary via a poisoned tool response. DeepJack installed an MCP server from a deeplink whose command was hidden off-screen. None of those agents had a directory identity, an owner, or an entitlement scope - and an identity platform cannot govern an object it was never told about.
How the halves fit together
The useful framing is not *which tool wins* but which direction each one works in. Identity governance is top-down: it starts from a registration event and attaches controls to it. Endpoint discovery is bottom-up: it starts from what is present on a machine and works out what it is. You need both, because agents arrive from both directions, and the failure modes are different - top-down misses what it never issued, bottom-up cannot by itself decide who should own something.
| Question | Answered by | Why |
|---|---|---|
| Who is this agent, and who owns it? | Entra Agent ID | Identity issued at creation with a sponsor |
| What is it entitled to, and for how long? | Entra ID Governance | Scoped entitlements and lifecycle workflows |
| Which agents exist on our endpoints at all? | Endpoint discovery | No registration event to observe |
| Which MCP servers, skills and hooks are installed? | Endpoint discovery | Repository and config artifacts, not directory objects |
| Did this agent's config change, and did anyone ask? | Endpoint discovery | Config drift is a file event, not a directory event |
| What is this agent doing right now, and should it be allowed? | Runtime enforcement at the tool call | Entitlements are grants; a tool call is an action |
That last row is worth separating from the rest. An entitlement says what an agent may reach; it does not decide whether a specific action now is appropriate. An agent legitimately entitled to read a repository and legitimately entitled to make network requests can still be talked into combining those two into exfiltration by content it read - the lethal trifecta. Identity governance and runtime governance answer different questions, and neither one covers the other.
Where Anomity fits
Anomity covers the bottom-up half. The unprivileged Endpoint Sensor runs on Windows, macOS and Linux and inventories eight AI artifact types per endpoint - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks and CLIs - each with a first-seen timestamp and the endpoint it appeared on. That is the register for everything that arrived without a registration event, and it is what makes an unexplained MCP server detectable by comparison rather than by luck.
It also covers the runtime row. Where an agent exposes a hook - for example the PreToolUse event in Claude Code - Anomity evaluates each call against policy and returns allow, deny, or log before it runs, so an action outside policy is stopped at the boundary regardless of what instructed it. Decisions land in a queryable 90-day audit trail and route to SIEM, Slack, email, or Jira - including into the same SIEM your Entra logs land in, which is where the two halves should meet. Anomity collects metadata only, with on-endpoint secret redaction, is SOC 2 Type II, and explicitly complements existing identity, EDR, DLP and GRC tooling rather than duplicating it. See how it works.
You can't govern what you can't see.The Anomity principle
What to do
- Adopt Entra Agent ID for every agent you build in Copilot Studio or publish to Agent 365. Identity at creation is the correct default and there is no reason to run a parallel scheme alongside it.
- Use agent sponsorship seriously rather than as a form field. An agent with a nominal owner who does not know they own it is functionally unowned, which is the state that produces long-lived orphaned access.
- Set expiry on agent entitlements by default and make renewal deliberate, so a project-scoped agent does not quietly become permanent infrastructure.
- Then count what Entra cannot see. Run an endpoint discovery pass for coding assistants, MCP servers, skills, hooks, CLIs and AI browser extensions, and compare the total against your Entra agent count. The gap is the honest size of your agent estate.
- Give the second half owners too. The artifacts that arrive by installation need the same accountability model as the ones that arrive by registration, even though no directory object exists to hang it on.
- Add runtime enforcement rather than treating entitlements as sufficient. An entitlement is a grant; a tool call is an action, and content the agent reads can direct actions within its grants.
- Send both halves to one place. Entra agent events and endpoint artifact events in the same SIEM is what makes a single answer to *what agents do we have* possible - see how to audit AI agent activity.
- Map the combined picture onto a lifecycle so it produces evidence, per ADLC, and onto controls you can be audited against such as ISO 42001.
Microsoft has built the identity layer the agent problem needed, and issuing an Entra Agent ID at creation time is a better default than most of the industry manages. The limitation is structural rather than a shortcoming: an identity platform governs what gets registered with it, and a large part of the modern agent estate is installed instead - the way AI agents became the new shadow IT. Adopt Entra Agent ID for what you provision, then go and count what appeared. For the identity foundations see AI identity security explained and non-human identity governance, and for building the second register, how to build an AI agent inventory. To see what endpoint discovery returns next to your Entra agent count, request early access.
Frequently asked questions
What is Microsoft Entra Agent ID?
Microsoft Entra Agent ID is an identity and security framework that extends Microsoft Entra to AI agents, giving each agent its own identity so it can be managed at enterprise scale. It is the identity platform underneath Microsoft Agent 365, which uses it to provide identity, lifecycle and access management per agent. In practice the most important behaviour is the default: Copilot Studio automatically creates an Entra Agent ID for each new agent you build, and those identities are viewable and manageable in the Entra admin center. Identity is issued at creation rather than retrofitted, which avoids the shared-service-account problem that has dogged non-human identity for years.
What is the difference between Agent 365 and Entra Agent ID?
Entra Agent ID is the identity platform; Agent 365 is the management surface built on it. Agent 365 gives each AI agent its own Entra Agent ID for identity, lifecycle and access management, and Entra Agent ID provides the underlying identity capabilities that make that possible. Alongside both, Microsoft Entra ID Governance for agent entitlements supplies the governance controls - scoped permissions, ownership accountability, time-bound access, agent sponsorship, and lifecycle workflows that stop an agent retaining access longer than needed. Practically you interact with Agent 365 and Entra admin center, and Entra Agent ID is what issues and holds the identities.
What does Entra Agent ID not cover?
It governs agents that exist as registered objects in Microsoft's control plane - agents someone created in Copilot Studio or published to Agent 365. It does not cover agents that arrive by installation rather than registration, because there is no registration event for it to observe. That excludes coding assistants installed per developer such as Claude Code, Cursor and Copilot CLI; MCP servers added to a config file like mcp.json or .cursor/mcp.json; skills, hooks and .vscode/tasks.json entries that ship inside a repository; and AI browser extensions. None of those produce a directory object or a recorded owner. This is a structural boundary rather than a product shortcoming, and it matters because most significant agent-layer incidents in 2026 involved artifacts from that second category.
Is Entra Agent ID enough on its own?
It is sufficient for the half of the estate it can see, and it is the right foundation for that half. It is not sufficient overall, for two reasons. First, coverage: it can only govern what was registered with it, and installed agents never register. Second, scope: identity governance answers what an agent may reach, which is a grant, not whether a specific action right now is appropriate. An agent legitimately entitled to read a repository and legitimately entitled to make network requests can still be induced to combine the two into exfiltration by content it reads. So you need endpoint discovery for coverage and runtime enforcement at the tool call for scope, alongside identity governance rather than instead of it.
How do we find out how big the gap is?
Compare two numbers. Take your Entra agent count, then run an endpoint discovery pass across managed machines for coding assistants, MCP servers, skills, hooks, CLIs and AI browser extensions. The difference is the honest size of your agent estate, and for most engineering organisations the installed side is considerably larger than the registered side. This comparison tends to be the most persuasive artifact in the whole exercise, because it is concrete, it is specific to your organisation, and it does not depend on accepting anyone's threat narrative.
Should we assign owners to installed agents too?
Yes, and it is the control most worth copying from the Entra model. Agent sponsorship works because an accountable human is what determines whether anything ever gets reviewed, renewed or decommissioned. Artifacts that arrive by installation need the same accountability even though there is no directory object to attach it to - so attach it to the artifact record in your inventory instead. Without it you accumulate MCP servers and hooks that nobody will remove because nobody is answerable for them, which is precisely how orphaned service accounts became a decade-long problem in the human-identity world.
How should identity governance and runtime governance work together?
They answer different questions and should feed one record. Identity governance establishes who an agent is, who owns it, what it is entitled to, and for how long. Runtime governance decides whether a specific tool call should proceed at the moment it is attempted, which is where content the agent has read can direct action within existing entitlements. The integration that matters is destination: send Entra agent events and endpoint artifact and decision events into the same SIEM, so that what agents do we have and what did they do are answerable from one place rather than reconciled by hand across two consoles.
Does this replace non-human identity tooling we already run?
For Microsoft-ecosystem agents it substantially overlaps it, and where it does, using the native platform is usually the better choice than maintaining a parallel scheme. But non-human identity is broader than agents - service accounts, workload identities, API keys and machine credentials all remain in scope, and agents are a new category inside that discipline rather than a replacement for it. The practical approach is to use Entra Agent ID as the identity source of record for registered agents, keep your existing NHI programme for the wider machine-identity estate, and add endpoint discovery for the installed agents neither of them sees.
