Agent 365 is GA: wat een IAM-team moet beslissen over Entra Agent ID

Agent 365 ging op 1 mei GA, samen met Microsoft 365 E7, zoals in maart aangekondigd. Op dezelfde dag verdwenen de blades Agent registry en Agent collections uit het Entra admin center (MC1275311). De volledige agent-inventaris, ook van agents zonder Entra-identiteit, staat nu onder Agents > All agents in het Microsoft 365 admin center, leesbaar met de rol AI Reader. Entra houdt de identiteitskant: agent identities, blueprints, permissies, Conditional Access en governance blijven onder Entra ID > Agents, te beheren met de rol Agent ID Administrator (registry convergence).

De pagina met key concepts beschrijft vier objecten. Voor een IAM-team gaat het vooral om waar ze afwijken van een gewone app registration.

De agent identity blueprint is een application-object. Daarin zitten de credentials (federated identity credential, certificaat of secret), de inheritable permissions en de publisher-gegevens. De enige taak van de blueprint in je tenant is agent identities aanmaken en verwijderen. De blueprint principal is de service principal van die blueprint in jouw tenant: dat is de oid in tokens die de blueprint ophaalt, en de actor die je in de audit log ziet als er agent identities worden aangemaakt.

De agent identity is een service principal met een agent-subtype. Hij heeft geen eigen credentials; de blueprint doet zich namens hem voor (impersonation). Object ID en app ID hebben dezelfde waarde, hij is altijd single-tenant, ook als de blueprint multitenant is, en dit is het object waar je permissies aan toekent. Een app registration heeft één service principal per tenant, een blueprint heeft er veel. Daarom noemt Microsoft het aantal blueprints een beslissing over je security boundary: een gelekte blueprint-credential geldt voor elke agent eronder (agent identities vs. service principals).

Het user account van de agent (agent user) is optioneel: een user-object dat 1:1 aan één agent identity hangt. Het krijgt tokens met idtyp=user, kan dus bij API's die alleen users accepteren, en kan een mailbox en licenties hebben. Er is geen wachtwoord of passkey, inloggen kan alleen via de bovenliggende agent identity, en het account kan geen geprivilegieerde beheerrollen krijgen (agent users). In Agent 365 is het agent user-scenario (de "AI teammate" met eigen mailbox) nog een Frontier-previewfunctie, dus de meeste tenants zien eerst agent identities en pas later agent users.

Eén detail zou ik elk IAM-team voorleggen: elke blueprint principal in je tenant krijgt automatisch de application permission AgentIdentity.CreateAsManager, en die toekenning kun je niet intrekken. Je kunt het aanmaken van agent identities alleen stoppen door de principal uit te schakelen of te verwijderen (creation channels). Bij agents van derden komt die principal binnen zodra een gebruiker consent geeft, dus in de praktijk bepaalt je app consent policy welke blueprint principals in je tenant terechtkomen.

Elke agent flow begint hetzelfde: de blueprint haalt met zijn credential een exchange token op voor api://AzureADTokenExchange/.default, met een fmi_path naar de agent identity. Wat daarna gebeurt bepaalt wie het subject van het token is, en daarmee welke Conditional Access policy geldt (Conditional Access for agent identities).

• On-behalf-of: de gebruiker is het subject, de agent identity is de actor. Policies op users gelden, policies op agents niet. Deze sign-ins zie je bij de non-interactive user sign-ins.
• App-only: de agent identity is het subject. Je richt je policy op de agent identity of zijn blueprint. Deze komen in de service principal sign-ins.
• Agent user: de agent identity ruilt zijn token in voor een token op naam van zijn agent user (grant type user_fic). De agent user is het subject, gelogd onder non-interactive user sign-ins.

Die eerste exchange tegen de resource "AAD Token Exchange Endpoint: Public" wordt bewust niet door Conditional Access geëvalueerd, en het Graph-token waarmee de blueprint agent identities aanmaakt ook niet. Agents kunnen verder geen /authorize gebruiken, hebben geen redirect URI's en kunnen geen SSO doen naar webapps via de Entra-aanmeldpagina.

