Wat gedelegeerde bevoegdheid betekent
Gedelegeerde bevoegdheid is de toestemming die een persoon (of een organisatie) aan een AI-agent geeft om namens hen te handelen. Wanneer een assistent een vergadering in je agenda boekt, een supportticket indient onder jouw naam of een factuur ophaalt uit het portaal van een leverancier, oefent die bevoegdheid uit die bij jou vandaan komt.
Goede delegatie heeft drie eigenschappen: ze is afgebakend (de agent kan bepaalde dingen doen, niet alles), tijdgebonden (ze verloopt of kan worden ingetrokken) en toerekenbaar (de ontvangende applicatie kan vaststellen wiens bevoegdheid wordt uitgeoefend).
Waarom dit belangrijk is voor applicaties
Vanuit het perspectief van een applicatie roept een agentverzoek tot drie aparte vragen op:
- Welke client heeft dit verzonden? Dat is de identiteit van de agent, die met ondertekende requests kan worden vastgesteld (zie HTTP Message Signatures).
- Onder wiens bevoegdheid handelt deze? Dat is delegatie.
- Is die bevoegdheid genoeg voor deze actie? Dat is autorisatie, bepaald door het beleid van de applicatie zelf.
Een ondertekend request van een bekende assistant-operator beantwoordt de eerste vraag goed. Het zegt op zichzelf niets over de tweede. De assistent kan handelen voor een van je gebruikers, voor iemand die geen gebruiker van je is, of volledig op eigen initiatief. Clientidentiteit behandelen als bewijs van instemming van een persoon is een van de meest voorkomende fouten in ontwerpen voor agentinteractie. Zie wat ondertekende requests van AI-agents wel en niet bewijzen.
Hoe delegatie meestal wordt uitgedrukt
- OAuth-achtige grants. De persoon meldt zich aan bij je applicatie en geeft een agent een token met beperkte scopes, zoals gedefinieerd in OAuth 2.0 (RFC 6749). Je applicatie weet dan precies wiens bevoegdheid het token draagt, en de grant kan worden ingetrokken (RFC 7009).
- API-sleutels per account die een gebruiker aanmaakt voor een specifieke integratie, bij voorkeur met smalle rechten.
- Bevestigingen in de app voor acties met grote impact, waarbij de persoon een specifieke actie goedkeurt die de agent heeft voorbereid.
- Delegatieclaims op tokenniveau. OAuth 2.0 Token Exchange (RFC 8693) definieert een
act-claim (actor) die vastlegt dat één partij optreedt voor een andere. Nieuwer werk rond het uitdrukken van agentdelegatie in requests is nog in ontwikkeling, en applicaties moeten elke delegatieclaim verifiëren aan de hand van hun eigen registers in plaats van die op het eerste gezicht te accepteren.
Veelvoorkomende misvattingen
- "Als de agent geverifieerd is, heeft de gebruiker dit goedgekeurd." Verificatie identificeert de client. Goedkeuring moet van de persoon komen, via een kanaal dat je applicatie vertrouwt.
- "Een agent die mijn usersessie gebruikt is prima." Dat kan, maar de sessie is uitgegeven voor interactief menselijk gebruik. Veel applicaties geven de voorkeur aan een aparte, afgebakende grant voor automatisering, zodat acties toerekenbaar en intrekbaar zijn.
- "Delegatie is alles of niets." De veiligste delegaties zijn smal: brede leestoegang, schrijfrechten alleen voor specifieke acties en bevestiging voor alles wat onomkeerbaar is.
Hoe Proof of Actor hierbij past
Proof of Actor helpt je zien wanneer een interactie door een agent wordt aangestuurd of door AI wordt ondersteund, en op welke basis: verified, declared, inferred of unknown. Die context laat zien waar delegatievragen ontstaan, bijvoorbeeld bij een autonome agent die binnen een menselijke accountsessie handelt. Proof of Actor geeft geen delegatiegegevens uit en valideert die ook niet, en een Agent-resultaat impliceert nooit dat een persoon de actie heeft geautoriseerd. De eigen grants, scopes en bevestigingen van je applicatie bepalen dat, en Route laat je het juiste beleid per route toepassen zodra je echt verkeer hebt geobserveerd. Voor beleids patronen, zie beleid op applicatieniveau ontwerpen voor mensen en AI-agents.
Lees wat het bewijs wel en niet kan vaststellen, of vraag vroege toegang aan.
Bronnen
- RFC 6749: The OAuth 2.0 Authorization Framework: afgebakende grants van een resource owner aan een client
- RFC 7009: OAuth 2.0 Token Revocation: intrekken van een gedelegeerd token
- RFC 8693: OAuth 2.0 Token Exchange: de
act-claim (actor) voor delegatie