Het probleem: agents arriveren sneller dan agent-aware IAM

Enterprise IAM is gebouwd voor mensen en service accounts. Agents zijn geen van beide: ze handelen namens een gebruiker, verspreid over meerdere tools, vaak in ketens. Als je identity provider geen agent-identiteitsfunctionaliteit heeft — of als je er simpelweg nog niet van afhankelijk wilt zijn — blijf je zitten met de drie slechte opties waarmee elke agent-implementatie begint: het token van de gebruiker lenen, een service account delen of impersonatie toepassen. Alle drie verstoren ze het auditspoor, zoals we bespreken in wat AI agent-identiteit is.

Met het identity-broker-patroon hoef je niet te wachten. Één vertrouwde component wordt de uitgever en autoriteit voor agent-identiteit, zodat je vandaag nog beheerde agents krijgt en de optie behoudt om later te federeren met je IdP.

Wat de broker daadwerkelijk doet

Een broker neemt drie rollen op zich die anders verdeeld zouden zijn over je IdP, je applicatiecode en elke afzonderlijke tool. Met TrueFoundry als broker ziet de verdeling er als volgt uit:

Hoe een aanroep verloopt

Registratie maakt de identiteit van de agent aan. De agent haalt zijn token op uit de registry (via ⋮ → Get Token) och stuurt dit mee met het token van de gebruiker bij elke aanroep:

De gateway valideert beide tokens, controleert of de agent de doel-MCP-server mag bereiken en of deze namens de gebruiker mag handelen, en stuurt het verzoek vervolgens door met de uitgaande authenticatie van het doel. Alles wat niet is toegewezen, wordt geweigerd met een 403. Omdat TrueFoundry beide credentials ondertekent en valideert, is de gateway het centrale trust domain — er hoeft geen externe uitwisseling te worden opgezet.

Derde doelen bereiken

De broker lost ook de uitgaande credentials op, wat het punt is waar de meeste agent-integraties daadwerkelijk vastlopen. Het biedt drie uitgaande modi, afhankelijk van wat het doel ondersteunt:

Één belangrijke kanttekening vooraf: een agent die handelt zonder gebruiker kan geen authorization-code flow voltooien, omdat er geen mens is om het toestemmingsscherm te goedkeuren. Gebruik voor onbeheerde agents een modus die geen toestemming per gebruiker vereist. Het uitgaande tokenmodel is het model dat we gedetailleerd beschrijven in OAuth en enterprise tokenbeheer voor MCP.

Waar teams de mist in gaan

Denken dat de broker alles-of-niets is. De andere scenario's (Okta, Entra, SPIFFE) veranderen alleen waar de identiteit van de agent vandaan komt. Je kunt scenario's per agent combineren binnen één tenant, en de controles van de gateway blijven identiek.

Een onbeheerde agent gebruiken met een authorization-code doel. Geen mens betekent geen toestemmingsscherm. Kies client-credentials of een beheerde credential voor agents die zelfstandig draaien.

Het bereiken van een doel verwarren met handelen namens een gebruiker. Dit zijn gescheiden toewijzingen. Een agent die een collaborator op een server is, heeft nog steeds toestemming nodig om te handelen namens de specifieke gebruiker die hij beweert te vertegenwoordigen — zie fijnmazige autorisatie.

Het migratieplan overslaan. De broker is de snelle route, maar als het beleid uiteindelijk vereist dat alle entiteiten in de corporate directory staan, registreer agents dan op een manier die een latere overstap naar Entra of Okta een configuratiewijziging maakt in plaats van een herontwerp.

Wil je beheerde agents zonder te wachten op een IdP-migratie?

Start gratis op TrueFoundry

Wanneer kies je voor de broker — en wanneer niet

Kies het broker-scenario wanneer je agents intern zijn ontwikkeld en hun doelen intern zijn of bereikbaar met door de gateway beheerde credentials; wanneer je beheer snel operationeel wilt hebben; of wanneer je IdP geen ondersteuning voor agents heeft. Geef de voorkeur aan een door IdP ondersteund scenario wanneer het beveiligingsbeleid vereist dat elke entiteit in de corporate directory staat, wanneer je IdP-gefaciliteerde toegang tot SaaS van derden nodig hebt (bijvoorbeeld Okta Cross App Access, behandeld in TrueFoundry en Okta Cross App Access), of wanneer agents al Entra- of Okta-identiteiten hebben waarvan andere systemen afhankelijk zijn.

Een uitgewerkt voorbeeld

Een team wil een research-agent inzetten om Jira te lezen namens gebruikers, maar hun IdP heeft geen agent-product ingeschakeld. Ze registreren de agent in TrueFoundry (broker-scenario), verlenen het research-team Agent Access zodat de agent namens hen mag handelen, en voegen de agent toe als collaborator op de Jira MCP-server met een door de gateway beheerde credential. De agent haalt zijn token op, stuurt dit mee met het token van elke gebruiker, en de gateway autoriseert het paar en stuur de aanroep door. Maanden later, wanneer de organisatie standaardiseert op Entra Agent ID, zetten ze die ene agent om naar identity-provider-backed — de collaborator-toewijzingen en het auditspoor blijven ongewijzigd behouden.

Belangrijke aandachtspunten

