Een Agent Identity Is Geen Autorisatiebeslissing: Gedelegeerde Autoriteit End-to-End Ontwerpen

Agent identity geeft antwoord op de vraag welke workload belt. Productie-autorisatie moet daarnaast de menselijke subject, het delegatiebereik, de resource-doelgroep, de taakintentie, de goedkeuring en de huidige bedrijfsstatus bij elke hop behouden.

Elke agent een eigen identiteit geven is noodzakelijk. Het is echter ook gemakkelijk om te overschatten wat dat oplevert.

Met identiteit kan een gateway een planner-agent onderscheiden van een finance-agent. Authenticatie levert het bewijs dat de aanroeper die identiteit beheert. Geen van beide feiten geeft antwoord op de vraag of de werknemer een specifieke actie mocht delegeren, of de agent deze tool voor deze gebruiker mag gebruiken, of het downstream token bedoeld is voor deze resource, of een mens deze argumenten heeft goedgekeurd, of dat de huidige bedrijfsstatus de transactie toestaat.

Dat zijn autorisatievragen die verspreid liggen over meerdere systemen. Door "de agent is geauthenticeerd" als antwoord te behandelen, ontstaat er een nieuwe confused deputy: een legitieme workload met een geldige credential kan worden misleid om zijn bereik in te zetten voor het verkeerde subject, doel, resource of moment.

Behoud drie principals in plaats van ze samen te voegen

Een nuttig verzoekrecord bevat daarom ten minste twee identiteiten. De mens of de initiërende dienst blijft het subject. De op dat moment uitvoerende agent is de actor. In een multi-agent-systeem kan het subject stabiel blijven terwijl de actor bij elke hop verandert. Daardoor kan het beleid zowel vragen "mag deze gebruiker de taak delegeren?" als "mag deze agent de taak uitvoeren?"

De derde principal is vaak impliciet: de eigenaar van de resource en het bijbehorende beleid. Een finance-applicatie, klantendatabase, broncode-repository of productie-control plane heeft eigen autorisatieregels. Een agent-platform kan aanroepers authenticeren en het toolbereik inperken, maar het mag geen bedrijfsautoriteit creëren die het downstream systeem niet heeft verleend.

Scheid inkomende identiteit van uitgaande autoriteit

Tool calls van een agent overschrijden ten minste twee authenticatiegrenzen. Inkomende authenticatie vertelt de gateway wie er aanroept. Uitgaande authenticatie bepaalt welke credentials de gateway of MCP-server presenteert aan de downstream dienst. Deze kunnen bewust van elkaar verschillen.

Een agent in service-modus kan inkomend authenticeren met een machine-identiteit en een gedeeld downstream service-account gebruiken. Elke gebruiker krijgt dezelfde effectieve datatoegang, tenzij de applicatie eigen controls toevoegt. Een ontwerp per gebruiker kan de mens authenticeren via een identity provider en per-gebruiker OAuth of token exchange/on-behalf-of gebruiken, zodat een downstream dienst gebruikersspecifieke rechten kan afdwingen. TrueFoundry documenteert ook token-passthrough wanneer de MCP-server zelf hetzelfde inkomende TrueFoundry- of identity provider-token valideert. De keuze is onderdeel van het beveiligingsmodel, geen technische randzaak.

Audience binding is eveneens van belang. De MCP authorization security considerations van 28 juli 2026 vereisen dat clients de doelresource identificeren en dat servers valideren dat een token daarvoor is uitgegeven. Ze maken ook onderscheid tussen het token dat aan een MCP-server wordt gepresenteerd en een afzonderlijk token dat de server kan gebruiken bij een upstream API. De specificatie verbiedt een MCP-server om het MCP-token van de client door te geven aan een upstream API. De door TrueFoundry gedocumenteerde token-passthrough-modus is strikter: de gateway stuurt het inkomende token door naar een MCP-server die is geconfigureerd om diezelfde issuer en audience te valideren. Het hergebruiken van een breed token over ongerelateerde resources verandert één datalek in lateral movement en maakt onduidelijk welke dienst de call daadwerkelijk heeft geautoriseerd.

