Agent identity governance — the layer your agent inventory doesn't cover

← All articles

Say your organisation has already done the sensible thing: you've inventoried every Copilot agent deployed in your tenant, blocked the third-party ones nobody approved, and scoped the rest to the groups that actually need them. Good — that's the visibility most IT admins still don't have.

It's also only half the picture. Knowing what agents exist and knowing whether they're properly identity-governed are two completely different questions, answered by two completely different parts of Microsoft's platform. An agent can look clean in the Copilot admin catalog — approved, scoped, nothing alarming — while having no accountable owner, no Conditional Access coverage, and no audit trail at the identity layer at all.

Two different layers, two different questions

Agent Inventory answers: which agents are deployed, who published them, and are they available to everyone or a scoped group? That's the Copilot admin catalog — Microsoft built-in agents, custom Copilot Studio agents, and external third-party ones.

Agent identity governance answers a different question: does this agent have a real, governed identity in Microsoft Entra — the same Conditional Access, Identity Protection, and audit log coverage your human staff accounts get? Microsoft calls this Entra Agent ID. An agent identity is an account, just like a user account, that an AI agent authenticates with. And just like a user account, it can be active, disabled, unowned, or quietly ignored since the day it was created.

Why this gap matters in practice: An organisation can pass every "what agents exist" check and still have zero visibility into whether those agents are covered by the same identity controls that protect every human account in the tenant. Governance that stops at the catalog level isn't governance — it's a list.

What "governed" actually means here

Microsoft's own framing is direct: every agent identity should have a designated party accountable for its actions, access permissions, and overall security posture. Not "someone in IT probably knows about it" — a specific, assigned owner, the same way a service account should have one.

A designated accountable owner

Without one, an active agent identity is effectively an orphaned account with nobody responsible for reviewing what it does or deciding when it should be disabled.

The same Conditional Access and Identity Protection coverage as human accounts

Agent identities authenticate like any other identity in Entra. If your Conditional Access policies were built before agent identities existed in your tenant, check whether they actually apply to this identity type.

Attention when Microsoft itself disables an identity

A disabledByMicrosoftStatus flag on an agent identity is Microsoft directly signalling a problem — not a configuration preference, a genuine governance concern that needs investigating before anyone considers re-enabling it.

Why most tenants will show nothing here yet — and why that's fine

Entra Agent ID is new. Most organisations haven't adopted an agent framework that creates these identities at all, and for a tenant with none, that's a completely normal, healthy state — not a gap to panic about. The point of checking isn't to manufacture urgency where there is none. It's to have the visibility ready for the moment agent identities do start appearing, rather than discovering six months in that a dozen of them have accumulated with nobody watching.

Check whether your agent identities are actually governed

M365Clarity checks Entra Agent ID directly — not just what agents exist, but whether they're properly identity-managed.

Run a free scan →