Gedelegeerde toegang voor agents

Wat is gedelegeerde toegang voor agents?

Gedelegeerde toegang is de manier waarop een agent iets mag doen voor een collega zonder die collega te worden. De agent houdt een eigen identiteit, de persoon houdt de zijne, en wat de twee verbindt staat ergens opgeschreven: welke handelingen, hoe lang, en wie het gegeven heeft.

RFC 8693, de OAuth-standaard voor token exchange, is daar scherp in. Krijgt de ene partij alle rechten van de andere en valt ze, in de bewoording van die tekst, niet meer van die andere te onderscheiden, dan heet dat impersonation. Behoudt de handelende partij haar eigen identiteit en is het uitdrukkelijk begrepen dat de handeling gesteld wordt door de agent die de persoon vertegenwoordigt, dan heet dat delegatie. Niet te onderscheiden, of uitdrukkelijk begrepen.

Of een agent überhaupt een eigen login heeft, is de vraag achter agentidentiteit. Delegatie is de vraag daarna: wat die login mag doen voor één collega met naam, en tot wanneer.

De twee sluipwegen, en hoe je log er nadien uitziet

De eerste sluipweg geeft de agent de login van de persoon zelf: een gekopieerd wachtwoord, een geleende sessie, een token uit haar aanmelding. Elke handeling komt dan onder haar naam aan de overkant binnen, en niets in dat verzoek zegt dat er een agent tussen zat, want dat kan er ook niet in staan. Zes weken later mag die collega een bestelbon uitleggen die ze nooit gezien heeft.

De tweede zet de agent op het gedeelde integratieaccount. Nu lijkt niets meer op haar, wat vooruitgang lijkt tot je merkt dat niets meer op iemand lijkt. Vijf agents en twee nachtelijke jobs op één account leveren een kolom identieke regels op, en dat account draagt elk recht dat ooit iemand eraan moest hangen.

Zet die twee naast een agent met een delegatie op één punt, namelijk wat je log je een maand later vertelt. Bij het gedeelde account staat er dat het account om 09:12 een bestelbon aanmaakte, en daar stopt het: niet welke agent, niet voor wie, niet op wiens gezag. Bij een delegatie noemt diezelfde regel de agent, noemt hij de collega voor wie hij handelde, en verwijst hij naar de toestemming die dat toeliet.

Wat een gedelegeerd token meedraagt

Twee identiteiten in plaats van één. RFC 8693 voorziet daar de claim act voor: een manier om in een token uit te drukken dat er delegatie plaatsvond en om de handelende partij te benoemen aan wie het gezag gedelegeerd werd. Het subject blijft de persoon, de actor is de agent. Een tweede claim, may_act, legt vooraf vast wie actor mag worden voor wie, zodat de autorisatieserver een delegatie kan weigeren die niemand ooit goedkeurde.

Een korte lijst scopes in plaats van alles waar de persoon aan kan. Je collega op de logistiek kan facturen lezen, stamgegevens wijzigen en zendingen annuleren. De agent die ophaalslots boekt heeft twee van die werkwoorden nodig en geen van die zelfstandige naamwoorden. In de scopes wordt least privilege een keuze die iemand echt moet maken in plaats van een principe.

Een einde. De vervaltijd van het token bepaalt hoe lang een gelekte kopie nog iets waard is. De toestemming zelf heeft een eigen einddatum nodig, en die bepaalt hoe lang de afspraak de aanleiding overleeft.

De claims die het werk doen zien er zo uit, en de tweede regel is net wat een serviceaccount nooit kan tonen.

{
  "sub": "lieve.dm@voorbeeld.be",
  "act": { "sub": "agent-logistiek-03" },
  "scope": "pickup.read pickup.create",
  "exp": 1788523200
}

Wat vastligt in een standaard, en wat nog voorstel is

Gepubliceerde standaarden. De authorisation code flow met scopes, beschreven in OAuth 2.0 (RFC 6749) en overgenomen in het ontwerp van OAuth 2.1, is hoe iemand een applicatie afgebakende toegang geeft zonder een wachtwoord af te staan. Token exchange (RFC 8693) is gepubliceerd en levert de woordenschat hierboven, en dat geldt ook voor token revocation (RFC 7009). Geen van de drie is voor AI-agents geschreven, en alle drie werken ze ervoor.

Een leverancierspatroon daarbovenop. De on-behalf-of-flow van Microsoft is het best gedocumenteerd. Een dienst wisselt het token dat ze kreeg om voor een token waarmee ze de volgende dienst aanroept, en Microsoft omschrijft de bedoeling als het doorgeven van de identiteit en de rechten van de gebruiker doorheen de keten. Er zitten alleen gedelegeerde scopes in en nooit applicatierollen, want rollen blijven aan de gebruiker hangen en niet aan de applicatie die voor haar handelt. Het is ook niet de token-exchange-grant, wel de JWT bearer grant met een eigen parameter requested_token_use=on_behalf_of. Hun richtlijn voor agents splitst op dezelfde lijn: een interactieve agent die werkt voor een aangemelde collega krijgt gedelegeerde rechten via die flow, een zelfstandige agent draait op zijn eigen identiteit via client credentials.

