AI Agent Identiteit met Microsoft Entra Agent ID: Identiteiten Uitgeven en Beheren

Agents als directory-objecten

Jarenlang was de enige manier om software een identiteit te geven in Entra een service principal — wat een app vertegenwoordigt, niet iets dat namens een persoon handelt. Entra Agent ID verandert dat. Een agent wordt gemodelleerd als een agent-identiteitsblauwdruk: een bovenliggende registratie die de authenticatiegegevens en de gedeclareerde gedelegeerde machtigingen bevat, met individuele agent-identiteiten als onderliggende elementen. Agents die zijn gebouwd in Copilot Studio en Azure AI Foundry krijgen deze automatisch, en Entra ID Governance voegt eigenaarschap, toegangsbeoordelingen en certificering voor hen toe (in preview).

Dit is de directory-native versie van het idee dat we beschrijven in wat AI-agentidentiteit is: de agent is een principal die u kunt bezitten, beoordelen en beheren — geen anonieme sleutel.

Agent-bewuste on-behalf-of

Het onderdeel dat Entra Agent ID nuttig maakt voor agents, en niet alleen voor apps, is het profiel van RFC 8693 token exchange. De agent wisselt het token van de gebruiker in voor een downstream token dat de gebruiker behoudt als sub en actor-facet claims bevat (act en xms_act_fct) die de agent identificeren. De uitwisseling verloopt in drie stappen:

1. De client meldt de gebruiker aan via Entra en ontvangt een gebruikerstoken dat is gericht op de blauwdruk van de agent.
2. De agent roept het Entra token-eindpunt aan met grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer en requested_token_use=on_behalf_of, waarbij het gebruikerstoken wordt doorgegeven als de assertion, plus zijn eigen client assertion.
3. Entra valideert de audience-keten en retourneert een samengesteld token dat is gericht op de downstream bron — sub = de gebruiker, act = de agent.

Het resultaat is hetzelfde token met twee subjecten waar het hele agent-identiteitsmodel van afhangt, zoals beschreven in agentidentiteit en on-behalf-of-delegatie — alleen maakt Entra het hier aan, niet de gateway.

Hoe TrueFoundry past

Entra bepaalt wie de agent is; TrueFoundry beslist wat deze mag doen en maakt het aanroeppad afdwingbaar. Vier stappen verbinden ze:

1. Registreer Entra als identity provider onder Platform → Identity Providers, met de issuer, audiences en JWKS van de tenant, zodat de gateway door Entra uitgegeven tokens kan valideren.
2. Registreer elke agent als ondersteund door een identity provider, waarbij claimwaarden uit het Entra-token van de agent worden gekoppeld (bijvoorbeeld het applicatie/client ID). De agent authenticeert bij Entra via client credentials of een managed identity en presenteert de JWT aan de gateway.
3. Verleen toegang in TrueFoundry met collaborator grants: wie de agent kan aanroepen, namens wie deze kan handelen en welke MCP-servers en modellen deze kan bereiken.
4. Configureer uitgaande OBO op MCP-servers — stel onder Auth Data → OAuth2 de Grant Type in op Token Exchange (on-behalf-of), richt deze op het token-eindpunt van de tenant en stel de audience in op de doelbron. De gateway voert de uitwisseling per aanroep uit.

Waar teams de fout in gaan

• Eran uitgaan dat Entra alleen de aanroep beheert. Entra geeft de identiteit uit en kan het samengestelde token aanmaken, maar het bepaalt niet welke MCP-servers of modellen een agent mag bereiken en verbindt geen multi-hop ketens. Dat afdwingen is de taak van de gateway.
• Niet-Microsoft-doelen vergeten. Entra's OBO bereikt door Entra beschermde bronnen. Een Jira- of Snowflake MCP-server heeft nog steeds brokering of OAuth per gebruiker nodig — de gateway verwerkt deze naast het Entra-pad.
• Preview-functies als definitief beschouwen. Entra Agent ID is in ontwikkeling en gedeeltelijk in preview; verifieer het huidige gedrag in de documentatie van Microsoft vóór een productie-uitrol.
• Conditional Access voor agents negeren. Aanmeldingen van agents kunnen worden gedekt door Conditional Access — gebruik het, in plaats van er van uit te gaan dat een agent-identiteit is vrijgesteld van de controles die u op mensen toepast.

Geeft u al agent-identiteiten uit in Entra?

Beheer hun pad

Een uitgewerkt voorbeeld

Een onderneming standaardiseert op Entra voor alles en wil haar agents ook in de directory. Een planner-agent krijgt een Entra agent-identiteit (blauwdruk plus onderliggende identiteit), en het team registreert Entra als identity provider in TrueFoundry en de agent als ondersteund door een identity provider, waarbij het client ID wordt gekoppeld. Ze verlenen de relevante gebruikers Agent Access, voegen de agent toe als collaborator op de door Entra beschermde MCP-servers die deze nodig heeft, en stellen de uitgaande authenticatie van die servers in op Token Exchange (on-behalf-of). Wanneer een verzoek van een gebruiker nu een samengesteld Entra-token genereert (sub = gebruiker, act = agent), valideert de gateway dit, autoriseert het paar, stuurt de OBO-uitwisseling naar elk doel aan en legt elke hop vast. Wanneer de agent een niet-Microsoft-tool nodig heeft, bemiddelt de gateway die authenticatiegegevens zonder het Entra-pad te wijzigen.