Documenteer voor elk toolpad het inkomende subject, de agent-actor, de gateway-autorisatie, de uitgaande credential-modus, de token-audience, de downstream principal en het uiteindelijke policy decision point. Als een team die keten niet kan traceren, kan het niet betrouwbaar uitleggen wiens autoriteit een actie heeft veroorzaakt.

Snijd autoriteit bij elke agent-hop

Dit voorkomt het witwassen van rechten (permission laundering). Stel dat een manager strategische prognoses mag inzien en een research-agent openbare bronnen mag bevragen. Een planner die beide kan aanroepen, mag er niet voor zorgen dat de research-agent de privédatarechten van de manager krijgt. Omgekeerd mag een finance-medewerker met permanente ERP-toegang deze niet gebruiken voor elke gebruiker die de planner kan aanroepen. Elke hop moet de agent, het subject, de delegatierelatie, de opgevraagde resource en de taakomvang verifiëren.

Een delegatie-envelope kan deze feiten expliciet maken. Deze kan het subject, de actor, de parent actor, de taak-ID, toegestane operaties, resource-ID's, dataklassen, het doel, de vervaldatum, de maximale diepte, de goedkeuringsreferentie en de correlatie-ID bevatten. De envelope is niet noodzakelijkerwijs één universeel token; het is het minimale semantische record dat beleids- en bewijssystemen moeten behouden over protocol-specifieke credentials heen.

Delegatie moet worden ingeperkt (attenuation). Een parent kan een child minder rechten verlenen dan hij zelf heeft, niet meer. Child-agents mogen geen credentials doorsturen die ze niet nodig hebben. Maximale ketendiepte en goedgekeurde agent-tot-agent-relaties beperken onverwachte uitwaaiering (fan-out). Intrekking moet nieuwe calls snel blokkeren, terwijl al vastgelegde bedrijfstransacties expliciete annulerings- of reconciliatieregels volgen.

Bepaal de scope van goedkeuring op beslissingsniveau, niet alleen op toolnaam

Menselijke goedkeuring is vaak geïmplementeerd als "sta de restitutie-tool toe". Dat kan volstaan voor gevallen met een laag risico, maar het is niet hetzelfde als het goedkeuren van elk toekomstig argument, elke klant en elk bedrag. Een krachtig goedkeuringsrecord vermeldt de aanvrager en agent, de operatie, de essentieel geachte argumenten of de hash daarvan, de resource, de reden, de geldigheid en de status die de beoordelaar zag.

Geldigheid kan gebaseerd zijn op aantal of tijd, maar tijd alleen is niet voldoende. Een betaling die is goedgekeurd toen een factuur geldig was, kan onveilig worden nadat de bankgegevens veranderen. Een deployment die is goedgekeurd voor één artifact-digest mag niet gelden voor een andere build. Wezenlijke statusveranderingen moeten de goedkeuring ongeldig maken of opnieuw controleren vóór de uitvoering. De applicatie is eigenaar van deze binding omdat deze de domeinregels kent; een goedkeuring op gateway-niveau kan een waardevolle lease op tool-niveau bieden zonder dat deze elke domein-invariant kent.

Goedkeuring vervangt ook geen autorisatie. Een goedkeurder mag geen toegang kunnen verlenen die hij zelf niet bezit. De tool moet binnen het toegestane bereik van de agent, de delegeerbare autoriteit van het subject en het downstream beleid blijven. Goedkeuring is een aanvullende voorwaarde voor een gevoelige actie, geen kanaal om regels te omzeilen.

Herautoriseer op de mutatiegrens

Agent-runs kunnen minuten of uren duren. Gedurende die tijd kan een gebruiker van rol veranderen, een klantedossier worden geblokkeerd, een factuur worden betaald, een beleid worden aangescherpt of een goedkeuring verlopen. Autorisatie die alleen is geëvalueerd toen het gesprek begon, is per definitie verouderd. Controleer kortstondige credentials en zakelijke omstandigheden met een hoge impact opnieuw op het moment van mutatie.

