Identiteitsconcepten van agents in Microsoft Foundry

Een agentidentiteit is een gespecialiseerd identiteitstype in Microsoft Entra ID dat speciaal is ontworpen voor AI-agents. Het biedt een gestandaardiseerd framework voor het beheren, verifiëren en autoriseren van AI-agents in Microsoft-services. Met dit framework kunnen agents veilig toegang krijgen tot resources, communiceren met gebruikers en communiceren met andere systemen.

Microsoft Foundry richt agentidentiteiten automatisch in en beheert deze gedurende de levenscyclus van de agent. Deze integratie vereenvoudigt het beheer van machtigingen, terwijl beveiliging en controlebaarheid behouden blijft wanneer agents van ontwikkeling naar productie gaan.

In dit artikel wordt uitgelegd hoe agentidentiteiten betrekking hebben op Microsoft Entra ID objecten, hoe Foundry deze gebruikt wanneer een agent hulpprogramma's aanroept en hoe u toegang met minimale bevoegdheden kunt toepassen met Azure op rollen gebaseerd toegangsbeheer (RBAC).

Voorwaarden

• Inzicht in Microsoft Entra ID en OAuth-verificatie
• Bekendheid met Azure op rollen gebaseerd toegangsbeheer (RBAC)
• Basiskennis van AI-agents en hun runtime-vereisten

Zie voor Foundry-specifieke RBAC-rollen en -bereiken Azure op rollen gebaseerd toegangsbeheer in Foundry.

Hoe agentidentiteiten werken in Foundry

Foundry maakt gebruik van Microsoft Entra ID agentidentiteiten ter ondersteuning van twee gerelateerde behoeften:

• Beheer en governance: beheerders een consistente manier geven om agenten te inventariseren, beleidsregels toe te passen en activiteiten te controleren.
• Toolverificatie: Een agent laten verifiëren bij downstreamsystemen (bijvoorbeeld Azure Storage) zonder geheimen in te sluiten in prompts, code of verbindingsreeksen.

Op hoog niveau doet Foundry het volgende:

1. Hiermee wordt een blauwdruk voor agentidentiteit en een of meer agentidentiteiten ingericht in Microsoft Entra ID.
2. Wijst RBAC-rollen (of andere machtigingsmodellen, afhankelijk van het doelsysteem) toe aan de agentidentiteit.
3. Wanneer de agent een hulpprogramma aanroept, vraagt Foundry een toegangstoken aan voor de downstreamservice en gebruikt deze token om de aanroep van het hulpprogramma te verifiëren.

Runtime-tokenuitwisseling

Wanneer een agent een hulpprogramma aanroept, vindt automatisch een OAuth 2.0-tokenuitwisseling met meerdere stappen plaats tussen agentservice, Microsoft Entra ID en de downstreamresource. Ontwikkelaars beheren tokens niet rechtstreeks. Agent Service verwerkt de volledige uitwisseling.

De uitwisseling verloopt in vier fasen:

• Blueprint-verificatie: Agentservice presenteert de OAuth-referenties van de blauwdruk aan Microsoft Entra ID. Dit bewijst dat de Agentservice gemachtigd is om namens de blauwdruk en de bijbehorende agentidentiteiten te handelen.

• Agent identity token uitgifte: Microsoft Entra ID valideert de blauwdrukreferenties en geeft een token uit voor de specifieke agentidentiteit. Dit token is niet hetzelfde als tokens voor menselijke gebruikers of beheerde identiteiten. Hiermee wordt de agent geïdentificeerd als een onafhankelijke actor in de directory.

