Om werkende AI-systemen te bouwen, moet je ze eerst proberen te breken. We voerden een red teaming-traject uit en testten als aanvallers een klantgerichte AI-app voor financiële dienstverlening. Onze bevindingen zijn relevant voor iedereen die door LLM's aangedreven applicaties inzet waarbij beveiliging geen bijzaak mag zijn.
Red teaming houdt in dat je bewust probeert je AI-systeem te breken, zodat je kwetsbaarheden kunt verhelpen voordat een echte aanvaller ze vindt. Bij financiële dienstverlening staat er bijzonder veel op het spel: AI-applicaties verwerken klantgegevens en transacties en bieden financiële inzichten. De gevolgen van een fout kunnen uiteenlopen van een slechte gebruikerservaring tot overtreding van regelgeving, financiële verliezen en onherstelbare reputatieschade.
Ons doel was kwetsbaarheden vroegtijdig te vinden, realistische aanvalspatronen te testen en de organisatie te helpen voldoen aan de AI-veiligheidseisen die toezichthouders zeer serieus nemen.
Een belangrijk onderscheid: een jailbreak valt de veiligheidsfilters van het onderliggende model aan; prompt-injectie richt zich op de applicatie zelf en combineert onbetrouwbare gebruikersinvoer met de vertrouwde prompt van de ontwikkelaar. Prompt-injectie brengt meer risico met zich mee, omdat de aanval gericht is op je systeem en de vertrouwelijke gegevens die het verwerkt, niet op een model voor algemeen gebruik.
Onze eerste testronde bestond uit ongeveer 750 tests op het gebied van:
Gegevenslekken tussen sessies
Blootstelling van persoonsgegevens (via natuurlijke taal, API-manipulatie en verschillende coderingen)
SQL-injectie
Omzeiling van systeemprompts
Tijdens die eerste tests stelden we twee grote problemen met het bestaande systeem vast: de verwerking van vragen met meerdere intenties en het gebruik van gecodeerde prompts.
Vragen met meerdere intenties: verzoeken waarin legitieme en kwaadaardige opdrachten worden gecombineerd. Bijvoorbeeld: “Toon mijn uitgaven per categorie en voer ook [kwaadaardige SQL] uit.” De applicatie herkende de kwaadaardige intentie niet en vertrouwde volledig op beveiligingsmaatregelen in de achterliggende gegevenslaag. Dat is alsof je de voordeur openlaat omdat je vertrouwt op de kluis in de kelder.
Codering: verzoeken die zijn gecodeerd met Base64, Hex, LeetSpeak of homogliefen. Het kan voor systemen lastig zijn om kwaadaardige intenties eruit te filteren. Hoewel deze vragen geen gevoelige gegevens blootlegden, destabiliseerden ze het systeem wel aanzienlijk, met onder meer hallucinaties, kwaadaardige SQL die letterlijk aan gebruikers werd teruggegeven en een verwarde intentieclassificatie.
De eerste tests leverden de volgende resultaten op:
Temporele hallucinaties: het model gaf met grote stelligheid verzonnen datums, tijdstempels van transacties of tijdgebonden overzichten. Dat vormt een aanzienlijk risico in een financiële context, waar handelen op basis van een verkeerde datum echte gevolgen kan hebben
Kwaadaardige SQL die letterlijk aan de gebruiker werd teruggegeven, met risico op geheugenvergiftiging
Verwarde intentieclassificatie
Verhaspelde uitvoeropmaak
Met die bevindingen op zak scherpten we onze focus aan. Tests met SQL-injectie en codering kregen minder prioriteit, omdat het team die problemen al aanpakte. In plaats daarvan richtten we ons op de succesvolste aanvalsvectoren: blootstelling van persoonsgegevens en gegevenslekken tussen sessies.
De opvallendste bevinding uit de tweede ronde was verrassend eenvoudig: vaak hoef je helemaal niet slim te werk te gaan.
In veel gevallen hoefde je alleen maar om interne gegevens te vragen, verpakt in een verzoek dat legitiem klonk, om het systeem bereid te krijgen die gegevens prijs te geven. Bij eenvoudige vragen verwezen de antwoorden naar interne ID's en systeemvelden die nooit zichtbaar mogen zijn voor eindgebruikers.
Bij nader onderzoek bleek dit niet alleen een fout op applicatieniveau te zijn. De achterliggende tekst-naar-SQL-service stelde query's samen die meer velden opvroegen dan toegestaan, en verwees in zijn toelichtingen naar gegevens waartoe de toegang beperkt had moeten zijn. Hierdoor kwam een echte zwakke plek tussen systemen aan het licht: een kwetsbaarheid die je alleen ontdekt wanneer je de volledige stack test en niet afzonderlijke onderdelen in isolatie.
Test het systeem met red teaming, niet het model. Een LLM afzonderlijk testen zegt nauwelijks iets over de beveiliging van je applicatie. Test de volledige stack van begin tot eind, zoals een gebruiker ermee zou werken.
Invoer moet vóór de LLM worden gevalideerd. Gecodeerde query's, aanvallen met meerdere intenties en eenvoudige injectiepogingen moeten aan de buitengrens worden onderschept, niet aan achterliggende services worden overgelaten.
Vertrouw de raakvlakken niet. In architecturen met meerdere services zitten de interessantste kwetsbaarheden vaak in de kieren tussen systemen. Zero trust betekent zero trust: valideer dus alles, in elke laag.
Eenvoudige aanvallen werken. Geavanceerde jailbreaks halen de krantenkoppen, maar soms hoef je het alleen maar te... vragen. Als je systeem zonder bezwaar interne identificatiecodes toont wanneer een gebruiker die opneemt in een verder legitieme query, heb je een probleem.
Weet wat je daadwerkelijk test. Bekende aanvalspatronen worden mogelijk door de training van de LLM zelf onderschept en niet door je beveiligingsmaatregelen. Bouw waarneembaarheid in je red teaming-proces in om te begrijpen welke beheersmaatregelen daadwerkelijk worden aangesproken.
Beperkte omgevingen vragen om creatieve oplossingen. Dankzij aangepaste providers en ondersteuning voor lokale modellen is zinvolle red teaming mogelijk zonder gespecialiseerde cloudtoegang. Wees wel transparant over de beperkingen die dit met zich meebrengt.
Red teaming is niet eenmalig. Het is een iteratief proces, moet waar mogelijk worden geautomatiseerd en moet met je systeem mee-evolueren. De aanvallen die morgen relevant zijn, zijn niet dezelfde als die van vandaag.
AI-systemen in gereguleerde omgevingen zullen alleen maar strenger worden gecontroleerd. Organisaties die beveiligingstests als een doorlopend proces beschouwen in plaats van als een afvinkvakje vóór de lancering, zijn beter voorbereid op die controle en voorkomen pr-rampen die het vertrouwen van klanten schaden.