Uw AI-agent heeft een identiteitsprobleem (en dit is de template die het oplost)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

In elk AI-agentproject is er een moment dat ongeveer zo verloopt: de demo werkt perfect, de agent interpreteert natuurlijke taal, roept de juiste API’s aan, geeft de juiste gegevens terug. Dan begint u aan echte gebruikers te denken.

Wat verhindert dat de agentsessie van één gebruiker de gegevens van een andere gebruiker ziet? Wat als de agent wordt misleid via promptinjectie? Wat als hij een tool op een onverwachte manier aanroept?

Dit zijn geen randgevallen. Dit zijn ontwerpbeslissingen die u vóór de release moet nemen.

Een nieuwe azd-template van Curity en Microsoft geeft u een werkende referentie voor precies dit probleem.

Het kernprobleem: Authenticatie ≠ Autorisatie

De meeste agentsamples gaan goed om met gebruikersauthenticatie. Ze gaan slecht om met autorisatie. Weten wie de gebruiker is, vertelt u niet welke gegevens ze zouden moeten zien.

Een traditionele clientapp maakt voorspelbare API-aanroepen. Een AI-agent is niet-deterministisch — hij interpreteert natuurlijke taal en beslist wat hij aanroept. Hij kan creatief zijn. Hij kan ook ongelijk hebben. En als hij via promptinjectie wordt gemanipuleerd, hebt u regels nodig die niet afhankelijk zijn van goed gedrag van de AI.

De oplossing die deze template demonstreert: kortlevende tokens die precies de juiste informatie bij elke hop dragen.

Hoe de tokenketen werkt

De template gebruikt OAuth 2.0-toegangstokens met tokenuitwisseling om machtigingen bij elke stap te beperken. Het gebruikerstoken wordt twee keer uitgewisseld voordat het de MCP-server bereikt:

Eerste uitwisseling — versmalt de scope en converteert het ondoorzichtige token naar een JWT
Tweede uitwisseling — voegt agentidentiteit en een nieuw publiek toe voor de MCP-server hop

Hoe het MCP-servertoken eruit ziet:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

customer_id wordt door de autorisatieserver in het token ingebed, niet doorgegeven als een parameter die de agent beheert. De API controleert het token, niet de instructies van de agent.

Dat betekent: zelfs als iemand de agent misleidt om gegevens van een andere klant op te halen, zal het token dat niet autoriseren.

Wat de template implementeert

Met een paar azd-commando’s krijgt u:

Een backend-agent op Microsoft Foundry (C#, Microsoft A2A- en MCP-SDK’s)
Een MCP-server die een voorbeeld portfolio-API blootstelt
Curity Identity Server als autorisatieserver, samen met Entra ID voor authenticatie
Externe en interne API-gateways die tokenuitwisseling en auditlogging afhandelen
Bicep voor alle Azure-infrastructuur: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, opslag

Het volledige patroon is inspecteerbaar en aanpasbaar.

Het ontwerpprincipe dat het waard is te lenen

Zelfs als u Curity niet gebruikt, is het patroon overdraagbaar: agents mogen nooit permanente API-toegang hebben. Elke actie zou een kortlevend token moeten gebruiken met de minimale scope die nodig is voor die specifieke aanroep, uitgegeven voor de specifieke agentidentiteit, met de claims die de API nodig heeft om autorisatiebeslissingen te nemen.

Dit bestand het tegen creatieve agents, fouten en promptinjectie op manieren die “zorg er gewoon voor dat de agent geen slechte dingen doet” nooit zal.

Conclusie

Beveiligingspatronen voor AI-agents worden nog steeds in de gehele industrie uitgewerkt. Deze template is een van de meest complete referentie-implementaties die ik heb gezien — het behandelt de daadwerkelijke autorisatiestroom, niet alleen authenticatie.