Bij het aanmaken van een blueprint of agent identity is een sponsor verplicht (owners, sponsors and managers). Bij een delegated create wordt de aanroepende gebruiker sponsor als er niemand anders is opgegeven; beheerders met een Agent ID-rol worden bewust niet automatisch sponsor. De sponsor is de zakelijk verantwoordelijke: die kan de agent uitschakelen en sponsors beheren, maar niet aan credentials of configuratie komen. Owners zijn optionele technische beheerders, users of service principals, geen groepen.

Waar het misgaat is het type groep. Een sponsorgroep moet een dynamische groep of een assigned Microsoft 365-groep zijn. De assigned security group die de meeste teams al hebben voor "de mensen die verantwoordelijk zijn voor applicatie X" wordt niet geaccepteerd, een role-assignable groep ook niet. Mijn advies: maak een Microsoft 365-groep met het businessteam dat om de agent heeft gevraagd sponsor, en maak de engineers of de service principal van de deployment pipeline owner. Sponsors van een agent user zijn een andere relatie (ze werken zoals sponsors van B2B-gasten en kunnen het account niet aanpassen), dus zet op beide objecten dezelfde groep.

Nog twee beperkingen hebben invloed op hoe je beheer delegeert: agent identities en blueprints kunnen niet in administrative units, en custom roles ondersteunen geen acties op agent identities. Gescoped beheer loopt dus via ownership. De admin consent workflow werkt ook niet voor permissies die agent identities aanvragen, dus die verzoeken komen buiten de gewone wachtrij bij je team binnen.

Een blueprint uitschakelen blokkeert alle agent identities eronder. Een blueprint of zijn principal verwijderen start een cascade die de agent identities en agent users soft-delete, asynchroon en soms pas uren of dagen later, in de audit log zichtbaar als "Delete service principal" door een actor genaamd Delete Agent Identities Task zonder app ID (agent identity deletion). De blueprint principal terugzetten draait verwijderingen die al gebeurd zijn niet terug. Verwijderen kan niet vanuit het admin center; dat doe je met Graph of Entra PowerShell. Soft-deleted agent identities tellen mee voor de limiet van 250 per blueprint die geldt voor niet-Microsoft-platformen met app-only permissies. De FAQ zegt bovendien nog dat agent users achterblijven als een agent identity wordt verwijderd, dus neem in je runbook voor het opruimen een aparte controle op verweesde agent users op.

Voor sponsors die vertrekken heeft Lifecycle Workflows mover- en leaver-taken die de manager of co-sponsors mailen en het sponsorschap naar de manager overzetten. Hang ze aan je bestaande leaver-workflow.

Over naamgeving: de display name van een agent identity verschijnt in Teams en Outlook en kan door owners worden aangepast, dus stop daar geen classificatie in. Leg omgeving, gevoeligheid van data en goedkeuringsstatus vast in custom security attributes, want daar kan Conditional Access op filteren, en houd de naam van de blueprint als "het soort agent".

In de policy-editor staat alles rond agents nog als preview gemarkeerd: Agents (Preview), All agent identities (Preview) en de conditie Agent risk (Preview). Voor agent identities kun je alles targeten, losse agents, blueprints (inclusief toekomstige agents uit die blueprint) of custom security attributes, en de enige grant control is Block. Voor agent users is er precies één scope, alle agents die als user optreden, met Block op alle resources. Learn zegt niet met zoveel woorden dat policies op "All users" agent users overslaan, maar gezien die aparte scope ga ik ervan uit dat ze er niet onder vallen en bouw ik de policy voor agent users expliciet. Menselijke controls als MFA en device compliance worden bewust niet toegepast. Met security defaults aan geldt dit allemaal niet.

ID Protection for agents is preview, met zes offline detecties en een Risky Agents-rapport. Confirm compromise zet de agent op high risk, en een policy die blokkeert op high agent risk handhaaft dat dan.

