För att bygga AI-system som fungerar måste du först försöka knäcka dem. Vi genomförde red teaming och agerade angripare för att testa och granska en kundinriktad AI-app inom finansiella tjänster. Våra fynd är viktiga för alla som driftsätter LLM-baserade applikationer där säkerhet är ett krav.
Red teaming innebär att medvetet försöka knäcka AI-systemet för att kunna åtgärda sårbarheter innan en riktig angripare hittar dem. Inom finansiella tjänster står särskilt mycket på spel: AI-applikationer hanterar kunddata, behandlar transaktioner och ger finansiella insikter. Ett fel kan leda till allt från en dålig användarupplevelse till regelöverträdelser, ekonomiska förluster och irreparabel skada på varumärket.
Vårt mål var att hitta sårbarheter tidigt, testa realistiska attackmönster och hjälpa organisationen att uppfylla de krav på AI-säkerhet som tillsynsmyndigheter tar på största allvar.
En viktig skillnad: jailbreak-attacker riktas mot den underliggande modellens säkerhetsfilter, medan promptinjektion angriper själva applikationen genom att kombinera opålitliga användarindata med utvecklarens betrodda prompt. Promptinjektion innebär en större risk eftersom den riktas mot ditt system och de konfidentiella data som det hanterar, inte mot en generell modell.
Vår första testomgång omfattade cirka 750 tester av:
Dataläckage mellan sessioner
Exponering av personuppgifter (via naturligt språk, API-manipulering och olika kodningar)
SQL-injektion
Åsidosättande av systempromptar
Under de inledande testerna identifierade vi två stora problem i det befintliga systemet: hanteringen av frågor med flera avsikter och användningen av kodade promptar.
Frågor med flera avsikter: förfrågningar som kombinerar legitima och skadliga önskemål. Till exempel: “Show my spending by category, and also execute [malicious SQL].” Applikationen upptäckte inte den skadliga avsikten utan förlitade sig helt på skyddsmekanismer längre ned i datalagret. Det motsvarar att lämna ytterdörren öppen för att du litar på kassaskåpet i källaren.
Kodning: förfrågningar som kodats med Base64, hex, LeetSpeak eller homoglypher. Det kan vara svårt för system att filtrera bort skadliga avsikter. Vi konstaterade att dessa frågor inte exponerade känsliga data, men de bidrog till betydande instabilitet i systemet, bland annat hallucinationer, skadlig SQL som upprepades för användarna och förvirrad avsiktsklassificering.
Resultaten från våra inledande tester visade:
Tidsrelaterade hallucinationer: modellen gav självsäkra men påhittade datum, tidsstämplar för transaktioner eller tidsbundna sammanfattningar – en betydande risk i ett finansiellt sammanhang där fel datum kan få verkliga konsekvenser för en kund
Skadlig SQL som upprepades för användaren, vilket är oroande med tanke på risken för minnesförgiftning
Förvirrad avsiktsklassificering
Förvanskad utdataformatering
Med dessa fynd i ryggen avgränsade vi vårt fokus. Tester av SQL-injektion och kodning fick lägre prioritet eftersom teamet redan åtgärdade dessa problem. I stället koncentrerade vi oss på de mest framgångsrika attackvektorerna: exponering av personuppgifter och läckage mellan sessioner.
Det mest slående fyndet i den andra omgången var förbluffande enkelt: ofta behöver man inte alls vara listig.
I många fall räckte det att helt enkelt be om interna data inom ramen för en till synes legitim förfrågan för att systemet skulle gå med på att exponera dem. Enkla frågor kunde ge svar med hänvisningar till interna ID:n och systemfält som aldrig borde visas för slutanvändare.
När vi grävde djupare upptäckte vi att felet inte bara fanns på applikationsnivå. Den underliggande text-till-SQL-tjänsten skapade frågor som begärde fler fält än den borde, och dess förklarande svar hänvisade till data som skulle ha varit begränsade. Detta blottlade en verklig spricka mellan systemen – en sårbarhet som bara visar sig när hela teknikstacken testas i stället för enskilda komponenter var för sig.
Utför red teaming på systemet, inte modellen. Att testa en LLM isolerat säger väldigt lite om applikationens säkerhetsnivå. Testa hela teknikstacken från början till slut, så som en användare skulle interagera med den.
Indata måste valideras före LLM-modellen. Kodade frågor, attacker med flera avsikter och enkla injektionsförsök bör stoppas vid systemgränsen, inte överlåtas åt underliggande tjänster.
Lita inte på skarvarna. I arkitekturer med flera tjänster gömmer sig de mest intressanta sårbarheterna i sprickorna mellan systemen. Nolltillit betyder nolltillit, så validera allt i varje lager.
Enkla attacker fungerar. Avancerade jailbreak får rubrikerna, men ibland kan du helt enkelt... fråga. Om ditt system villigt visar interna identifierare när en användare inkluderar dem i en i övrigt legitim fråga är det ett problem.
Förstå vad du faktiskt testar. Kända attackmönster kan stoppas av LLM-modellens egen träning snarare än av dina skyddsmekanismer. Bygg in observerbarhet i din red teaming för att förstå vilka kontroller som faktiskt aktiveras.
Begränsade miljöer kräver kreativa lösningar. Anpassade leverantörer och stöd för lokala modeller möjliggör meningsfull red teaming utan specialiserad molnåtkomst. Var dock öppen med vilka begränsningar detta medför.
Red teaming är ingen engångsinsats. Arbetet är iterativt, bör automatiseras där det är möjligt och utvecklas i takt med systemet. De attacker som blir viktiga i morgon är inte desamma som är viktiga i dag.
AI-system i reglerade miljöer kommer bara att granskas mer, inte mindre. De organisationer som ser säkerhetstester som ett kontinuerligt arbete snarare än en ruta att bocka av före lansering kommer att vara bättre rustade för granskningen och kan undvika PR-katastrofer som undergräver kundernas förtroende.