Waarom agents het aanvalsoppervlak vergroten
Een klassieke chatbot ontvangt een bericht en genereert een antwoord. Een AI-agent kan daarnaast API’s aanroepen, bestanden lezen, databases bevragen, e-mails versturen of acties starten.
Daardoor wordt een fout in een prompt een reëel operationeel risico. Het probleem is niet langer alleen een verkeerd antwoord, maar ongeautoriseerde toegang tot of verzending van data.
Beveiliging moet daarom worden ontworpen op het niveau van tools, rechten en data, niet alleen in de systeemprompt.
Prompt injection kan tot datalekken leiden
Externe inhoud kan instructies bevatten die bedoeld zijn om de agent te manipuleren: een document, een e-mail, een webpagina, een supportticket of een RAG-resultaat.
Als de agent deze instructies als betrouwbaar behandelt, kan hij informatie prijsgeven, een onbedoelde tool gebruiken of afwijken van de gevraagde taak.
Alle opgehaalde inhoud moet als onbetrouwbaar worden beschouwd, systeeminstructies moeten gescheiden blijven van data en de beschikbare tools moeten strikt worden beperkt.
Minimale rechten voor de tools van de agent
Een agent die alleen de status van een bestelling hoeft te lezen, heeft geen algemene schrijftoegang tot de hele database nodig.
Elke tool moet één precieze bedrijfsoperatie aanbieden, met beperkte parameters, autorisatiecontroles aan de serverkant en validatie.
De inloggegevens die de agent gebruikt, moeten minder rechten hebben dan een menselijke beheerder, nooit meer.
Lekken tussen tenants in RAG voorkomen
In een multi-tenant SaaS moet het filter op organisatie vóór het vectorzoeken worden toegepast, niet pas nadat de documenten al zijn opgehaald.
Semantische gelijkenis mag nooit volstaan om een document toegankelijk te maken. Bedrijfsautorisatie gaat altijd voor gelijkenis.
Tests moeten scenario’s voor lekken tussen tenants bevatten, want een filterfout kan data blootleggen zonder enige technische exceptie te veroorzaken.
Geen secrets naar het model sturen
OAuth-tokens, API-sleutels, wachtwoorden, connectiestrings en technische secrets horen nooit in de context van het model.
Tools moeten hun eigen inloggegevens aan de serverkant gebruiken en alleen het benodigde bedrijfsresultaat teruggeven.
Wanneer een agent namens een gebruiker handelt, is gedelegeerde en in tijd beperkte autorisatie beter dan het rechtstreeks blootgeven van een secret.
Loggen zonder het lek in de logs te herhalen
Logs zijn essentieel om het gedrag van een agent te begrijpen, maar kunnen zelf een lekbron worden als elke prompt en elk antwoord in platte tekst wordt opgeslagen.
Geef de voorkeur aan correlatie-ID’s, metadata, beslissingen, toolnamen en statussen, en maskeer persoonlijke of gevoelige informatie.
Logs die echt inhoud nodig hebben, moeten korte bewaartermijnen en strengere toegangscontroles krijgen.
Een mens betrekken bij gevoelige acties
Het verwijderen van data, een financiële overboeking, gewijzigde rechten, een massaverzending of het delen van gevoelige documenten mag niet automatisch worden uitgevoerd op basis van alleen de output van een model.
De agent kan de actie voorbereiden, uitleggen wat hij gaat doen en vóór de uitvoering om uitdrukkelijke bevestiging vragen.
Deze validatie beperkt de impact van hallucinaties, prompt injection of een verkeerde context aanzienlijk.