Dit is de policy die ik als eerste zou aanmaken, in report-only, rechtstreeks uit de disable agent identities-documentatie:

De variant voor agent users gebruikt "includeUsers": ["AllAgentIdUsers"] onder conditions.users.

Audit events houden hun basistype: een blueprint is "Add application" (agentType = agenticApp), een agent identity is "Add service principal" (agenticAppInstance), een agent user is "Add user" (agentIDuser). In Graph heb je de header Prefer: include-unknown-enum-members nodig om die laatste waarde te zien. In de sign-in logs filter je op Agent type (Agent ID logs). Vraag je het via Graph op, gebruik dan de enumwaarde uit de agentSignIn-referentie: agenticAppInstance voor een agent identity. Het voorbeeld op de pagina Agent ID logs filtert op AgentIdentity, het label dat de portal toont, en dat weigert Graph met een 400 ("not a valid enumeration type constant"):

Laat het createdDateTime-venster en $top erin staan: zonder die twee doorzoekt de query de hele sign-in-historie van service principals en kan hij tegen de time-out van je client lopen voordat er iets terugkomt.

De Microsoft Graph activity logs maken nog geen onderscheid voor agents. Wil je weten welke calls van een agent kwamen, dan join je ze met de sign-in logs.

Agent 365 kost USD 15 per gebruiker per maand, Microsoft 365 E7 (E5, Microsoft 365 Copilot, Agent 365 en Entra Suite) USD 99. De licentie is per gebruiker, agents die namens een gelicenseerde gebruiker werken hebben geen eigen licentie nodig. De Entra-kant is op Learn sinds 30 april meerdere keren herschreven. De versie die deze week online staat zegt dat Agent ID zelf beschikbaar is voor alle Entra-klanten, dat Conditional Access voor agents Entra ID P1 vraagt en ID Protection voor agents P2 (of voor beide Microsoft 365 E5), terwijl het GA-bericht (MC1296867) zegt dat de governance-functies voor agents Agent 365 vereisen. Reken erop dat dit nog verschuift en kijk het opnieuw na voordat je iets tekent.

Update juni 2026: Microsoft heeft de service plans "Entra Conditional Access for Agents" en "Entra ID Protection for Agents" toegevoegd aan Agent 365 en Microsoft 365 E7, met uitrol in juli en augustus 2026; tenants die een van beide gebruiken zonder Agent 365 of E7 hebben die licentie nodig om ze te blijven gebruiken (MC1395007).

Om mee te beginnen: zet de block policy hierboven in report-only, laat hem een paar dagen draaien en gebruik de report-only-resultaten om elke agent identity en blueprint op te sommen die daadwerkelijk tokens aanvraagt. Controleer per stuk of de sponsor een groep van een ondersteund type is, en kijk welke gebruikers consent mogen geven aan apps, want dat bepaalt welke blueprint principals überhaupt je tenant in komen.

• agentSignIn resource type (Microsoft Graph beta)
• Microsoft blog: Introducing the first Frontier Suite built on intelligence and trust (9 maart 2026)
• MC1275311: Agent registry en Agent collections verdwijnen uit het Entra admin center
• MC1296867: Microsoft Agent 365 algemeen beschikbaar
• Agent registry convergence met het Microsoft 365 admin center
• Key concepts van Microsoft Entra Agent ID
• Agent identities, service principals en applications
• Agent users in Microsoft Entra Agent ID
• Creation channels voor agent identities
• Conditional Access voor agent identities
• Owners, sponsors en managers van agent identities
• Verwijderen van agent identities
• ID Protection voor agents (risky agents)
• Agent identities uitschakelen met Conditional Access
• Sign-in- en auditlogs voor agents
• Microsoft Entra-licenties: Agent ID
• MC1395007: service plans voor Conditional Access en ID Protection voor agents in Agent 365 en Microsoft 365 E7