• STS-uitgifte per hop staat gemarkeerd als binnenkort beschikbaar. Het geplande model geeft bij elke hop een kortstondig, door TrueFoundry ondertekend token uit met de gebruiker als sub en handelende agents in act, waardoor de doelgroep en scope worden beperkt tot de volgende aangeroepene.
• Houd het agent-token buiten de voor het model leesbare context. Een gepromptte agent die zijn token kan onthullen, kan worden geïmpersoneerd.
• Geweigerde aanroepen retourneren `403`, met vermelding van de geweigerde entiteit en reden — nuttig wanneer een toewijzing ontbreekt op een van de twee assen.
• OAuth per gebruiker betekent dat de gateway tokens opslaat en vernieuwt; houd rekening met die status en de versleuteling ervan.
• Één tenant kan scenario's combineren. Je hoeft niet te kiezen voor uitsluitend broker of IdP voor de gehele omgeving — beslis per agent.

Het geplande STS-model en waarom het belangrijk is

Momenteel ondertekent de broker één agent-token per geregistreerde agent en controleert dit bij elke aanroep. Het onderdeel dat in de documentatie gemarkeerd staat als binnenkort beschikbaar is dat de gateway fungeert als een volledige security token service (STS) die bij elke hop van een keten een vers, kortstondig token uitgeeft. In dat model blijft de gebruiker de sub, wordt elke handelende agent vastgelegd in een geneste act-claim, en worden de doelgroep en scope beperkt tot de volgende aangeroepene — zo kan een token dat is uitgegeven voor de research-agent om Jira aan te roepen, niet opnieuw worden gebruikt tegen Confluence. Het voordeel voor een stroomafwaartse MCP-server is eenvoud: deze valideert één enkele uitgever (de gateway) in plaats van elke agent en IdP in je omgeving te moeten vertrouwen. Als je nu multi-agent-ketens ontwerpt, bouw dan tegen het twee-header-model en beschouw STS per hop als een naadloze hardening die je doorvoert zodra deze beschikbaar is, niet als een herontwerp.

Een scenario kiezen

De broker is een van de vier identiteitsscenario's, en het enige dat daartussen verandert is waar de identiteit van de agent vandaan komt. De autorisatiecontroles van de gateway, collaborator-toewijzingen en audit zijn identiek, wat het mogelijk maakt om ze per agent te combineren binnen één tenant.

Het praktische patroon waar de meeste teams op uitkomen: start elke agent op de broker om snel beheer te realiseren, en migreer vervolgens het handjevol agents dat vanwege beleid of integraties vereist is naar een door IdP ondersteund scenario. Omdat de toewijzingen en audit behouden blijven, is die migratie een configuratiewijziging op één agent, geen heel project. De door IdP ondersteunde opties worden behandeld in TrueFoundry en Okta Cross App Access en de Entra- en SPIFFE-gidsen.

Uitgaande auth, bepaald per doel

De inkomende zijde (wie de agent is, namens wie deze handelt) is uniform; de uitgaande zijde (hoe de gateway authenticeert bij de tool) wordt gekozen per doel, en het verkeerd aanpakken hiervan is de meest voorkomende reden waarom een anderszins beheerde agent een systeem niet daadwerkelijk kan bereiken. Een snelle beslissingsgids: als het doel een interne MCP-server is die de gateway vertrouwt, gebruik dan geen auth of een beheerde header credential; als het een SaaS API is die app-to-app toegang ondersteunt, gebruik dan OAuth2 client credentials die centraal door de gateway worden beheerd; als het een SaaS API is die toestemming per gebruiker vereist, gebruik dan de OAuth2 authorization-code flow, waarbij de gateway OAuth per gebruiker uitvoert en het token van elke gebruiker opslaat en vernieuwt. De ene harde beperking: een onbeheerde agent — een agent die handelt zonder gebruiker — kan geen authorization-code flow voltooien, omdat er geen mens is om het toestemmingsscherm goed te keuren. Geef dergelijke agents in plaats daarvan een doel met client-credentials of beheerde credentials, en plan versleutelde opslag voor de per-gebruiker-tokens die de gateway beheert, zoals behandeld in OAuth en enterprise tokenbeheer voor MCP.

Gerelateerde artikelen

• Agent Identity and On-Behalf-Of Delegation — het twee-header-model in detail
• What Is AI Agent Identity? — het concept dat de broker levert
• TrueFoundry and Okta Cross App Access — het door IdP ondersteunde alternatief
• OAuth and Enterprise Token Management for MCP — uitgaande credentials naar tools van derden
• What Is MCP Authorization? — de toewijzingen achter elke aanroep

Conclusie

Het identity-broker-patroon bestaat omdat agents sneller arriveren dan agent-aware IAM. In plaats van te wachten, laat je één vertrouwde component de agent-identiteit uitgeven, elke aanroep autoriseren en credentials naar elk doel brokeren — zonder dat je menselijke IdP wordt aangeraakt. TrueFoundry vervult die broker-rol: het ondertekent en valideert zowel de gebruiker- als agent-tokens, beheert de aanroep vanuit toewijzingen op één centrale plek, en houdt de deur open om te federeren met Entra, Okta of SPIFFE wanneer je er klaar voor bent.

Het is de kortste weg van ongestuurde agents naar beheerde agents — zonder de gehele infrastructuur in te zetten op één enkele identiteitsleverancier.

Beheer de identiteit van je agents op één centrale plek.

Boek een demo