• Gescopeerde tokenaanvraag: De agentservice presenteert het agentidentiteitstoken terug aan Microsoft Entra ID en vraagt een nieuw toegangstoken aan dat is gericht op de doelgroep van de downstreamservice. De doelgroep is de OAuth-resource-id voor de doelservice (bijvoorbeeld https://storage.azure.com voor Azure Storage).

• Geverifieerde hulpprogramma-aanroep: Agent Service geeft het gescopeerde toegangstoken door aan de MCP-server of het A2A-eindpunt. De downstreamresource valideert het token en controleert de RBAC-roltoewijzingen van de agentidentiteit voordat toegang wordt verleend of geweigerd.

De volgende tabel bevat algemene doelgroepwaarden voor globale Azure-services:

Termen die in dit artikel worden gebruikt

Sleutelbegrippen

Het platformframework agent-id introduceert formele agentidentiteiten en agentidentiteitsblauwdrukken in Microsoft Entra ID om AI-agents te vertegenwoordigen. U kunt dit framework gebruiken om veilig te communiceren met AI-agents. Met dit framework kunnen deze AI-agents ook veilig communiceren met webservices, andere AI-agents en verschillende systemen.

Agentidentiteit

Een agent-id is een speciale service-principal in Microsoft Entra ID. Het vertegenwoordigt een identiteit die door de blauwdruk voor agentidentiteiten is gecreëerd en gemachtigd is om na te bootsen.

Beveiligingsvoordelen

Agentidentiteiten helpen specifieke beveiligingsuitdagingen aan te pakken die AI-agents vormen:

• Maak onderscheid tussen operaties die AI-agents uitvoeren en operaties die werknemers, klanten of workloadidentiteiten uitvoeren.
• Ai-agents in staat stellen om toegang te krijgen tot verschillende systemen met de juiste grootte.
• Voorkom dat AI-agents toegang krijgen tot kritieke beveiligingsrollen en -systemen.
• Schaal identiteitsbeheer naar grote aantallen AI-agents die snel kunnen worden gemaakt en vernietigd.

Verificatiemogelijkheden

Agentidentiteiten ondersteunen twee belangrijke verificatiescenario's:

• Gedelegeerd (gedelegeerde toegang of namens-verwerkingsstroom): De agent werkt namens een menselijke gebruiker met behulp van de OAuth 2.0-namens-verwerkingsstroom (OBO). De gebruiker verifieert eerst bij de toepassing en de toepassing geeft het token van de gebruiker door aan agentservice. AgentService wisselt dat token vervolgens uit voor een token dat zowel de agentidentiteit als de gedelegeerde machtigingen van de gebruiker bevat. Deze methode betekent dat de agent alleen toegang heeft tot resources waarvoor de gebruiker toestemming heeft gegeven en waarvoor deze is geautoriseerd.
• Zonder toezicht (stroom voor alleen toepassingen): de agent werkt onder een eigen bevoegdheid, door gebruik te maken van de OAuth 2.0-clientreferenties-stroom. Agent Service verifieert de blauwdruk met Microsoft Entra ID, haalt een token op voor de agent-identiteit, en vraagt een scope-gebaseerd toegangstoken aan voor de downstreamresource. De toegang van de agent wordt volledig beheerd door zijn eigen RBAC-roltoewijzingen, Microsoft Graph machtigingen op app-niveau of ander autorisatiebeleid. Er is geen menselijke gebruiker betrokken.

Blauwdruk voor agentidentiteit

Een blauwdruk voor agentidentiteiten fungeert als herbruikbare sjabloon waaruit alle gekoppelde agentidentiteiten worden gemaakt. Het komt overeen met een soort, type of klasse van agents. Het fungeert als het beheerobject voor alle agentidentiteitsexemplaren van die klasse.

Blauwdrukmogelijkheden

Blauwdrukken voor identiteiten van agenten dienen drie essentiële doeleinden.

Typeclassificatie: Met de blauwdruk wordt de categorie agent vastgelegd, zoals Contoso Sales Agent. Met deze classificatie kunnen beheerders:

• Pas beleid voor voorwaardelijke toegang toe op alle agents van dat type.
• Schakel machtigingen voor alle agenten van dat soort uit of trek ze in.
• Agents op schaal controleren en beheren via consistente besturingselementen op basis van blauwdrukken.

Instantie voor het maken van identiteiten: Services die agentidentiteiten maken, gebruiken de blauwdruk om te verifiëren. Blauwdrukken bevatten OAuth-referenties waarmee services tokens kunnen aanvragen via Microsoft Entra ID voor het maken, bijwerken of verwijderen van agentsidentiteiten. Deze referenties omvatten clientgeheimen, certificaten of federatieve referenties, zoals beheerde identiteiten.

Runtime-verificatieplatform: de hostingservice maakt gebruik van de blauwdruk tijdens runtime-verificatie. De service vraagt een toegangstoken aan met behulp van de OAuth-referenties van de blauwdruk. Vervolgens wordt dat token gepresenteerd aan Microsoft Entra ID om een token voor een van de agentidentiteiten te verkrijgen.

Blauwdrukmetagegevens

Een organisatie kan bijvoorbeeld een AI-agent gebruiken met de naam Contoso Sales Agent. De blauwdruk definieert informatie zoals:

• De naam van het agenttype: 'Contoso Sales Agent'.
• De uitgever of organisatie die verantwoordelijk is voor de blauwdruk: 'Contoso'.
• De rollen die de agent kan uitvoeren: 'verkoopmanager' of 'verkoopvertegenwoordiger'.
• Microsoft Graph machtigingen of gedelegeerde toegangsgebieden: 'lees de agenda van de aangemelde gebruiker'.

Federatieve identiteitsreferenties

De OAuth-referenties van de blauwdruk bepalen hoe de Agent Service zich authenticeert bij Microsoft Entra ID tijdens de runtime tokenuitwisseling. Blauwdrukken ondersteunen drie typen referenties:

De optie federatieve referentie is het meest relevant voor Foundry. Wanneer Foundry een blauwdruk voor de agentidentiteit voor uw project inricht, brengt de blauwdruk een vertrouwensrelatie tot stand met de beheerde identiteit van het project. De verificatieketen werkt als volgt:

• De blauwdruk voor de agentidentiteit heeft een vertrouwensrelatie met federatieve referenties met de beheerde identiteit van het project.
• Tijdens runtime gebruikt Agent Service de beheerde identiteit om de blauwdruk te verifiëren voor Microsoft Entra ID. Er is geen clientgeheim of certificaat nodig.
• Entra ID valideert de gefedereerde referentie en geeft een token uit voor de agentidentiteit van de service-principal.
• Het agent-identiteitstoken wordt vervolgens ingewisseld voor een scoped toegangstoken dat is bedoeld voor de doelgroep van de downstream-resource.

Deze keten is ontworpen om opgeslagen geheimen in de blauwdrukconfiguratie te elimineren. Azure beheert het rouleren van referenties via de infrastructuur van de beheerde identiteit, en elke laag ( beheerde identiteit, agentidentiteit en downstreamresource) heeft onafhankelijke roltoewijzingen met minimale bevoegdheden. Sommige hulpprogrammaconfiguraties maken echter nog steeds de door het project beheerde identiteit beschikbaar als verificatieoptie.

Foundry-integratie

Foundry kan automatisch worden geïntegreerd met Microsoft Entra Agent-ID door identiteiten te maken en te beheren gedurende de ontwikkelingslevenscyclus van de agent. Wanneer u uw eerste agent in een Foundry-project maakt, richt het systeem een standaardblauwdruk voor agentidentiteit en een standaardagentidentiteit voor uw project in.

Gedeelde projectidentiteit

Alle niet-gepubliceerde of in ontwikkeling zijnde agents binnen hetzelfde project delen een gemeenschappelijke identiteit. Dit ontwerp vereenvoudigt het beheer van machtigingen, omdat niet-gepubliceerde agents doorgaans dezelfde toegangspatronen en machtigingsconfiguraties vereisen. De benadering van gedeelde identiteit biedt de volgende voordelen:

• Vereenvoudigd beheer: beheerders kunnen machtigingen centraal beheren voor alle in-development agents binnen een project.
• Verminderde identiteitsgroei: Als u één identiteit per project gebruikt, voorkomt u dat er tijdens vroege experimenten onnodige identiteiten worden gemaakt.
• Autonomie van ontwikkelaars: nadat de gedeelde identiteit is geconfigureerd, kunnen ontwikkelaars onafhankelijk agents bouwen en testen zonder herhaaldelijk nieuwe machtigingen te configureren.

Ga naar uw Foundry-project in de Azure-portal om de blauwdruk voor gedeelde agentidentiteit en agentidentiteit te vinden. Selecteer JSON-weergave in het deelvenster Overzicht. Kies de nieuwste API-versie om de identiteiten weer te geven en te kopiëren.

Afzonderlijke agentidentiteit

Wanneer de machtigingen, controlebaarheid of levenscyclusvereisten van een agent afwijken van de standaardinstellingen van het project, moet u een upgrade uitvoeren naar een afzonderlijke identiteit. Als u een agent publiceert, wordt automatisch een blauwdruk voor een toegewezen agentidentiteit en agentidentiteit gemaakt. Beide zijn gekoppeld aan de agent-applicatiebron. Deze afzonderlijke identiteit vertegenwoordigt de systeemautoriteit van de agent voor toegang tot zijn eigen resources.

Veelvoorkomende scenario's waarvoor afzonderlijke identiteiten zijn vereist, zijn:

• Agents die klaar zijn voor integratietests.
• Agents die zijn voorbereid voor productieverbruik.
• Agents waarvoor unieke machtigingensets zijn vereist.
• Agents die onafhankelijke controlepaden nodig hebben.

Als u de afzonderlijke blauwdruk voor agentidentiteiten en agentidentiteit wilt vinden, gaat u naar de resource van uw agenttoepassing in de Azure-portal. Selecteer JSON-weergave in het deelvenster Overzicht. Kies de nieuwste API-versie om de identiteiten weer te geven en te kopiëren.

Hulpprogramma's voor automatisering en implementatie

Implementatiehulpprogramma's zoals de Azure Developer CLI (azd) bieden beperkte automatisering voor agentidentiteitsmachtigingen:

• Ontwikkeling: azd wijst automatisch de Azure AI-gebruiker toe aan de identiteit van de gedeelde projectagent voor niet-gepubliceerde agenten
• Productie: gepubliceerde agents ontvangen afzonderlijke identiteiten waarvoor handmatige roltoewijzingen zijn vereist

azd configureert containerregister, Application Insights of aangepaste resourcemachtigingen niet. Zie de referentie voor gehoste agentmachtigingen voor productie-implementaties en de volledige machtigingsvereisten voor gehoste agents.

Toelverificatie

Agents hebben toegang tot externe resources en hulpprogramma's met behulp van agentidentiteiten voor verificatie. Het verificatiemechanisme verschilt op basis van de publicatiestatus van de agent:

• Niet-gepubliceerde agents: verifiëren met behulp van de agent-id van het gedeelde project.
• Gepubliceerde agents: Verifieer met de unieke agent-id die is gekoppeld aan de agenttoepassing.

Wanneer u een agent publiceert, moet u RBAC-machtigingen opnieuw toewijzen aan de nieuwe agentidentiteit voor resources waartoe de agent toegang nodig heeft. Deze toewijzing zorgt ervoor dat de gepubliceerde agent de juiste toegang behoudt terwijl deze onder zijn eigen identiteit werkt.

Machtigingen toewijzen aan de agent-id

De agent-identiteit is een service-principal in Microsoft Entra ID. U wijst RBAC-rollen eraan toe op dezelfde manier als u rollen toewijst aan een andere service-principal of beheerde identiteit. Gebruik de agentIdentityId JSON-weergave van uw project of agenttoepassing als de toegewezen gebruiker.

Als u bijvoorbeeld een agent-id lees-/schrijftoegang wilt verlenen tot een opslagaccount, wijst u de rol Inzender voor opslagblobgegevens toe aan het bereik van het opslagaccount:

az role assignment create \
    --assignee "<agentIdentityId>" \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>"

De toewijzing controleren:

az role assignment list \
    --assignee "<agentIdentityId>" \
    --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>" \
    --output table

Algemene roltoewijzingen voor agenthulpprogramma's:

Ondersteunde hulpprogramma's

Momenteel zijn de hulpprogramma's die ondersteuning bieden voor verificatie met een agent-id:

• Model Context Protocol (MCP): gebruik de identiteit van uw agent om te verifiëren met MCP-servers die verificatie van agentidentiteit ondersteunen. Zie ModelContext Protocol en MCP-serververificatie voor meer informatie.
• Agent-naar-agent (A2A):schakel beveiligde communicatie tussen agents in met behulp van agentidentiteiten. Zie Agent-to-Agent-hulpprogramma en Agent2Agent-verificatie (A2A) voor meer informatie.

Andere hulpprogramma's en integraties kunnen verschillende verificatiemethoden gebruiken (bijvoorbeeld verificatie op basis van sleutels of passthrough voor OAuth-identiteit). Gebruik de hulpprogrammadocumentatie om ondersteunde verificatie te bevestigen.

Hulpprogrammaverbindingen configureren

Als u een MCP-server of A2A-eindpunt wilt verbinden met agentidentiteitsverificatie, maakt u een projectverbinding waarmee het verificatietype en de doelgroep voor de downstreamservice worden opgegeven. Het verificatietype is afhankelijk van het hulpprogramma:

Wanneer de agent het hulpprogramma aanroept, gebruikt agentservice de agentidentiteit om een toegangstoken te verkrijgen dat is afgestemd op de doelgroepwaarde en geeft die token vervolgens door aan het eindpunt van het hulpprogramma voor verificatie.

Zie voor stapsgewijze configuratie-instructies:

• MCP-serververificatie instellen
• Agent2Agent-authenticatie (A2A)

Beveiligingsoverwegingen

Met agentidentiteiten kunt u het risico verminderen door de noodzaak om langdurige referenties in agentconfiguraties op te nemen weg te nemen. Gebruik deze procedures om toegang met minimale bevoegdheden en controlebaar te houden:

• Wijs alleen de machtigingen toe die de agent nodig heeft voor de bijbehorende hulpprogrammaacties. Geef de voorkeur aan smalle bereiken (resource of resourcegroep) boven toegang voor het hele abonnement.
• Behandel de gedeelde projectidentiteit als een bredere invloedssfeer. Als een agent strengere besturingselementen of afzonderlijke controle nodig heeft, publiceert u deze zodat deze een afzonderlijke identiteit krijgt en wijst u rollen toe aan die nieuwe identiteit.
• Controleer en log toegang tot niet-Microsoft hulpprogramma's en servers. Als een aanroep van een hulpprogramma Microsoft-services verlaat, zijn uw gegevensverwerking en -retentie afhankelijk van de externe provider.

Beperkingen

• Alleen sommige hulpprogramma's ondersteunen momenteel verificatie van agentidentiteit. Raadpleeg de documentatie van het hulpprogramma voor ondersteunde verificatie.
• Het publiceren van een agent wijzigt welke identiteit wordt gebruikt voor hulpprogrammaaanroepen (gedeelde projectidentiteit versus afzonderlijke agentidentiteit). Plan voor het herverdelen van rollen bij publicatie.

Veelvoorkomende problemen

Deze problemen veroorzaken meestal verificatiefouten bij het gebruik van agentidentiteiten:

• Rollen die zijn toegewezen aan de verkeerde identiteit: bevestig dat u machtigingen hebt verleend voor de huidige identiteit die door de agent wordt gebruikt (gedeelde projectidentiteit voor niet-gepubliceerde agents, afzonderlijke identiteit voor gepubliceerde agents).
• Ontbrekende roltoewijzingen: Zorg ervoor dat de agentidentiteit de vereiste RBAC-rol heeft voor de doelresource. Zie Azure op rollen gebaseerd toegangsbeheer in Foundry voor Foundry-rollen en -bereiken.
• Incorrect audience: Zorg ervoor dat de doelgroep overeenkomt met de downstreamservice die u aanroept (bijvoorbeeld https://storage.azure.com voor Azure Storage).

Raadpleeg de documentatie voor hulpprogramma's voor specifieke probleemoplossing:

• Modelcontextprotocol
• Agent-naar-agent-hulpprogramma

Agentidentiteiten beheren

Agentidentiteiten blijven behouden zolang het bijbehorende Foundry-project of de agenttoepassingsresource bestaat. Wanneer u een Foundry-project verwijdert, worden de bijbehorende blauwdruk voor de agentidentiteit en de gedeelde agentidentiteit verwijderd. Gepubliceerde agenten hebben hun eigen identiteitslevenscyclus die is gekoppeld aan de agentapplicatieresource. Als u de agentapplicatie verwijdert, verdwijnt de afzonderlijke identiteit.

U kunt alle agentidentiteiten in uw tenant bekijken en beheren via de Microsoft Entra-beheercentrum. Meld u aan bij de Microsoft Entra-beheercentrum en blader naar Entra ID>Agent ID>Alle agentidentiteiten om een inventaris van alle agents in uw tenant te bekijken, inclusief Foundry-agenten, Microsoft Copilot Studio agenten en anderen.

In deze ervaring kunt u ingebouwde beveiligingsmaatregelen inschakelen, waaronder:

• Voorwaardelijke toegang: toegangsbeleid toepassen op agentidentiteiten.
• Identiteitsbeveiliging: bewaak en beveilig agentidentiteiten tegen bedreigingen.
• Netwerktoegang: netwerktoegang beheren voor agents.
• Governance: Beheer vervaldatum, eigenaren en sponsors voor agentidentiteiten.

Zie Microsoft Entra documentatie voor meer informatie over Microsoft Entra Agent-ID functies.

Verwante inhoud

• Agent-toepassingen in Microsoft Foundry
• Azure op rollen gebaseerd toegangsbeheer in Foundry
• MCP-serververificatie
• Agent2Agent-authenticatie (A2A)
• Microsoft Entra Agent-ID documentatie