Gebruik een operatie-ID voor elke side-effect die opnieuw geprobeerd kan worden. Leg de intentie vast vóór de call, stuur de ID mee wanneer het doel idempotentie ondersteunt, en reconcilieer met het authoritative system na een onduidelijke fout. Een runtime-event dat meldt "tool retourneerde succes" is een bewijs van de tool-interactie; het is geen bewijs dat het doel de beoogde status heeft vastgelegd. De geautoriseerde transactie of post-conditie levert dat bewijs.

Ontwerp het auditrecord voor reconstructie

Een auditrecord moet een onderzoeker in staat stellen de autorisatiebeslissing te reconstrueren zonder de verborgen redenering van een model opnieuw af te spelen. Leg de identiteiten van subject en actor, geauthenticeerde issuers, parent-delegatie, opgevraagde operatie, genormaliseerde argumenten of beschermde digest, resource, toepasselijke beleidsversies, autorisatieresultaat, goedkeuringsbesluit, model- en tool-events, operatie-ID en het gereconcilieerde resultaat vast.

Sla gevoelige data niet willekeurig op onder het mom van controleerbaarheid. Metadata kan vaststellen wie, wanneer, welk beleid, welk model, welke tool en hoeveel, zonder de ruwe prompts te bewaren. Waar inhoud noodzakelijk is, moeten toegangscontroles, bewaartermijnen, anonimisering en doelgebonden logging worden toegepast. De huidige logging-configuratie van TrueFoundry scheidt opgeslagen verzoek- en respons-bodies expliciet van kosten-, token-, latency- en metadatarecords: de opslag van bodies kan worden uitgeschakeld of geanonimiseerd terwijl de overige trace-data bewaard blijft.

Onveranderlijkheid en bewaartermijnen blijven de verantwoordelijkheid van de deployment. Bepaal waar records naartoe worden geëxporteerd, wie ze mag wijzigen, hoe klokken worden gesynchroniseerd, welke correlatie-ID's systemen overschrijden en hoe lang elke klasse van bewijsmateriaal wordt bewaard. Onontkenbaarheid (non-repudiation) ontstaat niet door simpelweg een agent ID-veld toe te voegen aan een gewoon, aanpasbaar logbestand.

Hoe TrueFoundry en TrueForge in elkaar passen

De productkoppeling is het sterkst wanneer identiteits- en controlelagen bewust worden gecombineerd. Behoud bij een workflow per gebruiker het gebruikers-token, koppel de huidige agent identity, autoriseer dat paar bij de gateway, gebruik de beoogde downstream delegatiemodus, houd ingrijpende tools vast waar menselijke goedkeuring vereist is, en geef een operatie-ID door aan de bedrijfsapplicatie. De applicatie dwingt vervolgens de huidige status af en retourneert een resultaat dat kan worden afgestemd op de run.

Praktijkvoorbeeld: een factuurbetalings-agent

Een controller vraagt een planner-agent om een goedgekeurde factuur te betalen. De planner delegeert de validatie naar een accounts-payable-agent, die de ERP-factuur en het leveranciersrecord leest. Een afzonderlijke treasury-agent kan de betalingsinstructie indienen.

De controller blijft het subject. Elke agent presenteert zijn eigen identiteit als actor. De planner kan de accounts-payable-agent aanroepen, maar heeft geen toegang tot de betalings-tool. De accounts-payable-agent kan alleen facturen lezen binnen de entiteit-scope van de controller en retourneert een getypeerde bevinding, geen credentials. De treasury-agent ontvangt een delegatie-envelope die beperkt is tot de factuur, het bedrag, de valuta, de ID van de begunstigde en de vervaldatum.

