Agent Identity en On-Behalf-Of (OBO) Delegation: Wie Roept Je Tools Echt Aan?

Waarom een agent zijn eigen identiteit nodig heeft

Geef een autonome agent toegang tot je tools en je staat direct voor een vraag waar je IAM nooit voor is ontworpen: wanneer de agent een Zendesk-ticket leest of een query uitvoert op een database, wie heeft dat dan gedaan? Er zijn drie gebruikelijke antwoorden, en alle drie zijn ze fout.

• Het gebruikt het token van de gebruiker. Het downstream systeem kan helemaal niet zien dat er een agent bij betrokken was — elke actie ziet eruit alsof de mens het rechtstreeks heeft gedaan.
• Het gebruikt een gedeeld service account. Nu kun je niet meer zien van welke gebruiker de data is aangeraakt; de verzoeken van dertig mensen vallen samen in één principal.
• Het doet zich voor als de gebruiker (impersonation). De rol van de agent in de beslissing is verborgen, wat precies het eerste is waar een auditor naar zal vragen.

In elk geval is de audit trail onvolledig, is de autorisatie grofmazig, en kan beleid een menselijke actie niet onderscheiden van een autonome. Agent identity lost dit op door van de agent een eersteklas principal te maken — een die als zichzelf kan handelen of namens een gebruiker. Voor het bredere beeld, zie wat AI agent identity is en AI agent governance.

Wat “on behalf of” daadwerkelijk betekent

On-behalf-of delegatie is een token dat twee subjects bevat. Gebouwd op het RFC 8693 token-exchange patroon, stelt het resulterende token sub in op de gebruiker en act op de agent — “deze gebruiker, zoals vertegenwoordigd door deze agent.” De permissies op dat token (scp) zijn de doorsnede van wat de gebruiker mag doen en wat de agent mag doen, dus een agent kan het bereik van een gebruiker nooit verruimen.

Voor een keten van agenten nesten de act claims: een data-agent die handelt voor een research-agent die handelt voor een gebruiker. Elke hop wordt geregistreerd, zodat het volledige delegatiepad zichtbaar is in het auditlogboek in plaats van te worden platgeslagen tot één actor.

De twee headers op elk verzoek

In TrueFoundry wordt de identiteit van een agent aangemaakt wanneer je deze registreert — elke geregistreerde agent heeft exact één identiteit, en deze kan TrueFoundry-backed zijn (de Gateway geeft het token uit en ondertekent het) of identity-provider-backed door Okta of Microsoft Entra. De identiteit betekent in beide gevallen hetzelfde; alleen de uitgever verschilt.

Elk verzoek naar de Gateway bevat vervolgens twee bearer tokens:

De Authorization header is het SSO-token van de gebruiker en wordt van begin tot eind ongewijzigd doorgegeven. De x-tfy-agent-authorization header is de agent die op dit moment handelt, en elke agent vervangt deze door zijn eigen identiteit voordat de volgende hop wordt aangeroepen. Als de agent-header ontbreekt, is het verzoek gewoon een normale gebruikersaanroep, geautoriseerd op alleen de permissies van de gebruiker. Hetzelfde header-paar werkt over alle drie de oppervlakken — de LLM Gateway (/api/llm/chat/completions), de MCP Gateway (/mcp/<server>/server) en de Agent Gateway (/agent/<agent-name>).

Wie voor wie kan handelen: collaborators

Delegatie is niet vrijblijvend. Het wordt begrensd door de collaborators in de Access Control-stap van de agent, die twee rollen hebben:

• Agent Manager — kan de agent en zijn configuratie bewerken.
• Agent Access — kan de agent aanroepen en er kan voor hem gehandeld worden door de agent. Een gebruiker zonder deze toewijzing kan niet het subject zijn van een gedelegeerde aanroep, zelfs als hij het doel zelf rechtstreeks zou kunnen bereiken.

Collaborators kunnen een gebruiker, een team of een virtual account zijn — dus niet-menselijke workloads kunnen ook delegeren. Dit is de drempel die voorkomt dat een agent stilzwijgend handelt voor iedereen in de organisatie: delegatie werkt alleen voor identiteiten die dit expliciet hebben verleend.

Het bereiken van het doel is een afzonderlijke machtiging

Mogen handelen voor een gebruiker is één permissie. Het mogen bereiken van een specifieke tool is een andere — en beide moeten gelden. Op de collaborators-lijst van een MCP-server verschijnen agenten naast gebruikers en teams, met hun eigen rollen: MCP Server User (tools aanroepen) en MCP Server Manager (beheren).

In een YAML-manifest gebruiken dezelfde toewijzingen subject-prefixes, zodat de intentie expliciet is:

