Hvis du vil bygge AI-systemer, der virker, skal du først prøve at ødelægge dem. Vi gennemførte en red-teaming-øvelse, hvor vi agerede angribere for at teste og undersøge en kundevendt AI-app inden for finansielle tjenester. Vores resultater er relevante for alle, der implementerer LLM-baserede applikationer, hvor sikkerhed er et ufravigeligt krav.
Red-teaming går ud på bevidst at forsøge at bryde dit AI-system, så du kan rette sårbarhederne, før en rigtig angriber finder dem. Inden for finansielle tjenester er der særligt meget på spil: AI-applikationer håndterer kundedata, behandler transaktioner og leverer finansiel indsigt. Et svigt kan føre til alt fra en dårlig brugeroplevelse til brud på lovgivningen, økonomiske tab og uoprettelig skade på brandet.
Vores mål var at finde sårbarheder tidligt, teste realistiske angrebsmønstre og hjælpe organisationen med at opfylde de forventninger til AI-sikkerhed, som myndighederne tager meget alvorligt.
Her er en vigtig forskel: Jailbreak angriber den underliggende models sikkerhedsfiltre, mens prompt injection angriber selve applikationen ved at kombinere brugerinput, der ikke er tillid til, med udviklerens betroede prompt. Prompt injection udgør en større risiko, fordi angrebet er rettet mod dit system og de fortrolige data, det behandler – ikke mod en model til generelle formål.
Vores første testrunde omfattede cirka 750 test inden for:
Datalækage på tværs af sessioner
Eksponering af personhenførbare oplysninger (via naturligt sprog, API-manipulation og forskellige kodninger)
SQL-injection
Tilsidesættelse af systemprompter
Under de indledende test identificerede vi to store problemer i det eksisterende system: håndteringen af forespørgsler med flere hensigter og brugen af kodede prompter.
Forespørgsler med flere hensigter: anmodninger, der kombinerer legitime og ondsindede forespørgsler. For eksempel: “Show my spending by category, and also execute [malicious SQL].” Applikationen opfangede ikke den ondsindede hensigt, men forlod sig udelukkende på sikkerhedsforanstaltninger længere nede i datalaget. Det svarer til at lade hoveddøren stå åben, fordi du stoler på pengeskabet i kælderen.
Kodning: anmodninger kodet med Base64, Hex, LeetSpeak og homoglyphs. Det kan gøre det svært for systemer at filtrere ondsindede hensigter fra. Selvom disse forespørgsler ikke afslørede følsomme data, bidrog de til betydelig ustabilitet i systemet, blandt andet hallucinationer, ondsindet SQL gentaget til brugerne og uklar klassificering af hensigter.
Resultaterne af vores indledende test viste:
Tidsmæssige hallucinationer: Modellen returnerede opdigtede datoer, tidsstempler for transaktioner eller tidsafgrænsede oversigter med stor sikkerhed – en betydelig risiko i en finansiel sammenhæng, hvor det kan få reelle konsekvenser, hvis en kunde handler ud fra en forkert dato
Ondsindet SQL blev gentaget til brugeren, hvilket vækker bekymring for risikoen for forgiftning af hukommelsen
Uklar klassificering af hensigter
Forvansket outputformatering
Med disse resultater i hånden indsnævrede vi vores fokus. SQL-injection og kodningstest fik lavere prioritet, da teamet allerede arbejdede på dem. I stedet fokuserede vi på de mest effektive angrebsvektorer: eksponering af personhenførbare oplysninger og lækage på tværs af sessioner.
Det mest opsigtsvækkende resultat fra anden runde var næsten afvæbnende enkelt: Ofte behøver man slet ikke være snedig.
I mange tilfælde var det nok blot at bede om interne data som en del af en tilsyneladende legitim anmodning for at få systemet til at gå med til at afsløre dem. Enkle forespørgsler udløste svar med henvisninger til interne id'er og systemfelter, som slutbrugerne aldrig burde se.
Da vi gravede dybere, opdagede vi, at fejlen ikke kun lå på applikationsniveau. Text-to-SQL-tjenesten længere nede i kæden konstruerede forespørgsler, der anmodede om flere felter end tilladt, og dens forklarende svar henviste til data, som burde have været begrænset. Det afslørede en reel sprække mellem systemerne – den slags sårbarhed, som kun viser sig, når man tester hele stacken frem for de enkelte komponenter isoleret.
Udfør red-teaming på systemet, ikke modellen. At teste et LLM isoleret fortæller meget lidt om din applikations sikkerhedsniveau. Test hele stacken fra ende til anden, sådan som en bruger ville anvende den.
Input skal valideres før LLM'et. Kodede forespørgsler, angreb med flere hensigter og grundlæggende forsøg på injection bør stoppes ved perimeteren, ikke overlades til tjenester længere nede i kæden.
Stol ikke på overgangene. I arkitekturer med flere tjenester gemmer de mest interessante sårbarheder sig i sprækkerne mellem systemerne. Zero trust betyder zero trust, så validér alt i hvert eneste lag.
Enkle angreb virker. Avancerede jailbreaks løber med overskrifterne, men nogle gange kan man bare ... spørge. Hvis dit system gladeligt viser interne id'er, når en bruger inkluderer dem i en ellers legitim forespørgsel, har du et problem.
Forstå, hvad du faktisk tester. Kendte angrebsmønstre kan blive opfanget af LLM'ets egen træning frem for af dine sikkerhedsforanstaltninger. Indbyg observerbarhed i din red-teaming, så du kan se, hvilke kontroller der rent faktisk aktiveres.
Begrænsede miljøer kræver kreative løsninger. Tilpassede udbydere og understøttelse af lokale modeller gør effektiv red-teaming mulig uden specialiseret adgang til cloudtjenester. Vær dog åben om de begrænsninger, det medfører.
Red-teaming er ikke en engangsøvelse. Det er en iterativ proces, som bør automatiseres, hvor det er muligt, og udvikle sig i takt med dit system. De angreb, der er vigtige i morgen, er ikke de samme som dem, der er vigtige i dag.
AI-systemer i regulerede miljøer vil kun blive mødt med mere kontrol, ikke mindre. De organisationer, der behandler sikkerhedstest som en løbende disciplin frem for et punkt, der skal krydses af før lanceringen, vil være bedre rustet til at leve op til kontrollen og undgå PR-katastrofer, der koster kundernes tillid.