Maak kennis met Agent Identity: Verifieerbare identiteit voor elke AI Agent

We brengen drie grote productupdates uit om agent governance op TrueFoundry te versterken. Zo krijgen teams controle over welke agents draaien, wat ze kunnen bereiken en namens wie ze handelen.

Agent Identity is de eerste grote lancering in deze reeks.

In een ziekenhuis draagt elke arts en verpleegkundige een ID-badge. Ze scannen deze bij de medicijnkast voordat ze een medicijn kunnen verstrekken, en de kast legt vast wie wat heeft gepakt, voor welke patiënt en wanneer. Stel je nu een drukke afdeling voor waar een paar mensen één badge delen om tijd te besparen. Het logboek vermeldt nog steeds "Dr. Smith heeft 10 mg morfine verstrekt om 02:14 uur", maar niemand kan zeggen wie de lade werkelijk heeft geopend. De registratie van de laatst gebruikte inloggegevens bestaat, maar daarbuiten is er geen traceerbaarheid.  

Dat is hoe de meeste AI-agents vandaag de dag werken. Agents roepen modellen, MCP-servers en andere agents aan met behulp van gedeelde API-sleutels, statische service-accounts of welke inloggegevens de ontwikkelaar maar bij de hand had. Wanneer een agent een terugbetaling verwerkt of een klantenbestand bijwerkt, tonen de logs een sleutel, geen agent, en ook niet de persoon namens wie de agent handelde. Dit was een klein ongemak toen agents op kleine schaal opereerden, voornamelijk op interne workflows. Maar naarmate de omvang van de agent-vloot van elke onderneming groeit en teams multi-agent systemen gaan inzetten die gevoelige gegevens kunnen raadplegen en ingrijpende acties kunnen uitvoeren, wordt het gebrek aan traceerbaarheid een enorm risico voor compliance en beveiliging. 

DáÁRном lanceren we Agent Identity in TrueFoundry's Agent Gateway. 

Waarom we Agent Identity hebben gebouwd

We hoorden steeds hetzelfde verhaal van platform- en securityteams. Neem een ondersteuningsportal: een support engineer vraagt, handelend voor een klant, het portal om een betaling te verwerken. Het portal roept een support orchestrator agent aan. De orchestrator draagt de taak over aan een payments agent. De payments agent roept een payments MCP server aan die het record daadwerkelijk wegschrijft.

Vier stappen later moet de MCP-server beslissen of deze actie moet worden uitgevoerd. Komt dit verzoek van het portal? Van de engineer? Van de klant die de engineer helpt? In de meeste opstellingen ziet de server alleen de laatste agent in de keten, waardoor deze óf alles vertrouwt, óf niets vertrouwt.

Teams die dit probeerden op te lossen, liepen tegen drie problemen aan:

• Geen identiteit per agent. Gedeelde sleutels maken het onmogelijk om agents van elkaar te onderscheiden of de toegang van één agent in te trekken zonder andere te verstoren.
• Gebruikerscontext gaat verloren tussen stappen. Elke agent herbepaalt de authenticatie als zichzelf, waardoor de persoon achter het verzoek verdwijnt.
• Authenticatie wordt in elke agent opnieuw gebouwd. De logica voor token-uitwisseling, vernieuwing en ondertekening wordt in elke codebase gekopieerd, elke keer net even anders.

Agent Identity verplaatst al deze logica uit de agent-code en naar de gateway.

Geef elke agent een verifieerbare identiteit, waar deze ook draait

Elke agent die is geregistreerd in TrueFoundry's AI agent registry krijgt precies één identiteit. Je kiest zelf wie deze ondersteunt:

• Ondersteund door TrueFoundry: TrueFoundry geeft de token van de agent uit en ondertekent deze. Dit is de eenvoudigste en snelste manier om te starten, omdat er geen aanvullende configuratie nodig is.
• Ondersteund door een identity provider: De agent gebruikt tokens van de identity provider die je al gebruikt, zoals Okta, Microsoft Entra, elke willekeurige OIDC-provider, of SPIFFE/SPIRE. TrueFoundry koppelt de agent aan een subject claim in de token, zodat je IdP de bron van de waarheid blijft.

