Penetrationstest av AI-applikationer: OWASP LLM Top 10 i praktiken

En säkerhetsgranskning identifierar var riskerna borde finnas. Ett penetrationstest går steget längre och visar vad en angripare faktiskt kan göra. För AI-applikationer är skillnaden särskilt viktig, eftersom riskerna är nya och teoretiska resonemang lätt blir för optimistiska. Den här djupdykningen beskriver hur ett pentest av en AI-applikation går till, med OWASP LLM Top 10 som ramverk och praktiken som facit.

Jag genomför penetrationstester av AI-applikationer inom cybersäkerhet. För en orientering i själva riskkategorierna rekommenderar jag Säkerhetsgranskning av AI-applikationer; den här texten handlar om det offensiva testandet. Det offensiva perspektivet är värdefullt just för att AI-applikationer ofta beter sig på sätt utvecklarna inte förutsett. En modell är inte deterministisk på samma sätt som vanlig kod, och en angripare som tålmodigt omformulerar sina försök hittar ibland vägar som ingen designat bort, helt enkelt för att ingen tänkt på dem. Pentestet är sättet att hitta dem innan någon med onda avsikter gör det.

Granskning kontra penetrationstest

En granskning är defensiv och bred: man läser arkitektur, kod och konfiguration och bedömer var svagheter sannolikt finns. Ett pentest är offensivt och djupt: man försöker faktiskt utnyttja svagheterna, inom en överenskommen ram, och dokumenterar vad som lyckades. Båda behövs. Granskningen ger täckning, pentestet ger bevis, och inget övertygar en ledningsgrupp som ett konkret exempel på vad som faktiskt gick att åstadkomma.

Omfattning och regler innan testet börjar

Ett ansvarsfullt pentest börjar med tydliga spelregler: vilka system som ingår, vad som är tillåtet, och hur känsliga fynd hanteras. För AI-applikationer är det extra viktigt att avgränsa mot tredjepartsmodeller, testar man modellleverantörens infrastruktur eller bolagets egen integration? Nästan alltid är det det senare som är i fokus. Den här typen av leverantörsavgränsning hänger ihop med tredjepartsresonemanget i DORA-artikeln.

Att testa prompt injection på riktigt

Här blir OWASP LLM Top 10 konkret. Direkt prompt injection testas genom att försöka få modellen att ignorera sina instruktioner, läcka sin systemprompt eller agera utanför sitt mandat. Indirekt prompt injection är ofta farligare: man planterar instruktioner i innehåll som modellen läser, som ett dokument i ett RAG-flöde eller en webbsida den hämtar, och ser om modellen lyder dem. I praktiken är indirekt injektion den teknik som oftast ger oväntade resultat, just för att utvecklare sällan tänker på indata de inte själva matar in.

En metodisk del av testandet är att tänka i kedjor snarare än enskilda försök. En enstaka manipulerad prompt kanske inte ger mycket, men kombinerat med ett dokument som modellen läser, en behörighet den har och ett verktyg den kan anropa, kan en angripare ibland länka ihop flera till synes harmlösa steg till något allvarligt. Ett bra pentest letar därför inte bara efter enskilda hål utan efter sådana attackkedjor. Det är också därför erfarenhet spelar roll: det krävs viss kreativitet och förståelse för just den här applikationens logik för att se vilka kombinationer som är farliga, något ett rent automatiskt verktyg sällan klarar.

Här gör jag mid-vägs alltid en kartläggning av varje väg in i modellen, inklusive de indirekta. Den kartan styr testfallen. Vill ni ha den gjord ingår det i cybersäkerhetsuppdraget.

Övriga angreppsvägar i ett AI-pentest

• Åtkomst via retrieval: försök nå dokument eller data som användaren inte borde ha behörighet till, för att verifiera att åtkomstkontrollen sker före retrieval.
• Verktyg och åtgärder: om modellen kan anropa verktyg, testa om den kan förmås utföra åtgärder utanför sitt mandat.
• Output-baserade attacker: om modellens svar körs eller vidarebefordras, testa om det går att injicera skadlig output.
• Informationsläckage: försök få modellen att avslöja känslig kontext, systeminstruktioner eller annat den inte borde dela.

Manuellt testande kontra automatiska verktyg

Det finns en växande flora av automatiska verktyg för att testa LLM-applikationer, och de har sin plats, de kan snabbt köra stora mängder kända attackmönster och fånga det uppenbara. Men för AI-applikationer är det manuella, kreativa testandet fortfarande oöverträffat, eftersom de intressanta sårbarheterna ofta kräver att man förstår just den här applikationens logik och bygger en attackkedja i flera steg. Min rekommendation är att kombinera: använd automatik för bredd och baslinje, och lägg den manuella tiden där den gör störst skillnad, typiskt på indirekt prompt injection och på de ställen där modellen kan utföra åtgärder. Att enbart förlita sig på ett automatiskt verktyg ger en falsk trygghet.

Rapporten som faktiskt leder till åtgärd

Ett pentest är bara värt något om rapporten leder till handling. Jag prioriterar fynd efter faktisk risk, beskriver hur varje sårbarhet utnyttjades så att teamet kan återskapa den, och ger konkreta åtgärdsförslag. Och eftersom AI-applikationer förändras snabbt rekommenderar jag att testet kompletteras med en process för att hantera fynd löpande, det hänger ihop med en fungerande incident response-plan.

Var jag brukar börja

Börja med att kartlägga alla vägar in i modellen, särskilt de indirekta. De allvarligaste fynd jag gör i AI-pentester kommer nästan alltid via indata som utvecklarna inte tänkt på som indata, ett uppladdat dokument, en hämtad sida, ett fält som råkar nå modellen. När den kartan finns blir testet både skarpare och snabbare. Se hur jag lägger upp granskningar och tester i kundcase.

Relaterat

• DORA-förordningen för fintech: Vad CTO:n måste veta innan 2027
• Schrems II och dataöverföring till USA 2026: Status och alternativ
• SBOM med Syft + Grype: Sårbarhetshantering i CI/CD

Vill du ta det vidare?

Jag penetrationstestar AI-applikationer mot OWASP LLM Top 10 och levererar fynd som faktiskt går att åtgärda. Boka ett samtal så går vi igenom omfattning för er applikation.