Microsoft Entra Agent ID vs. service principals: welke moeten je AI-agents gebruiken?
By Mirko Peters ·
Vergelijk Microsoft Entra Agent ID en service principals. Ontdek waarom AI-agents toegewijde identiteitsframeworks en blueprintbeheer nodig hebben in M365.
Automatically translated with AI from the original post. Read the English original

Bij het uitrollen van autonome AI-medewerkers in Microsoft 365 is de keuze van het juiste identiteitsmodel cruciaal. Traditionele service principals beheren al lange tijd standaard applicatieworkloads, maar schieten tekort bij kortstondige AI-agents die in hoog tempo werken. Microsoft Entra Agent ID introduceert een specifieke architectuur die het beheer van referenties scheidt van de machtigingen van agents, waarmee belangrijke beveiligings- en controleerbaarheidsproblemen worden opgelost.
Belangrijkste punten
- Service principals koppelen referenties en machtigingen rechtstreeks aan één applicatie, waardoor kortlevende AI-agents met een hoog tempo moeilijk te volgen en te beveiligen zijn.
- Microsoft Entra Agent ID ontkoppelt referenties door ze op een centrale blueprint op te slaan, terwijl individuele medewerkers elk een unieke agent-identiteit krijgen.
- Agent-identiteiten elimineren lokale geheimen op de agent zelf, waardoor de mogelijke impact van een gecompromitteerd onderdeel sterk afneemt.
- Met blueprints kunnen beheerders bulkbeleid toepassen, levenscyclusbeheer uitvoeren en een absolute noodstop inzetten voor hele groepen AI-agents.
- Beheerde identiteiten blijven ideaal voor code die in Azure draait, terwijl Agent ID's speciaal zijn ontworpen voor autonome AI-agents die zelfstandig beslissingen nemen tijdens de uitvoering.
De identiteitskloof bij AI-medewerkers begrijpen
Agents met kunstmatige intelligentie passen niet netjes in de traditionele identiteitsvakjes van de onderneming. Anders dan standaardgebruikers, die zich aanmelden met wachtwoorden of multifactorcodes, en anders dan traditionele applicaties, die vertrouwen op stabiele, langlopende serviceaccounts, werken AI-agents dynamisch. Een druk geautomatiseerde workflow kan duizenden agent-instanties opstarten en binnen één werkdag weer verwijderen. Wanneer deze kortlevende agents vertrouwen op gedeelde serviceaccounts of menselijke referenties lenen, worden je auditlogs al snel onbetrouwbaar.
Bovendien moeten IT-beheerders bij een incident om twee uur 's nachts twee fundamentele vragen kunnen beantwoorden: welke specifieke agent heeft deze actie uitgevoerd, en wie is hiervoor verantwoordelijk? Traditionele app-registraties en gedeelde service principals maken het bijna onmogelijk om deze vragen te beantwoorden zonder niet-gerelateerde workloads te verstoren. Dit blinde vlek in de operatie is precies de reden waarom Microsoft een gespecialiseerd framework heeft ontwikkeld voor niet-menselijke medewerkers.
Service principals versus Agent ID's: architectuurverschillen
Om te begrijpen waarom Microsoft Entra Agent ID een paradigmaverschuiving betekent, moet je zien hoe het structureel verschilt van een standaard service principal. Een service principal is een één-op-één-instantie van een applicatieobject in je tenant. Die heeft eigen langlevende geheimen, clientcertificaten en directe machtigingstoewijzingen. Voor stabiele, voorspelbare webapps en achtergronddaemons heeft dit model al jarenlang goed gewerkt.
Maar als je een AI-agent een standaard service principal laat gebruiken, ontstaat er flink wat beheerlast:
- Wildgroei aan referenties: Elke keer dat een geautomatiseerde workflow een nieuwe agent-instantie opstart, laat het aanmaken van een nieuwe service principal verspreide clientgeheimen achter in je omgeving.
- Granulariteitsproblemen: Het uitschakelen van één afwijkende agent vereist het doorzoeken van honderden service principals, met het risico dat kritieke bedrijfsprocessen per ongeluk worden stopgezet.
- Onduidelijke audits: Gedeelde applicatieaccounts verhullen welke exacte workflow-instantie toegang heeft gehad tot gevoelige bedrijfsgegevens.
Het Agent ID-model werkt daarentegen met een ouder-kindrelatie via een administratief blueprint. Het blueprint slaat de authenticatiegegevens veilig op en definieert de toegestane scopes. Individuele agent-identiteiten krijgen een unieke identifier en worden dynamisch aangemaakt. De agent-identiteit zelf bevat geen wachtwoord of geheim, dus er is niets dat een aanvaller uit de runtimeomgeving kan halen.
De kracht van blueprints in fleetbeheer
De kerninnovatie van Microsoft Entra Agent ID zit in het blueprint-object. Zie een blueprint als een hoofdsjabloon dat een vloot van verwante AI-medewerkers aanstuurt. Als je organisatie bijvoorbeeld een sjabloon 'Sales Assistant Agent' uitrolt, kun je vanuit die ene definitie dynamisch regionale instanties starten voor Noord-Amerika, Zuid-Amerika en Europa.
Omdat deze agents een gemeenschappelijk blueprint delen, krijgen beheerders krachtige mogelijkheden die moeiteloos meeschalen:
- Gecentraliseerde beleidshandhaving: Een Conditional Access-beleid of een beperking van Microsoft Graph-machtigingen die je op het blueprint toepast, dekt automatisch elke agent-instantie die daaruit wordt gegenereerd, inclusief toekomstige instanties.
- De ultieme noodrem: Als er een kwetsbaarheid wordt ontdekt in een specifieke agentklasse, stopt het uitschakelen van het bovenliggende blueprint direct de authenticatie van elke onderliggende agent-identiteit in de hele tenant.
- Governance via sponsors: Elke agent-identiteit vereist een benoemde menselijke sponsor. Als die sponsor de organisatie verlaat, schuift Microsoft Entra het sponsorschap automatisch door naar diens manager. Zo blijven er geen AI-workloads zonder toezicht achter.
Welk identiteitstype je wanneer gebruikt in je architectuur
Moderne Microsoft 365- en Azure-omgevingen vragen om een gedifferentieerde aanpak voor niet-menselijke identiteiten. Het juiste mechanisme kiezen voorkomt beveiligingslekken en onnodige beheerlast.
Managed Identities voor code die in Azure draait
Als je eigen code, functies of microservices rechtstreeks in de Azure-infrastructuur draaien, kies dan altijd voor Managed Identities. Azure beheert de levenscyclus en de rotatie van credentials automatisch. Er zijn dus geen geheimen die je team moet bewaken of per ongeluk in broncoderepositories terechtkomen.
Service principals voor traditionele applicaties
Blijf service principals gebruiken voor stabiele enterpriseapplicaties, SaaS-integraties en langlopende daemonservices die een persistente, eigen applicatiecontext nodig hebben en gebruikmaken van traditionele client credential flows.
Agent ID's voor autonome AI-medewerkers
Kies specifiek voor Microsoft Entra Agent ID wanneer je AI-agents uitrolt, zoals agents gebouwd in Copilot Studio of in eigen orchestratieframeworks. Deze agents beoordelen situaties dynamisch, nemen autonome beslissingen en werken namens gebruikers of workflows met Microsoft 365-gegevens.
Je cloudtoekomst veiligstellen
Nu autonome kunstmatige intelligentie een kernpijler wordt van digitale transformatie, levert het beheren van AI-agents met verouderde serviceaccounts een onaanvaardbare beveiligingsschuld op. Met Microsoft Entra Agent ID benut je de snelheid en schaal van moderne AI en houd je tegelijkertijd strikte governance, heldere audittrails en robuuste least-privilege-waarborgen op orde. Wil je dieper ingaan op hoe deze mechanismen werken? Luister de volledige aflevering en praat mee over het veiligstellen van de Microsoft-cloud.
Veelgestelde vragen
Slaan Microsoft Entra Agent ID's lokaal wachtwoorden of geheimen op?
Nee. Agent-identiteiten zijn bewust zo ontworpen dat ze geen lokale credentials, geheimen of certificaten bevatten. Authenticatie wordt veilig beheerd door het bovenliggende blueprint, zodat aanvallers geen sleutels uit de runtimeomgeving van de agent kunnen halen.
Hoe gaan agent-blueprints om met multi-tenantuitrollingen?
Blueprints kunnen als multi-tenantsjablonen over organisaties heen worden gepubliceerd. Wanneer een klant het blueprint in zijn tenant uitrolt, zijn de resulterende agent-identiteiten echter strikt single-tenant en lokaal. Zo blijft de impact van een incident binnen de grenzen van je eigen organisatie.
Wat gebeurt er met een AI-agent als zijn menselijke sponsor het bedrijf verlaat?
Om te voorkomen dat AI-medewerkers zonder toezicht onbeperkt blijven draaien, draagt Microsoft Entra het sponsorschap van de agent-identiteit automatisch over aan de directe manager van de vertrekkende sponsor.
Kunnen Conditional Access-beleidsregels rechtstreeks worden toegepast op agentidentiteiten?
Ja. De Conditional Access-engines evalueren aanmeldingssignalen voor agentidentiteiten net zoals voor gebruikers. Door een beleid op een agentblauwdruk te richten, worden die regels bovendien automatisch afgedwongen voor alle huidige en toekomstige agentinstanties die vanuit die sjabloon worden gemaakt.