Wat agentautorisatie betekent
Agentautorisatie is de beslissing over wat een AI-agent mag doen: welke routes hij mag aanroepen, welke data hij mag lezen, welke acties hij mag uitvoeren en op welk volume. Dit is iets anders dan de identiteit van een agent, die gaat over het vaststellen welke agent, of welke agent van een operator, de aanvraag doet.
Die twee zijn makkelijk door elkaar te halen omdat ze vaak samen binnenkomen. Een ondertekende aanvraag vertelt je wie deze heeft verzonden. Maar niet of die afzender toestemming moet hebben om een account te wijzigen, een bestelling te plaatsen of data te exporteren. Identiteit is bewijs; autorisatie is beleid. Onze post over wat ondertekende aanvragen van AI-agents bewijzen, en wat niet legt het verschil uit.
Waarom dit onderscheid belangrijk is
Applicaties scheiden authenticatie en autorisatie al voor menselijke gebruikers: inloggen bewijst wie je bent, en rollen en rechten bepalen wat je kunt doen. Agents hebben dezelfde scheiding nodig, met een extra laag zorgvuldigheid:
- Identiteit kan sterk zijn terwijl toestemming ontbreekt. Een crawler met een volledig geldige HTTP message signature heeft niet van zichzelf het recht om een write-endpoint aan te roepen.
- Toestemming kan bestaan zonder sterke identiteit. Een agent die de API-sleutel van een klant gebruikt, is door die sleutel geautoriseerd, ook als niets aangeeft welke agentsoftware die sleutel vasthoudt.
- De persoon achter de agent telt mee. Wanneer een agent namens iemand handelt, wordt de vraag of die persoon die bevoegdheid heeft gegeven (zie gedelegeerde bevoegdheid).
Als je dit samenvoegt tot één controle, ontstaan twee foutmodi: legitieme automatisering blokkeren omdat er geen menselijke login is, of een goed geïdentificeerde agent vertrouwen met acties die die nooit mocht uitvoeren.
Hoe autorisatie meestal wordt uitgedrukt
De meeste applicaties autoriseren agents met mechanismen die ze al hebben:
- Credentials en scopes. API-sleutels of OAuth 2.0 tokens met scopes die beperkt zijn tot wat de integratie nodig heeft. MCP servers gebruiken hetzelfde model: de MCP authorization specification behandelt een beveiligde server als een OAuth 2.1 resource server.
- Beleid op route-niveau. Alleen-lezen routes open voor bekende agents; write-routes die een credential vereisen die aan een account is gekoppeld.
- Risiconiveaus. Handelingen met lage impact breed toegestaan, handelingen met hoge impact die sterkere credentials, bevestiging of review vereisen.
- Rate limits en quota's per operator, per credential of per route.
Bewijs van de identiteit van een agent voedt deze beslissingen als één input. Voor een uitgewerkte aanpak, zie beleid op app-niveau ontwerpen voor mensen en AI-agents. Daarmee kun je een geverifieerde operator anders behandelen dan een anonieme client, maar de toestemming zelf komt nog steeds uit je beleid.
Veelvoorkomende misverstanden
- "Geverifieerde agent betekent toegestaan." Verificatie koppelt een aanvraag aan een partij. Je beleid beslist nog steeds wat die gekoppelde partij mag doen.
- "Agents moeten worden geblokkeerd tenzij bewezen is dat ze menselijk zijn." Veel agents zijn legitieme deelnemers. De betere vraag is wat elk type actor per route mag doen.
- "Autorisatie kan uit gedrag worden afgeleid." Gedrag kan de mate van vertrouwen verhogen of verlagen over welk type actor aanwezig is. Het mag op zichzelf geen toestemming geven.
Hoe Proof of Actor hiermee omgaat
Proof of Actor beantwoordt de bewijs-vraag: welk type actor is aanwezig, op welke basis (verified, declared, inferred of unknown), en wat is bekend en wat niet. Het bepaalt bewust niet de toestemming. Een Agent-resultaat, zelfs een geverifieerd resultaat, impliceert nooit autorisatie. In Route combineert je applicatie het actorresultaat met de eigen credentials, scopes en risiconiveaus om elke interactie toe te staan, aan te passen, uit te dagen, te reviewen of te beperken, te beginnen in observatiemodus zodat je uitkomsten kunt controleren voordat je iets afdwingt.
Lees meer over hoe beslissingen in je app passen, bekijk de use cases voor APIs en MCP servers, of vraag vroege toegang aan.
Bronnen
- RFC 6749: The OAuth 2.0 Authorization Framework: tokens met scopes voor clients
- MCP specification 2026-07-28: Authorization: op OAuth gebaseerde autorisatie voor MCP servers
- RFC 9421: HTTP Message Signatures: wat een ondertekende aanvraag vaststelt