AI-chatbot tool-calls beveiligen: rechten, bevestiging en rollback

Een website-chatbot verandert fundamenteel zodra hij niet alleen antwoordt, maar ook acties mag uitvoeren. Een afspraak opvragen is nog overzichtelijk. Een afspraak annuleren, een adreswijziging of een terugbetaling verandert daarentegen de daadwerkelijke bedrijfstoestand. Het taalmodel mag daarbij een passende tool-call voorstellen. Of de actie is toegestaan, moet echter een gescheiden, deterministische applicatielaag beslissen. Veilige AI-chatbot tool-calls ontstaan daarom niet door een bijzonder strenge systeem-prompt, maar door beperkte functies, server-side rechtencontrole, een duidelijke bevestiging en een gecontroleerd uitvoeringspad.

Waarom een goed taalmodel geen autorisatie vervangt

Een model werkt met waarschijnlijkheden. Het kan een intentie verkeerd begrijpen, een parameter toevoegen of reageren op gemanipuleerde inhoud. De OWASP-risicobeschrijving over Excessive Agency noemt drie typische oorzaken: te veel functionaliteit, te verreikende bevoegdheden en te veel autonomie. Het probleem is dus niet alleen een kwaadwillige invoer. Ook een dubbelzinnige vraag of een aannemelijk klinkende modelfout kan een ongewenste actie voorbereiden.

De belangrijkste architectuurregel luidt daarom: het model formuleert een voorstel, maar de applicatie autoriseert en voert het uit. Een tool-call zoals cancelAppointment is in eerste instantie slechts een gestructureerde intentie. Pas een policy-check controleert gebruiker, tenant, object, toegestane actie, huidige status en de noodzakelijke bevestiging. Deze scheiding is een aanvulling op de bescherming tegen prompt injection bij website-chatbots; deze blijft ook noodzakelijk als er geen aanval is gedetecteerd.

Elke tool indelen op basis van impact in plaats van naam

Teams moeten niet de gehele chatbot algemeen als "veilig" of "kritiek" classificeren. Bepalend is de impact van elke afzonderlijke tool. Een eenvoudige risicomatrix schept helderheid:

• Lezend en weinig gevoelig: openingstijden of openbaar beschikbare productinformatie ophalen.
• Lezend en persoonsgebonden: een bestelstatus of klantgegevens tonen; hiervoor moeten identiteit, tenant en objectrelatie worden gecontroleerd.
• Schrijvend, maar goed omkeerbaar: een verzoek om terug te bellen aanmaken of een vrijblijvende notitie toevoegen.
• Ingrijpend of moeilijk omkeerbaar: een boeking annuleren, contactgegevens wijzigen, inhoud publiceren, berichten verzenden of betalingen starten.

Uit deze klasse volgen rechten, bevestigingsniveau, limieten en logging. Een algemene vrijgave als "de chatbot mag het CRM gebruiken" is te grof. Beter is een lijst met concrete vaardigheden met gedefinieerde parameters en toegestane statusovergangen.

Least Privilege begint bij het afbakenen van functies

De OWASP Authorization Cheat Sheet adviseert Least Privilege en Deny by Default. Voor tool-calls betekent dit: een chatbot krijgt alleen de functie en de dataselectie die nodig zijn voor de specifieke stap.

Kleine hulpmiddelen in plaats van universele interfaces

Een tool getOrderStatus(orderId) is eenvoudiger zuiver te beveiligen dan een open databasetoegang. Een tool requestCallback(topic, timeWindow) is beter controleerbaar dan een algemene functie voor het verzenden van willekeurige berichten. Vrije SQL-, shell-, URL- of e-mailfuncties vergroten de mogelijke impact onnodig. Ook test-tools die niet meer nodig zijn, moeten uit de productieve catalogus verdwijnen.

Uitvoeren in de context van de ingelogde gebruiker

