Anomity Integrates with Microsoft Entra ID

Anomity now integrates with Microsoft Entra ID. Connect a tenant and Anomity reads the AI agent identities in Entra Agent ID, including every agent Copilot Studio creates, the blueprints behind them, the enterprise apps employees and administrators consented to in Microsoft 365, and the tenant's consent and Conditional Access posture. It lands all of it in the AI Applications inventory and turns the gaps into findings. The connector is available today from Settings, under Integrations, together with an Azure AI Foundry connector that reuses the same consent.

This post explains what the connector reads, what it flags, what it can do about it, and why the most useful question to ask about the agents in a directory is who answers for them.

Why Microsoft Entra, and why now

Entra Agent ID gives every AI agent in a tenant a first-class directory object: an owner, a sponsor, permissions, a risk level and sign-in logs. Copilot Studio creates one each time somebody in the business builds an agent. That is the right direction, and we looked at its scope in Microsoft Agent 365 and Entra Agent ID: what it governs, and the half it doesn't. It also means a tenant can hold a growing population of agents that nobody in security created, and that run entirely in Microsoft's cloud. No endpoint sensor will ever see them.

Entra lists those agents. What a security team needs on top is a policy layer, a findings queue, and a view across vendors: the same governance questions asked of every agent identity at once, and answered next to the AI apps in Google Workspace and GitHub. The first of those questions is accountability, the point we argued in our guide to non-human identity governance: an agent that can act needs an owner, a credential someone maintains, and a way to be turned off.

What the connector reads

Everything comes from read-only Microsoft Graph application permissions. The connector records four kinds of row.

Where the tenant is licensed for them, four activity signals are added: Microsoft's own risk verdict on each agent from ID Protection, last sign-in and sign-in count over a 30-day window, who consented to each app and when, from the audit log, and the Copilot agent catalogue from Agent 365. Raw sign-in events are never stored, only last-used and a count. Copilot agents are kept as their own rows and cross-referenced to a matching agent identity where one exists, rather than merged on a guess or counted twice.

Delegated versus application permissions

This is the distinction that matters most in a Microsoft tenant, and the two share one set of names. A delegated Mail.Read reads the mailbox of the one person who consented. An application permission called Mail.Read reads every mailbox in the tenant, forever, with no signed-in user and no session to revoke. Anomity labels application permissions separately and scores them higher, so the largest risk on the Microsoft side is not averaged into the same number as a single person's consent.

What it flags

Agent identities run through a new agent identity posture policy type, with a seeded template, AI agent identity with nobody accountable for it, at high severity. Like every seeded policy it is off until you switch it on, and each check can be turned on or off.

• Nobody accountable. No owner or sponsor is assigned to the agent.
• Orphaned agent. Every person accountable for it has a disabled account. The agent has outlived the people answerable for it, and can still sign in.
• Static or expired credential. The blueprint holds a static client secret, or one that has already expired, a sign nobody is maintaining it.
• Denied application permission. The agent or app holds an application permission your policy does not allow.
• Directory role held by an agent, exercised with no person present.
• Disabled by Microsoft. Microsoft disables identities for suspicious or abusive activity, so this needs investigating rather than re-enabling.
• Multi-tenant blueprint, and open tenant consent. The template can be instantiated outside your tenant, or any user can consent to third-party apps on their own.
• No Conditional Access for agents. Raised once on the tenant, not once per agent: one fact, one fix.
• Risky agent. ID Protection has flagged it, the one signal here that something may already have happened.
• Unused agent, inherited permissions, unverified publisher. Off by default, because the last two fire on the normal state of a Copilot Studio tenant.
• Discovery gap. A fact the connector could not read, so its absence is never mistaken for a clean result.

Enterprise apps need no new policy: they flow through the same AI-app policy that governs Google Workspace grants. Findings route to the SIEM, Slack or ticketing like every other Anomity finding.

What it can do: revoke, and disable

Disabling is the most consequential action Anomity offers, so it carries every guard revocation has (administrator only, audited, and followed by an immediate policy re-check so resolved findings close at once) and adds one more: an agent whose blueprint is published by Microsoft is refused, because that is part of your Copilot deployment rather than something someone built on the side. The publisher check reads Microsoft's verification, never a display name.

Write access lives in a second Anomity application with its own consent. Entra admin consent grants every permission an application declares, with no way to accept a subset, so one application holding both read and write would make 'connect read-only' untrue the moment you clicked it. A tenant that never consents to the enforcement application cannot be written to.

How it authenticates

1. In Anomity, open Settings, then Integrations, and choose Connect with admin consent on the Microsoft Entra ID card. The card lists every Graph permission before you go.
2. Sign in to Microsoft as a Global Administrator or Privileged Role Administrator, the roles that can grant tenant-wide application permissions, and review the permissions.
3. Consent. Anomity verifies the signed token Microsoft returns, binds your tenant, and runs a first sync.
4. Click Test at any time. It checks the tenant and whether agent identities are actually readable, so a missing agent permission shows up at Test rather than as an empty first sync.

Anomity stores only your tenant ID; tokens are minted per sync from Anomity's own application. The consent step does not trust the tenant named in Microsoft's redirect, which anyone can edit: the tenant is taken from a signature-verified token tied to the session that started the flow, so one customer can never bind another's directory. The connect card is explicit about Directory.Read.All, which is broad, and why it is needed: reading every delegated permission grant in the tenant requires it.

Licences decide what can be seen

Unlike most connectors, the same correctly configured Entra connector returns different facts in different tenants. Sign-in and audit logs need Entra ID P1 or higher, risk needs ID Protection, and the Copilot catalogue needs Agent 365. Each fact a tenant cannot read becomes a named 'not checked' note, deduplicated so one missing licence is one note rather than one per agent. A risk level Microsoft has formed but the tenant is not licensed to see is recorded as hidden, never as no risk, and an agent is reported as unused only when its sign-in history was readable.

Also in this release

• Groups from Entra. Security groups can be pulled directly from the directory instead of appearing only after a member signs in, so a mapped group starts scoping policies and hook configuration straight away.
• Intune sensor coverage. The Deployment page shows how many Intune-managed computers run an Anomity sensor, and lists the ones that do not.

How Anomity and Microsoft Entra fit together

Entra is the identity plane: it issues the identities, enforces Conditional Access and owns the off switch. Identity alone is not containment, as we argued in the AI agent containment gap, and Anomity covers the other half. The Endpoint Sensor inventories agents, MCPs, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes on every managed device and decides allow, deny or log at the agent hook before a tool call runs; the Browser Sensor covers AI web services and the accounts used in them; and cloud discovery reads the identity planes, from Entra and Okta to the AI apps in Atlassian and the seats and settings in Claude Enterprise.

The Entra connector is where those views meet for Microsoft: every agent identity, who answers for it, what it can reach, and an off switch you can use from the finding. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see it against your own tenant, book a 30-minute demo.