Authenticatie bepaalt wie je bent; autorisatie bepaalt wat je mag doen. Een groeiend aantal AI-gestuurde applicaties verifieert de identiteit van een gebruiker eenmalig bij het inloggen en laat de onderliggende agent vervolgens de rest van de sessie op elke resource acteren, wat in feite neerkomt op het geven van een "blanco cheque". Dit ontwerp opent de deur naar onbedoelde datalekken, ongewenste e-mails of zelfs destructieve database-updates, en het risico neemt toe telkens wanneer een AI-assistent meerdere tools kan aanroepen met een latentie van slechts enkele milliseconden.

Waarom deze fout blijft voorkomen

De meeste AI-ontwikkelaars beschouwen het inlogscherm als de enige beveiligingspoort. De code vraagt om een wachtwoord of een token, markeert de sessie als "geauthenticeerd" en gaat er vervolgens van uit dat elk volgend verzoek veilig is. In een traditionele webapp zorgen de trage klikken van een menselijke gebruiker voor een natuurlijk rempunt; een mens zal pauzeren voordat hij op "verwijderen" klikt. Een AI-agent kan echter binnen enkele seconden tientallen tool-aanroepen uitvoeren. Als het platform alleen vraagt "Is de gebruiker ingelogd?", erft elke aanroep dezelfde onbeperkte rechten.

De kernoorzaak is gemak. Teams maken vaak een enkel, langdurig serviceaccount aan voor de hele applicatie, zodat de code geen meerdere tokens of scopes hoeft te beheren. Dat account heeft doorgaans brede permissies — lezen, schrijven, verwijderen — over alle projecten. Wanneer een AI-assistent binnen die sessie draait, erft deze automatisch die rechten, ongeacht of de huidige taak daar daadwerkelijk om vraagt.

Wat er op het spel staat

  • Gegevensblootstelling – Een agent die elk bestand kan lezen nadat een gebruiker is ingelogd, kan onbedoeld vertrouwelijke documenten opnemen in een antwoord dat later buiten de organisatie wordt gedeeld.
  • Onbedoelde acties – De AI-helper van een support engineer zou een ruwe SQL-query kunnen uitvoeren op productiedatabases, simpelweg omdat de sessie van de engineer nog actief is, zelfs als de query niets te maken heeft met het ticket dat wordt afgehandeld.
  • Naleving van regelgeving – Veel gegevensbeschermingsregels vereisen dat toegang beperkt blijft tot het strikt noodzakelijke minimum. Een model met algemene permissies kan deze principes schenden en leiden tot audits of boetes.
  • Operationele kosten – Fouten die records verwijderen of wijzigen, dwingen teams om wijzigingen terug te draaien, de oorzaken te onderzoeken en het vertrouwen van gebruikers te herstellen — wat allemaal tijd en geld kost.

De ontbrekende stap: autorisatie per actie

Autorisatie moet bij elke "deur" binnen het systeem worden geëvalueerd, niet alleen bij de hoofdingang. De vraag verandert van "Wie is dit?" naar "Mag deze specifieke actie op dit specifieke resource nu plaatsvinden?". Het implementeren van deze controle vereist geen volledige herontwerp; het vereist alleen een verschuiving van een enkele sessie-vlag naar kortlevende, gescoped tokens.

Hoe het in de praktijk werkt

  1. Vraag een token aan met een gedefinieerde scope – Wanneer de AI-agent een tool moet aanroepen, verkrijgt deze eerst een token waarin de exacte vereiste permissies staan vermeld (bijv. read:ticket, execute:sql_query).
  2. Valideer het token voor elke aanroep – Voordat de tool wordt uitgevoerd, controleert de service of het token de benodigde scope bevat en of het token niet is verlopen.
  3. Koppel resource aan scope – Als het verzoek gericht is op een specifiek project of database, moet het token expliciet toegang verlenen tot die identifier.
  4. Weiger of sta toe – Als een controle mislukt, wordt de aanroep geweigerd en ontvangt de agent een foutmelding die hij aan de gebruiker kan tonen.

Het verschil in code is eenvoudig. Een "slechte" aanpak ziet er mogelijk zo uit:

if session.is_authenticated():
    tool.run(params)

Een "goede" aanpak breidt de controle uit:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

Het tweede patroon voegt een paar regels toe, maar dwingt het systeem om bij elke operatie de juiste vraag te stellen.

Standaarden die het makkelijker maken

OAuth 2.0-scopes bieden al een breed geaccepteerde manier om te beperken wat een token kan doen. Door kortlevende access tokens uit te geven die scopes zoals project:1234:write of email:send bevatten, kunnen ontwikkelaars vertrouwen op bestaande bibliotheken voor de verificatiestap.

De nieuwere Rich Authorization Requests (RFC 9396) breiden dit idee uit, waardoor een client tijdens runtime granulaire permissies kan aanvragen in plaats van een vooraf gedefinieerde statische lijst. Die flexibiliteit is nuttig wanneer een AI-workflow tijdens het proces mogelijkheden moet toevoegen of verwijderen op basis van de intentie van de gebruiker.

Tegenargument: eenvoud versus beveiliging

Some teams argue that per-action checks add latency and code complexity, especially when the AI assistant must call many tools in rapid succession. They point out that a single session token avoids the overhead of fetching and validating a new token for each call. The trade-off, however, is a dramatically higher exposure to misuse. Modern token-validation services are designed to operate in microseconds, and the additional network round-trip can be batched or cached without sacrificing the principle of least privilege. In environments where data integrity and compliance are non-negotiable, the modest performance cost is outweighed by the reduction in risk.

What to watch for next

  • Adoption of scoped tokens in AI SDKs – Keep an eye on updates to the major AI platform toolkits; many are beginning to expose helper functions for OAuth-based scopes.
  • Policy-as-code frameworks – Emerging solutions let teams declare authorization rules in a declarative file, automatically enforcing them at runtime.
  • Audit logs that surface per-action decisions – As more platforms record each authorization check, organizations will gain visibility into which AI actions are being allowed or blocked, informing future policy tweaks.

Takeaway

Treating a logged-in session as permission to do anything is a recipe for unintended consequences. By moving the authorization decision from the moment of login to every individual tool call—and by leveraging short-lived, scoped tokens—AI applications can keep the convenience of autonomous agents while protecting data, complying with regulations, and avoiding costly mishaps. The extra lines of code are a small price for a system that asks the right question each time an action is attempted.