De backend mag er niet alleen op vertrouwen dat het model het juiste klant-ID doorgeeft. Hij moet de huidige gebruiker en tenant afleiden uit de vertrouwde sessie en voor elk object opnieuw controleren of er toegang bestaat. Het praktische verschil tussen een openbare chat en een afgeschermde omgeving wordt uitgebreid uitgelegd in het artikel over identiteit en datatoegang in het klantenportaal. Een algemeen service-account met volledige toegang is voor gebruikersgebonden acties meestal de verkeerde afsnijroute.

Parameters deterministisch valideren

Tool-parameters hebben een strikt schema nodig: toegestane velden, typen, lengtes, waardebereiken en statusregels. Een afspraak-ID moet bij de gebruiker horen, een datum moet binnen een toegestaan bereik liggen en een actie moet passen bij de huidige status. Onbekende velden worden geweigerd. De applicatie moet er bovendien voor zorgen dat de toolnaam zelf afkomstig is uit een vaste allowlist en niet wordt uitgevoerd uit vrij gegenereerde tekst.

Bevestiging moet de daadwerkelijke actie tonen

Bij ingrijpende wijzigingen is de vraag "Weet u het zeker?" niet voldoende. De OWASP-richtlijn voor transactieautorisatie beschrijft het principe "What You See Is What You Sign": gebruikers moeten de essentiële gegevens van de concrete actie kunnen herkennen en bevestigen. Voor een website-chatbot betekent dat bijvoorbeeld:

• "Afspraak op 18 augustus om 14:30 uur annuleren" in plaats van "Wijziging bevestigen"
• "Afleveradres voor bestelling …84 wijzigen naar Wenen" in plaats van "Gegevens opslaan"
• "Terugbelverzoek met onderwerp factuur aanmaken" in plaats van "Aanvraag versturen"

De bevestiging wordt aan de serverzijde gekoppeld aan exact dit concept-actie. Veranderen het doel, het bedrag, de datum, de ontvanger of andere essentiële parameters, dan vervalt deze. De bevestiging krijgt een korte geldigheidsduur en kan niet worden hergebruikt voor een tweede actie. Voor bijzonder kritieke processen kan aanvullend een hernieuwde inlog of vrijgave door een mens vereist zijn. Het model mag deze stap niet overspringen en evenmin vervangen door een geruststellend geformuleerd antwoord.

Idempotentie, limieten en rollback inplannen

Ook een correct geautoriseerde tool-call kan technisch dubbel binnenkomen: de browser herhaalt een verzoek, een timeout veroorzaakt een retry of de gebruiker stuurt hetzelfde bericht opnieuw. Schrijvende tools moeten daarom een server-side idempotentie-ID gebruiken. Voor hetzelfde ID wordt dezelfde actie hoogstens één keer uitgevoerd; een retry ontvangt het reeds bekende resultaat.

Aanvullend heeft elke tool passende grenzen nodig: maximale calls per sessie, korte timeouts, beperkte retries en een afbreking bij ongebruikelijke ketens. Vóór de uitvoering controleert de backend de status nogmaals. Zo wordt bijvoorbeeld een reeds geannuleerde boeking niet een tweede keer verwerkt. Waar mogelijk moet een actie eerst als concept of voorgemerkte opdracht worden aangemaakt. Voor onvermijdelijke directe wijzigingen moet helder zijn hoe deze gecompenseerd, ingetrokken of overgedragen worden aan een supportteam. Een voorbereid degraded mode- en rollbackplan voorkomt dat er bij een storing geëxperimenteerd moet worden.

Loggen zonder geheimen te verzamelen

Een beveiligingslogboek moet kunnen beantwoorden wie welke actie op welke basis heeft vrijgegeven en met welk resultaat heeft uitgevoerd. Zinnige gegevens zijn een gepseudonymiseerd actor-ID, tool en versie, objectreferentie, policyversie, autorisatiebesluit, bevestigings-ID, idempotentie-ID, tijdstip en resultaat. Wachtwoorden, tokens, volledige chatgeschiedenissen en onnodige persoonsgegevens horen niet thuis in dit logboek.