Agents hoeven niet te worden verplaatst om een identiteit te krijgen. Je kunt agents die draaien op AWS Bedrock AgentCore, Vertex AI, LangGraph, aangepaste HTTP-services, A2A-agents of TrueForge registreren zonder ze te herschrijven. Agents die je via de gateway routeert, krijgen volledige beleidshandhaving op inkomende aanroepen. Embedded agents die niet via een proxy kunnen lopen, krijgen nog steeds een identiteit, en hun uitgaande aanroepen naar modellen en MCP-servers blijven onderworpen aan governance.

Beheer hoe identiteit door elke stap stroomt

Authenticatie beantwoordt de vraag "wie ben je?". In een multi-agent keten is de moeilijkere vraag echter "namens wie handel je?". Met Agent Identity kun je voor elke stap bepalen hoe de identiteit wordt gepresenteerd aan het volgende systeem:

• Token pass-through: De gateway stuurt de token van de aanroeper ongewijzigd door. Dit kan worden gebruikt wanneer het downstream-systeem de oorspronkelijke token al vertrouwt.
• OAuth2 client credentials: De agent roept downstream-systemen aan als zichzelf, ongeacht wie de agent heeft aangeroepen. Dit werkt als een gedeeld service-account, maar dan afgebakend tot één geregistreerde agent.
• On-behalf-of (OBO) token exchange: De gateway wisselt de token van de aanroeper bij je IdP om voor een nieuwe token die beide identiteiten bevat: deze agent, handelend voor deze gebruiker. We ondersteunen Microsoft Entra (JWT bearer) en Okta (RFC 8693 token exchange).
• AWS SigV4: De gateway ondertekent verzoeken met AWS-inloggegevens voor agents die in AWS draaien.

Hoe werkt dit in de praktijk? Laten we teruggaan naar het scenario met de support-agent van eerder. Je kunt de token rechtstreeks trochgeven tussen de orchestrator en de payments agent, en vervolgens on-behalf-of gebruiken bij de uiteindelijke aanroep naar de payments MCP. De MCP-server ziet nu dat de payments agent handelt namens de support engineer, en kan de rechten van die persoon toepassen. In de praktijk bepaalt het achterliggende registratiesysteem aan het einde van de keten meestal welke identiteit het nodig heeft, en met Agent Identity kun je aan die eis voldoen zonder de agent-code aan te raken. De gateway voert de uitwisseling uit, spacert en vernieuwt tokens, en weigert aanroepen die niet de identiteit dragen die de volgende stap vereist.

Beheer wie elke agent kan aanroepen en wat de agent zelf kan aanroepen

Identiteit is alleen nuttig als je er actie op kunt ondernemen. Elke agent heeft twee sets beheersmaatregelen:

• Wie deze agent kan aanroepen: Een allow-list van gebruikers, teams, apps en andere agents met toegang om de agent aan te roepen.
• Wat deze agent kan aanroepen: Rechten op de modellen, MCP-servers en andere agents die de agent mag bereiken.

Agents kunnen een eigenaar-team hebben en medewerkers met de rollen Agent Manager of Agent Access. Toegang is gebaseerd op een allow-list: verwijder een toewijzing, en de gateway geeft bij de volgende aanroep een 403-foutmelding terug. Deze policies maken gebruik van hetzelfde RBAC-model als elke andere TrueFoundry-resource, dus er is geen afzonderlijk rechtensysteem om te leren.

Aan de slag met Agent Identity

Het registreren van een agent omvat vier stappen in de Agent Registry: Metadata, Agent Identity, Config, en Access Control. Je kunt dezelfde configuratie ook toepassen als YAML. Ga naar de Agent Registry documentatie voor een volledige handleiding, inclusief instellingsgidsen voor Okta en Microsoft Entra.

Wil je meer weten over hoe Agent Identity in de TrueFoundry AI Gateway zou werken binnen jouw huidige omgeving?

Plan nu je demo in →