Het scheiden van de twee machtigingen is wat least-privilege werkelijkheid maakt: een agent waar je gebruiker via kan handelen, kan nog steeds geen tool aanraken waar hij nooit aan is toegevoegd. Het weerspiegelt het autorisatiemodel dat we behandelen in wat MCP autorisatie is en fine-grained autorisatie.

Wil je precies zien wie — en welke agent — elke tool heeft aangeroepen?

TrueFoundry Gateway

Hoe een multi-hop aanroep wordt geautoriseerd

De duidelijkste manier om het model te begrijpen is door één verzoek te volgen. Jane vraagt een planner-agent, die delegeert naar een research-agent, die een Zendesk MCP-server aanroept. Het gebruikerstoken verandert nooit; het agenttoken wel, en de Gateway controleert elke hop op zijn eigen machtigingen.

Elke agent is alleen geautoriseerd op zijn eigen machtigingen — hij erft nooit het bereik van zijn aanroeper. De uitgaande kant is ongewijzigd: de bestaande auth van de MCP-server (OAuth2, een gedeelde API-sleutel, of token passthrough) blijft werken zonder herconfiguratie. Het enige dat de Gateway toevoegt, is het oplossen van het (gebruiker, agent)-paar en het autoriseren daarvan.

Waar teams de mist in gaan

• Een gedeeld service account behandelen als “agent identity.” Een service account vertegenwoordigt de agent als zichzelf, maar kan voor niemand handelen — dus kun je nog steeds niet beantwoorden wiens data is aangeraakt. Delegatie is juist het hele punt.
• Aannemen dat het bereiken van een tool permissie impliceert om te handelen voor een gebruiker. Het zijn gescheiden machtigingen. Een agent die een collaborator op een server is, heeft nog steeds een Agent Access machtiging nodig voor de specifieke gebruiker voor wie hij claimt te handelen.
• Het model zijn eigen identiteitstoken laten lezen. Een geprompte agent die zijn x-tfy-agent-authorization token kan onthullen, kan worden geïmpersoneerd. Houd het buiten versiebeheer en buiten alles wat het model kan lezen.
• De keten platmaken. Als een multi-agent systeem instort tot één service account, gaan de geneste act claims verloren en kan je auditlogboek niet meer reconstrueren wie wat heeft gedaan. Bewaar de delegatieketen hop voor hop.

Een uitgewerkt voorbeeld

Een support-automatiseringsteam draait een planner-agent die taken verdeelt over gespecialiseerde agenten, waarvan er één tickets leest uit Zendesk. Ze willen drie dingen: de menselijke aanvrager bij elke actie, de specifieke agent die heeft gehandeld, en geen enkele agent die een tool kan bereiken waar hij niet expliciet toegang toe heeft gekregen.

1. Registreer elke agent zodat deze zijn eigen identiteit krijgt — hier TrueFoundry-backed, aangezien ze de agenten zelf bouwen en draaien.
2. Voeg op de Access Control van elke agent het supportteam toe als Agent Access, zodat de agenten voor die gebruikers mogen handelen.
3. Voeg op de Zendesk MCP-server alleen de ticket-lezende agent toe als MCP Server User — de planner raakt Zendesk nooit rechtstreeks aan.
4. Verstuur verzoeken met het gebruikerstoken in Authorization en het agenttoken in x-tfy-agent-authorization; laat elke agent zijn eigen token invoegen.
5. Lees het auditlogboek: elke Zendesk-leesactie toont de aanvrager, de handelende agent en de volledige delegatieketen.

De eerlijke grens: dit regelt wie voor wie mag handelen en wat mag bereiken. Het vervangt niet de eigen uitgaande credentials van de MCP-server — die blijven waar ze zijn, wat precies is waarom adoptie geen herinrichting van je tools vereist.

Belangrijke aandachtspunten

• Agent identity is in Beta — gedrag en configuratie kunnen nog veranderen, dus houd vast aan de gedocumenteerde flow en controleer deze opnieuw voor een brede uitrol.
• Identity-provider-backed agenten moeten ook in de IdP worden geregistreerd (Okta of Entra); TrueFoundry-backed agenten hebben geen externe registratie nodig.
• Geweigerde aanroepen retourneren 403, met vermelding van de geweigerde principal en reden — een gebruiker die een Agent Access machtiging mist, wordt geweigerd voor gedelegeerde aanroepen, zelfs wanneer hij het doel rechtstreeks zou kunnen bereiken.
• De permissies op een OBO-token zijn de doorsnede van gebruiker- en agent-scopes, dus het aanscherpen van een van beide kanten scherpt de gedelegeerde aanroep aan. Een forbid-beleid heeft voorrang op een permit.
• Delegatie en bereikbaarheid zijn onafhankelijk — audit beide machtigingen, niet slechts één, wanneer iets onverwacht wordt geweigerd (of onverwacht wordt toegestaan).