De OWASP AI Agent Security Cheat Sheet adviseert gestructureerde besluitvormingsgegevens voor risicovolle acties en een scheiding van besluit en uitvoering. Dat is iets anders dan volledige technische tracing: voor de beveiligingsaudit telt een beknopt, betrouwbaar bewijs van de vrijgaveketen. Bewaartermijnen en toegang moeten zijn afgestemd op de werkelijke controlebehoefte.

Een robuuste architectuur in vijf lagen

1. Dialog en voorstel: Het model herkent de intentie en genereert een gestructureerd concept van de actie, maar voert direct niets uit.
2. Policy-besluit: Een deterministische component controleert de tool-allowlist, gebruiker, tenant, object, parameters, risicoklasse en limieten.
3. Bevestiging: De interface toont de essentiële actiegegevens. De vrijgave is van korte duur en gebonden aan het ongewijzigde concept.
4. Uitvoering: Een strikt begrensd uitvoeringsorgaan (executor) controleert de autorisatie opnieuw vlak vóór de call en maakt gebruik van een idempotentie-ID.
5. Bewijs en reactie: Resultaat, fouten en vrijgaveketen worden datazuinig gelogd; alarmering, compensatie en menselijke overdracht zijn gedefinieerd.

Het NIST AI RMF Core deelt dergelijke taken in onder Govern, Map, Measure en Manage. In de praktijk betekent dit: verantwoordelijkheden en risicogrenzen vastleggen, de gebruikscontext begrijpen, controles testen en reageren op geobserveerde afwijkingen.

Testmatrix vóór de go-live

Positieve testen alleen zijn niet voldoende. Een tool moet ook onder ongunstige omstandigheden veilig falen. Minstens de volgende gevallen horen thuis in een herhaalbare testmatrix:

• Een niet-ingelogde of onbevoegde gebruiker verzoekt om de actie.
• Een geldige sessie verwijst naar een object van een andere tenant.
• Essentiële parameters veranderen na de bevestiging.
• Hetzelfde verzoek wordt herhaald vanwege een timeout of dubbelklik.
• Een tool geeft gemanipuleerde instructies of onverwachte extra velden terug.
• Een call overschrijdt tijd-, hoeveelheid- of kostenlimieten.
• Het doelsysteem valt uit tussen controle en uitvoering.
• Een bevoegdheid wordt vlak vóór de uitvoering ingetrokken.

Verwacht worden niet alleen succesvolle acties, maar duidelijke weigeringen, ongewijzigde gegevens en bruikbare beveiligingsgebeurtenissen. Voordat schrijftoegang voor echte gebruikers wordt geactiveerd, kan het proces in shadow mode worden getest met realistische vragen, zonder de voorgestelde acties uit te voeren.

Checklist voor websiteteams

• Is elke tool klein, doelgericht en afkomstig uit een vaste allowlist?
• Worden gebruiker, tenant, object en actie aan de serverzijde gecontroleerd?
• Gelden Deny by Default en minimale technische bevoegdheden?
• Zien gebruikers vóór kritieke acties alle essentiële gegevens?
• Vervalt de bevestiging bij wijzigingen en na een korte tijd?
• Voorkomt een idempotentie-ID dubbele uitvoering?
• Zijn er limieten, timeouts, afbreking, compensatie en human handoff ingericht?
• Blijven tokens, geheimen en onnodige persoonsgegevens uit de logs?
• Dekt de testmatrix rechtenfouten, manipulatie, retries en uitval af?

Conclusie: Het model stelt voor, de applicatie beslist

Een handelingsbekwame website-chatbot hoeft niet te starten met volledige toegang. Begin met een strikt begrensde, omkeerbare actie en bouw de vrijgaveketen daar zichtbaar omheen. Wanneer het afbakenen van tools, server-side autorisatie, concrete bevestiging, idempotentie en rollback samen worden ontworpen, blijft de chat behulpzaam zonder het model de rol van een beveiligingssysteem te geven. Voor de volgende stap is een workshop met product, development, support en privacy/data protection waardevol: kies een reële actie, deel het risico daarvan in en definieer vóór de eerste live-vrijgave het veilige weigeringsgeval.