Nog in ontwerp. De MCP-specificatie voor autorisatie van 28 juli 2026 is OAuth 2.1 met resource indicators, zodat een token aan één server vasthangt, maar ze beschrijft geen delegatieketen. Transaction tokens, die de identiteit van de gebruiker meedragen doorheen een reeks interne diensten, zijn een werkgroepdocument bij de OAuth-werkgroep, versie 11 van 30 juli 2026. Het profiel dat zou vastleggen hoe je de actor benoemt voor agents over organisaties heen, bestaat als individueel ontwerp van april 2026 en heeft geen formele status. De onderdelen om dit vandaag te bouwen liggen dus vast. Wat ontbreekt is het profiel dat de delegatie van de ene leverancier leesbaar maakt voor het systeem van de andere.

De keuzes die je maakt voor je een delegatie uitdeelt

1. Welke scopes. Vertrek van de twee of drie handelingen die de agent aantoonbaar stelt. Vertrekken van de rechten van wie hem bouwde en achteraf afromen gebeurt nooit, want tegen dan weet niemand nog wat er zou stilvallen.

2. Hoe lang ze loopt, en wat er gebeurt als zij weg is. Zet de einddatum vast bij het aanmaken, want het moment waarop iemand vraagt of dit nog nodig is, komt uit zichzelf niet. Twee weken verlof is prima voor het boeken van ophaalslots en niet prima voor het goedkeuren van betalingen.

3. Of de persoon erbij moet zijn. Een delegatie die ze op het moment zelf goedkeurt, is het veiligst en het lastigst. Eén die blijft doorlopen via een refresh token laat de agent om drie uur 's nachts werken, en meestal is dat net waarom je hem gebouwd hebt. Dat tweede is een staande volmacht, dus noem het zo.

4. Wat ze ziet op het moment dat ze toestemt. Een scherm met veertig rechten erop is geen echte toestemming, want niemand leest veertig regels en geen enkele ervan zegt welke deze agent gaat gebruiken. Twee of drie scopes in gewone taal, met de einddatum erbij, is een beslissing die een mens echt kan nemen.

De toegang van één agent intrekken zonder de persoon uit te schakelen

De eis is smal. Je moet de toegang van één agent kunnen afnemen zonder aan het account van de collega te raken, en je moet kunnen antwoorden wie deze agent hiervoor gemachtigd heeft.

RFC 7009 dekt het eerste stuk. Die beschrijft het revocation-endpoint, verplicht ondersteuning voor het intrekken van refresh tokens, beveelt het aan voor access tokens, en stelt dat het intrekken van een refresh token ook de access tokens uit diezelfde toestemming ongeldig hoort te maken. Een intrekking landt daardoor op het tempo van je tokenlevensduur: een agent met een token van een uur werkt tot een uur later gewoon door. De dag dat de collega vertrekt, moeten haar delegaties mee met haar account, en iets moet benoemen welke agents daardoor stilvallen. Anders leer je het van het proces dat de dinsdag erna faalt.

Het tweede stuk is boekhouding en geen protocol. Wie dit gemachtigd heeft, is enkel te beantwoorden als die toestemming ergens als een object bestaat, met een nummer, een persoon die ze gaf, een datum, de scopes en een einddatum. Vraag aan je platform vooral één ding: een filter die elke handeling van één agent vindt, en elke handeling die voor één persoon gesteld werd. Entra doet dat door de initiator en de uitvoerder van een auditgebeurtenis te merken met een agentType, wat een draaiende agent onderscheidt van het gebruikersaccount van een agent, het accounttype dat bestaat zodat een agent als gebruiker kan handelen met gedelegeerde rechten.

Een agent die een ophaalslot boekt, van toestemming tot logregel

Een groothandel met veertig mensen laat een agent ophaalslots boeken bij de vervoerder. Lieve van de logistiek geeft die agent één keer toegang: twee scopes, pickup.read en pickup.create, niets om te annuleren en niets aan facturen, gegeven op 19 augustus 2026 en negentig dagen geldig, dus tot 17 november. De agent heeft een eigen identiteit, agent-logistiek-03, en een eigenaar met naam. Drie weken later betwist de vervoerder een slot, en dit is de regel die je dan wil vinden.

{
  "time": "2026-09-04T09:12:44Z",
  "action": "pickup.create",
  "result": "BK-88214 voor 2026-09-05",
  "actor": "agent-logistiek-03",
  "on_behalf_of": "lieve.dm@voorbeeld.be",
  "grant": "c7f3a2, gegeven 2026-08-19, vervalt 2026-11-17"
}

Wat er gebeurde, welke agent het deed, voor wie, en onder welke toestemming. Op het gedeelde serviceaccount had je het eerste veld gehad en een naam die je niets vertelt. Op de login van Lieve had je een boeking gehad waarvan zij zweert dat ze die nooit gemaakt heeft.

Dat is meteen ook de test voor je een agent op een systeem met geld of klantgegevens aansluit. Vraag welke identiteit hij gaat gebruiken. Is het antwoord een kopie van iemands login, stop daar, want je koopt een audit trail die tegen je gaat liegen. Is het antwoord het gedeelde integratieaccount, vraag dan wat er nog allemaal op draait. En is het antwoord een eigen identiteit met een delegatie, vraag dan de lijst met scopes en de datum waarop ze afloopt.