De drie manieren waarop een agent zijn OBO-token krijgt

Onder het twee-header model heeft de vraag wie de token exchange uitvoert drie antwoorden, bepaald door het identiteitstype van de agent. Ze maken een afweging tussen gemak en waar het vertrouwen en de geheimen zich bevinden.

Bij managed credentials is de OAuth-client van de agent geregistreerd in de IdP en slaat TrueFoundry de credentials op als secrets, voert vervolgens de exchange uit met het token van de gebruiker als subject token, en mecatched en ververst het resultaat. Bij federated token doet de agent de exchange buiten TrueFoundry en verstuurt het voltooide OBO-token, dat de gateway valideert met jwks_uri, issuer, audience en een agent_claim (standaard act.sub) voordat het wordt gekoppeld aan het register — een mislukte match retourneert 403. Bij virtual account verstuurt de aanroeper twee tokens, Authorization: Bearer <virtual-account-token> en X-TFY-User-Token: <user-sso-token>, en wordt de gebruikerscontext gedragen door TrueFoundry's eigen uitgaande auth in plaats van een door de IdP uitgegeven OBO-token; servers die specifiek standaard RFC 8693-tokens vereisen, moeten een van de andere twee modi gebruiken.

Hoe de gateway het paar autoriseert

Het vaststellen van de (gebruiker, agent) identiteit is stap één, niet het hele verhaal. Zodra het paar bekend is, voert het verzoek een korte evaluatie uit voordat iets de tool bereikt, en elke laag kan de toegang alleen maar verkleinen:

1. Stel de (gebruiker, agent) identiteit vast uit de twee headers.
2. RBAC — gebruiker: de gebruiker moet een collaborator zijn op de MCP-server.
3. RBAC — agent: de agent moet ook een collaborator zijn (zijn subject is agent:<agent-name>).
4. Tool scope: de opgevraagde tool moet in de optionele tools-lijst van de agent staan, als deze is ingesteld.
5. Beleid: optionele Cedar-policies worden uitgevoerd, waarbij een forbid altijd voorrang heeft op een permit.
6. Stuur door naar de MCP-server met zijn eigen uitgaande auth.

Dit is waarom delegatie van nature veilig is: de eigen scope van het OBO-token is al de doorsnede van gebruiker- en agent-permissies, en vervolgens moeten vier onafhankelijke machtigingen het elk eens zijn voordat de aanroep wordt doorgezet. Het verstrengen van een van deze — het verwijderen van de collaborator-rol van de gebruiker, het verwijderen van de agent, het inkorten van de tool-lijst of het toevoegen van een Cedar forbid — scherpt de gedelegeerde aanroep aan. De volledige auditregel registreert de gebruiker, de agent, de identiteitsmodus, de delegatieketen, de server en tool, de RBAC- en Cedar-beslissingen, de gebruikte scopes en de status.

Gerelateerde artikelen

• What Is AI Agent Identity? — het concept waar dit op voortbouwt
• AI Agent Governance: Five Pillars You Build, Not Write — waar identiteit zich bevindt in de stack
• MCP Authentication, Explained — inkomende identiteit en uitgaande credentials
• What Is MCP Authorization? — het autorisatiemodel achter de machtigingen
• TrueFoundry Joins Okta’s Cross App Access Ecosystem — identiteit-gestuurde agenttoegang met je bestaande IdP
• Agent Gateway vs LLM Gateway — waarom het multi-hop pad zijn eigen controlepunt nodig heeft

Conclusie

Een agent die het token van een gebruiker leent of zich verschuilt achter een service account is een risico dat wacht om ontdekt te worden — door een auditor, of door een aanvaller. Agent identity lost dit op door van de agent een zelfstandige principal te maken, en on-behalf-of delegatie laat die principal handelen voor een specifieke gebruiker terwijl beide identiteiten hop na hop worden meegenomen.

Het mechanisme is bewust compact gehouden: twee headers, twee soorten machtigingen en een autorisatiecontrole bij de gateway. Het gebruikerstoken blijft constant, de handelende agent verandert, en elke tool-aanroep beantwoordt beide vragen tegelijk — welke gebruiker, en welke agent. Dat is wat een autonoom systeem auditeerbaar maakt in plaats van louter functioneel.

Geef elke agent een identiteit en zie wie echt elke tool heeft aangeroepen.

Boek een demo