Handig om te weten

• Entra Agent ID is gedeeltelijk in preview. Functies zoals Governance-certificering voor agents zijn in ontwikkeling — controleer de documentatie van Microsoft voor de huidige status.
• Copilot Studio- en Foundry-agents krijgen automatisch Entra Agent IDs en kunnen in TrueFoundry worden geregistreerd als embedded (governance-only) agents om hun uitgaande MCP-aanroepen te beheren.
• Het samengestelde token is gericht op de downstream bron; de gateway vernauwt de audience en scope per hop, dus controleer of de doel-audiences overeenkomen.
• Uitwisseling per hop wordt binnenkort uitgerold; controleer voor multi-agent ketens hoe delegatie is ingericht in uw versie.
• Niet-Microsoft-doelen vereisen de brokering van de gateway — Entra OBO alleen kan ze niet bereiken.

De rest van de Entra Agent ID-toolkit

On-behalf-of is de blikvanger, maar Entra Agent ID is een verzameling mogelijkheden. Kennis van de hele set helpt u bepalen wat Entra dekt en wat nog steeds een gateway vereist:

• Entra ID als de identity provider — de agent-blauwdruk en de onderliggende identiteiten bevinden zich in de directory en worden op dezelfde manier geauthenticeerd als elke andere principal.
• Entra ID Governance voor agents — eigenaarschap, toegangsbeoordelingen en certificering, zodat een agent-identiteit onderworpen is aan dezelfde periodieke beoordeling als een menselijk account (in preview).
• Conditional Access voor agent-aanmeldingen — dezelfde policy engine die de logins van medewerkers beveiligd, kan die van een agent beveiligen, in plaats van de agent als vrijgesteld te behandelen.

Deze maken de agent tot een beheerd directory-object, niet alleen een geauthenticeerd object — wat het gedeelte is waar een beveiligingsteam om geeft. Wat geen van deze functies doet, is op het moment van de aanroep beslissen welke MCP-servers en modellen de agent mag bereiken, of een multi-agent keten samenvoegen. Dat is het afdwingen dat de gateway toevoegt.

Wie doet wat

De meest heldere manier om over een Entra-plus-gateway implementatie na te denken, is door verantwoordelijkheden expliciet te scheiden, zodat u van geen van beide zijden verwacht dat ze de taak van de ander uitvoeren:

Lees de tabel als een taakverdeling, niet als een competitie: Entra beantwoordt “wie is deze agent en wiens verzoek voert deze uit?”, en de gateway beantwoordt “mag dit paar dit hier en nu doen — en kan het dat later bewijzen?”

Een opmerking over Copilot Studio- en Foundry-agents

Als u al Copilot Studio- of Azure AI Foundry-agents gebruikt, heeft u Entra Agent IDs, of u ze nu zelf heeft ingesteld of niet — beide maken ze automatisch aan. U hoeft het inkomende verkeer van die agents niet via TrueFoundry te proxyen om ze te beheren; registreer ze als embedded (governance-only) agents, en de gateway beheert hun uitgaande MCP-aanroepen terwijl Microsoft de agent blijft hosten. Dat is de praktische instap: adopteer Entra Agent ID waar Microsoft het al uitgeeft, en plaats de gateway op het tool-call pad om het afdwingbaar te maken. De Foundry-specifieke configuratie wordt behandeld in het beheren van Microsoft Foundry-agents en de no-code casus in het beheren van Copilot Studio-agents.

Gerelateerde artikelen

• Agentidentiteit en On-Behalf-Of-delegatie — het tokenmodel met twee subjecten
• Microsoft Foundry-agents beheren — de Foundry-specifieke configuratie
• Microsoft Copilot Studio-agents beheren — de no-code tegenhanger
• TrueFoundry en Okta Cross App Access — het alternatief op basis van Okta
• Wat is een MCP Gateway? — het beheren van de tool-aanroepen zelf

Conclusie

Entra Agent ID lost de identiteitshelft van het probleem op: agents worden directory-objecten met eigenaren, toegangsbeoordelingen en een agent-bewuste on-behalf-of-flow die de gebruiker als sub behoudt en de agent als actor noemt. Wat het niet doet, is bepalen welke tools en modellen een agent mag bereiken, multi-hop ketens verbinden of niet-Microsoft-doelen bereiken. Dat is de helft van de TrueFoundry Gateway: het valideert het Entra-token, dwingt machtigingen per hop af, stuurt de uitwisseling aan, bemiddelt bij afwijkende doelen en traceert elke aanroep.

Samen bieden ze wat een directory-native onderneming daadwerkelijk van agents verlangt — identiteit die u uitgeeft in Entra, en een aanroeppad dat u overal kunt beheren en auditeren waar het naartoe gaat.

Koppel Entra Agent ID aan een beheerd aanroeppad.

Boek een demo