Vóór het indienen verifieert de gateway of het paar van treasury-agent en controller de betalings-MCP-server mag bereiken. Een eenmalige goedkeuring bindt de beoordelaar aan de genormaliseerde betalingsinstructie. Het bank- of treasury-systeem verifieert onafhankelijk de tekenbevoegdheid, sanctiestatus, dubbele betalingsstatus en actuele leveranciersgegevens. Als de call een time-out geeft, controleert de workflow de operatie-ID voordat deze het opnieuw probeert. De voltooiing wordt pas geregistreerd nadat het authoritative system de vastgelegde status van de instructie meldt.

Als de planner wordt getroffen door een prompt injection via een factuurbijlage, stuit de aanvaller nog steeds op onafhankelijke grenzen: de planner mist het bereik om betalingen uit te voeren; de worker kan de scope van de controller niet uitbreiden; de treasury-agent ontvangt begrensde argumenten; de goedkeuring is specifiek; en het authoritative system dwingt de actuele regels af. Het model kan nog steeds een verkeerd voorstel doen, maar de autoriteitsketen beperkt wat er met dat voorstel kan gebeuren.

Fouttesten voor de autoriteitsketen

• Verloren subject: verwijder de menselijke identiteit bij een agent-hop en controleer of het verzoek mislukt in plaats van terug te vallen op een gedeelde superuser.
• Agent-substitutie: presenteer het gebruikers-token met een niet-geregistreerde of niet-geautoriseerde agent identity.
• Permission laundering: vraag een child met lage rechten om het bereik van een parent met hoge rechten te gebruiken.
• Verkeerde audience: presenteer een token dat is uitgegeven voor een andere MCP-resource en controleer of het wordt geweigerd.
• Verouderde goedkeuring: wijzig essentiële argumenten of de bedrijfsstatus na goedkeuring en controleer of er opnieuw wordt geautoriseerd.
• Onduidelijke mutatie: verbreek de verbinding voor de respons na vastlegging (commit) en controleer of reconciliatie dubbele uitvoering voorkomt.
• Introkken subject: verwijder de rol van de gebruiker tijdens een lange run en controleer of de volgende gevoelige operatie de autorisatie opnieuw controleert.

Identiteit zorgt voor verantwoording; autorisatie begrenst de actie

Agent identity is essentieel omdat gedeelde, anonieme automatisering geen nauwkeurig beleid of reconstructie kan ondersteunen. Maar het uiteindelijke doel van een veilige architectuur is groter: een end-to-end autoriteitsketen die behoudt wie het werk heeft aangevraagd, welke workload heeft gehandeld, wat er is gedelegeerd, op welke resource het gericht was, wat een mens heeft goedgekeurd, wat het huidige beleid toestond en wat het authoritative system heeft vastgelegd.

Wanneer die feiten gescheiden blijven, wordt agent-autonomie bestuurbaar. Wanneer ze worden samengevoegd tot één bearer token of één "goedgekeurde agent"-label, kunnen geldige credentials ongeldige autoriteit verbergen. De technische regel is eenvoudig, zelfs als de implementatie dat niet is: authenticeer elke actor, koppel delegatie in bij elke hop, en laat de resource-eigenaar de uiteindelijke zakelijke beslissing nemen.

Referenties

1. PwC — AI agents as workforce counterparts: what governance should look like.
2. NIST NCCoE — Draft concept paper on software and AI agent identity and authorization.
3. Model Context Protocol — Authorization security considerations, 2026-07-28.
4. TrueFoundry — Agent Identity (beta).
5. TrueFoundry — MCP Gateway Authentication and Security.
6. TrueFoundry — MCP Tool Approvals.
7. TrueFoundry — Logging Configuration.
8. TrueForge — SDK Concepts.

Redactionele vermelding. Dit artikel geeft de technische interpretatie van TrueFoundry weer van de geciteerde openbare bronnen per 13 september 2026. Productmogelijkheden zijn beperkt tot de gelinkte documentatie. Voorbeelden dienen ter illustratie en zijn geen juridisch advies, audit-oordeel, onafhankelijke benchmark of garantie voor naleving of beveiliging.

‍