For å bygge KI-systemer som fungerer, må du først prøve å bryte dem ned. Vi gjennomførte red teaming der vi opptrådte som angripere for å teste og utfordre en kunderettet KI-app for finansielle tjenester. Funnene våre er viktige for alle som tar i bruk LLM-drevne applikasjoner der sikkerhet er helt avgjørende.
Red teaming innebærer at du bevisst prøver å bryte ned KI-systemet ditt, slik at du kan utbedre sårbarheter før en reell angriper finner dem. Innen finansielle tjenester er særlig mye på spill: KI-applikasjoner behandler kundedata og transaksjoner og gir økonomisk innsikt. En svikt kan føre til alt fra en dårlig brukeropplevelse til regelbrudd, økonomiske tap og uopprettelig skade på merkevaren.
Målet vårt var å finne sårbarheter tidlig, teste realistiske angrepsmønstre og hjelpe organisasjonen med å oppfylle forventningene til KI-sikkerhet som tilsynsmyndighetene tar svært alvorlig.
Her er det verdt å skille mellom to ting: Jailbreak-angrep retter seg mot sikkerhetsfiltrene i den underliggende modellen, mens promptinjeksjon angriper selve applikasjonen ved å kombinere uklarert brukerinndata med utviklerens klarerte prompt. Promptinjeksjon utgjør en større risiko fordi angrepet retter seg mot systemet ditt og de konfidensielle dataene det behandler, ikke mot en generell modell.
Den første testrunden vår omfattet rundt 750 tester av:
Datalekkasje mellom økter
Eksponering av personopplysninger (via naturlig språk, API-manipulering og ulike typer koding)
SQL-injeksjon
Overstyring av systemprompter
I den innledende testingen avdekket vi to store problemer med det eksisterende systemet: håndteringen av forespørsler med flere hensikter og bruken av kodede prompter.
Forespørsler med flere hensikter: forespørsler som kombinerer legitime og ondsinnede ønsker. For eksempel: “Vis utgiftene mine etter kategori og kjør [ondsinnet SQL].” Applikasjonen oppdaget ikke den ondsinnede hensikten, men stolte i stedet utelukkende på sikkerhetsmekanismene i det underliggende datalaget. Det tilsvarer å la ytterdøren stå åpen fordi du stoler på safen i kjelleren.
Koding: forespørsler som er kodet med Base64, heksadesimal kode, LeetSpeak eller homogryfer. Det kan være vanskelig for systemer å filtrere ut ondsinnede hensikter. Selv om disse forespørslene ikke eksponerte sensitive data, bidro de til betydelig ustabilitet i systemet, blant annet hallusinasjoner, ondsinnet SQL som ble gjengitt til brukerne, og forvirret klassifisering av hensikt.
Den innledende testingen viste følgende:
Tidsrelaterte hallusinasjoner: Modellen oppga oppdiktede datoer, transaksjonstidspunkter eller tidsavgrensede sammendrag med stor sikkerhet. Dette utgjør en betydelig risiko i finansiell sammenheng, der det kan få reelle konsekvenser hvis en kunde handler ut fra feil dato.
Ondsinnet SQL ble gjengitt ordrett til brukeren, noe som gir grunn til bekymring for risikoen for minneforgiftning
Forvirret klassifisering av hensikt
Rotete formatering av utdata
Med disse funnene i bagasjen snevret vi inn fokuset. Tester av SQL-injeksjon og koding ble nedprioritert fordi teamet allerede jobbet med disse problemene. I stedet konsentrerte vi oss om de mest effektive angrepsvektorene: eksponering av personopplysninger og lekkasje mellom økter.
Det mest slående funnet fra andre runde var forbløffende enkelt: Ofte trenger du ikke å være særlig utspekulert.
I mange tilfeller var det nok å bare be om interne data som del av en tilsynelatende legitim forespørsel for å få systemet til å gå med på å eksponere dem. Enkle forespørsler fikk svar med interne ID-er og systemfelt som aldri burde vært synlige for sluttbrukere.
Da vi undersøkte nærmere, fant vi ut at dette ikke bare var en svikt på applikasjonsnivå. Den underliggende tekst-til-SQL-tjenesten konstruerte spørringer som ba om flere felt enn den skulle, og forklaringene den ga, viste til data som skulle vært underlagt tilgangsbegrensninger. Dette avdekket en reell sprekk mellom systemene – en type sårbarhet som først kommer til syne når hele teknologistakken testes samlet, ikke når enkeltkomponenter testes isolert.
Gjennomfør red teaming av systemet, ikke modellen. Å teste en LLM isolert sier svært lite om sikkerheten i applikasjonen din. Test hele teknologistakken fra ende til ende, slik en bruker ville samhandlet med den.
Inndata må valideres før de når LLM-en. Kodede forespørsler, angrep med flere hensikter og enkle injeksjonsforsøk bør oppdages ved yttergrensen, ikke overlates til underliggende tjenester.
Ikke stol på overgangene mellom systemene. I arkitekturer med flere tjenester er det i sprekkene mellom systemene at de mest interessante sårbarhetene skjuler seg. Nulltillit betyr nulltillit, så valider alt i hvert eneste lag.
Enkle angrep fungerer. Avanserte jailbreaks får overskriftene, men noen ganger kan du bare ... spørre. Hvis systemet villig viser interne identifikatorer når en bruker inkluderer dem i en ellers legitim forespørsel, har du et problem.
Forstå hva du faktisk tester. Kjente angrepsmønstre kan bli stoppet av LLM-ens egen trening i stedet for av sikkerhetsmekanismene dine. Bygg inn observerbarhet i red teaming-prosessen for å forstå hvilke sikkerhetstiltak som faktisk aktiveres.
Begrensede miljøer krever kreative løsninger. Tilpassede leverandører og støtte for lokale modeller gjør det mulig å gjennomføre meningsfull red teaming uten spesialisert skytilgang. Vær imidlertid åpen om begrensningene dette medfører.
Red teaming er ikke noe man gjør bare én gang. Prosessen er iterativ, bør automatiseres der det er mulig, og må utvikle seg i takt med systemet. Angrepene som blir viktige i morgen, er ikke de samme som er viktige i dag.
KI-systemer i regulerte miljøer vil bare bli møtt med strengere kontroll, ikke mindre. Organisasjoner som behandler sikkerhetstesting som et kontinuerlig arbeid i stedet for et punkt som skal krysses av før lansering, vil være bedre rustet til å møte denne kontrollen og unngå omdømmekriser som ødelegger kundenes tillit.