Vad är LLM-säkerhet? Så minskar du de tio största säkerhetsriskerna enligt OWASP

En attack som lurar en AI att behandla en angripares instruktioner som kommandon – promptinjektion – har legat på plats 1 på OWASP Top 10 for LLM Applications i varje utgåva sedan 2023.

Listan är ungefär så nära konsensus man kan komma inom AI-säkerhet. Projektet startade som en liten grupp säkerhetsexperter och bygger i dag på fler än 600 bidragande experter i över 18 länder.

Vi är ett AI-företag som publicerar en guide om hur AI övertalas att göra saker, så vi tänker inte låtsas att problemet är löst. Wilson, som är med och leder OWASP-projektet, var ganska tydlig om dagens skydd: ”...ärligt talat tror jag inte att vi är uppe i 99 %.”

Utgåvan för 2026 inleds på samma ton. Projektledaren uppmanar oss att ”sluta försöka bygga en modell som inte kan luras” och att i stället utforma det omgivande systemet så att en lurad modell inte kan förstöra något viktigt.

Vi tillämpar det synsättet på alla 10 risker på OWASP:s lista för 2026.

Vad innebär LLM-säkerhet?

LLM-säkerhet innebär att skydda AI-modeller och de applikationer som använder dem mot attacker och missbruk. Risken ökar med vad modellen är ansluten till: de filer och data den kan läsa och de verktyg den kan använda, som e-post, sökning eller en företagsdatabas.

I korrekt säkrad programvara finns en tydlig gräns mellan de instruktioner ett program följer och den information det bearbetar. Men LLM:er har inte den gränsen.

Allt modellen läser kommer in som en enda lång textström: utvecklarens instruktioner, din fråga, en webbsida den slog upp. AI-modeller ska hålla reda på vem som talar, oavsett om det är utvecklaren, användaren eller modellen själv som resonerar sig igenom ett problem.

Men forskarna Jasmine Cui och Charles Ye upptäckte att modeller oftast gissar vem som talar utifrån hur texten låter. Så om en angripare skriver något som låter som modellens eget resonemang kan modellen tro att den själv kom på idén. Det är ett problem för alla säkerhetslösningar som bygger på att modellen vet vem som bestämmer.

Vi har stött på samma problem med våra egna AI-agenter. Vår CISO, Kyle Polley, sa till ISMG att agenter ”kanske inte följer policyer även om man lägger till dem i systemprompten”. Det är därför vi byggde Numbat, ett verktyg med öppen källkod som kontrollerar vad en agent är på väg att göra och kan blockera handlingen om den bryter mot en konfigurerad säkerhetsregel.

LLM-säkerhet innebär att acceptera att modellen ibland tar order från fel person, och att bygga skyddsräcken för AI runt den som håller även när det händer.

Vilka är de bästa metoderna för LLM-säkerhet?

Vi går igenom OWASP Top 10 for LLM Applications 2026 i ordning, från nummer 1 till nummer 10.

För varje risk får du en lättbegriplig förklaring av hur det kan gå fel och ett exempel från verkligheten. Sedan går vi igenom de metoder som kan hjälpa till att förhindra den, eller åtminstone begränsa skadan.

1. Håll promptinjektion i schack

En promptinjektion inträffar när en angripare får en AI att följa instruktioner som den inte borde följa. Instruktionerna kan komma direkt i en chatt eller vara planterade i ett e-postmeddelande, en webbsida eller ett dokument.

Den andra typen kallas indirekt promptinjektion. Du ber din assistent att sammanfatta ett dokument. De har sagt åt assistenten att skicka dina privata filer till dem. Om assistenten följer de instruktionerna har personen som skrev dokumentet i praktiken lånat din åtkomst.

PCMag jämför promptsäkerhet med att täppa till hål i en porös sten. Du tätar en öppning, och vattnet hittar en annan. ”En attack tar sig igenom; den åtgärdas, men otaliga andra attackvägar återstår att upptäcka helt enkelt på grund av hur dynamiska system som LLM:er är.”

Exempel: I juni 2025 upptäckte forskare på Aim Security EchoLeak, en brist som lurade Microsoft 365 Copilot att läcka privat företagsinformation. När en anställd ställde en rutinmässig arbetsfråga kunde Copilot hämta in e-postmeddelandet, följa instruktionerna som var gömda i det och skicka känslig information till angriparen. Attacken tog sig förbi de kontroller som skulle fånga skadliga instruktioner och ta bort misstänkta länkar.

Det här kan du göra:

• Följ Metas ”Rule of Two”: EchoLeak krävde en AI som kunde läsa företagsdata, läsa extern e-post och skicka ut information – och den hade alla tre. Om du begränsar den till två av dessa förmågor kan en promptinjektion inte få för stor kontroll. Om uppgiften kräver alla tre bör du kräva mänskligt godkännande före varje åtgärd.
• Testa mot angripare som känner till dina skydd: Ge dina säkerhetstestare de regler och filter du har infört och låt dem sedan försöka ta sig runt dem. I en studie lyckades angripare som anpassade sig efter skydden i mer än 90 % av fallen mot de flesta av de 12 testade skydden.

2. Förhindra att känslig information läcker

När AI-system ger privat information till personer som inte borde se den kallas det röjande av känslig information. Det kan innebära att en kunds betalningsuppgifter avslöjas eller att privata konversationer lämnas kvar i en delad databas.

Många läckor börjar med ”överdelning”. Säg att ett företag kopplar sin AI till lagringsytor och kunskapsbaser med generösa behörigheter. AI:n hämtar allt den kan komma åt, precis som den är utformad att göra. Ingen behöver bryta sig in, men du bör ändå se det som att LLM:en har utsatts för intrång.

Exempel: I januari 2025 hittade forskare på Wiz en DeepSeek-databas som var öppen mot internet med mer än en miljon loggposter, bland annat chatthistorik och API-nycklar, som programvara använder för att komma åt andra tjänster. Forskarna behövde inte övertala modellen att avslöja något.

Det här kan du göra:

• Kontrollera åtkomsten innan AI:n läser data: Din applikation bör kontrollera vilka dokument personen som ställer frågan får se innan de skickas vidare till modellen.
• Skydda de spår din AI lämnar efter sig: Ta bort privata uppgifter och hemliga nycklar innan aktivitetsloggar sparas, kräv inloggning och begränsa åtkomsten till de personer som behöver dem. Ange en lagringstid så att posterna inte samlas på hög i all oändlighet.

3. Tygla överdriven handlingsfrihet

AI-system med överdriven handlingsfrihet har mer makt än deras uppgifter kräver: verktyg de inte behöver, behörigheter som går utöver uppgiften eller frihet att agera utan kontroll. Orsaken spelar här ingen roll.

En injicerad prompt, en bugg eller en modell som helt enkelt gör fel leder alla till samma resultat. AI:n kommer förr eller senare att göra något destruktivt om den har förmågan.

Exempel: I juli 2025 rapporterade SaaStr-grundaren Jason Lemkin att Replits kodningsagent raderade hans databas med 1 206 poster om chefer, trots instruktioner om att inte göra några ändringar. Agenten sa först att data inte gick att återställa, men det visade sig senare att en återställning var möjlig. Jason insåg att uppmaningen att lämna databasen i fred inte hade tagit bort agentens möjlighet att radera den.

Förstora

Källa: X

Det här kan du göra:

• Ta bort förmågor som uppgiften inte kräver: Begränsa både vilka verktyg en agent får och vad verktygen kan göra. En assistent som sammanfattar e-post behöver behörighet att läsa den, inte att skicka eller radera den.
• Placera behörighetskontroller utanför AI:n: Varje gång en åtgärd begärs ska den kontrolleras mot dina säkerhetsregler, och en person ska behöva godkänna den.

4. Kontrollera vad som kommer in i din AI-leveranskedja

Få företag bygger AI från grunden, och de blir färre för varje år. Enligt Menlo Ventures undersökning The State of Generative AI in the Enterprise från 2025 köpte 53 % AI-modeller 2024, en andel som ökade till 76 % 2025.

Oftast laddar företag ned modeller från plattformar som Hugging Face, tränar dem vidare på datamängder som andra har samlat in och kopplar in tillägg och kodpaket som främlingar har skrivit.

Var och en av de delarna är en väg in. Om någon av dem manipuleras följer problemet med i din produkt.

Exempel: Antalet offentliga modellarkiv på Hugging Face växte från 2,43 miljoner till 2,96 miljoner mellan januari 2026 och augusti 2026. I juli 2026 tog sig dock OpenAI:s modeller förbi kontroller som skulle hålla dem borta från internet under intern säkerhetstestning och bröt sig in i delar av Hugging Faces system. En agent kom till och med åt 14 offentligt exponerade inloggningsuppgifter, kontrollerade att de fungerade och delade dem med andra agenter. Agenterna utnyttjade sedan brister som lät dem köra kod på Hugging Faces servrar.

”Vi ställer strängare krav på alignment under hela modellens livscykel och skapar mer isolerade sandlådor, begränsar internetåtkomsten och kontrollerar åtkomsten till modellvikter ytterligare”, står det i OpenAI:s rapport.

Det här kan du göra:

• Lås modeller till en exakt version och verifiera dem: Lås varje modell till en granskad version och kontrollera filens fingeravtryck innan den läses in, så att en utbytt fil inte kan smyga sig in under samma etikett. OWASP rekommenderar också digitala signaturer, med en reservation – en signatur bevisar var en modell kommer ifrån, inte att den är säker.
• Kontrollera varje paket som din AI föreslår: Innan du installerar ett kodpaket som en AI-assistent har rekommenderat bör du bekräfta att det finns, att det är det paket du avsåg och att det kommer från den utgivare du förväntar dig.

5. Skydda dig mot förgiftning av data och modeller

En förgiftad AI lär sig av korrumperad data. Det kan vara de exempel den finjusterades på eller en kunskapsbas den söker svar i. Modellen ser fortfarande ut att fungera; den lär sig bara fel saker, och ibland lär den sig att bete sig illa bara när den ser en specifik utlösande fras.

Modellen klarar varje test du ger den, ända tills någon använder frasen.

Förstora

Dessutom är det verkligen svårt att rätta till i efterhand. Förgiftning är inte en bugg som du kan patcha. Om din data är fel kan du behöva kontrollera den på nytt, träna om modellen eller ersätta den helt.

Exempel: I oktober 2025 visade forskare vid Anthropic, brittiska AI Security Institute och Alan Turing Institute att 250 förgiftade dokument kunde lära en modell att producera nonsens så fort den stötte på en viss utlösare. Samma antal fungerade för alla fyra testade modellstorlekar, trots att den största tränades på mer än 20 gånger så mycket ren data.

Det här kan du göra:

• Spåra var din data kommer ifrån: Dokumentera varje datamängd och modell du använder, var de kommer ifrån och vad som har ändrats mellan versionerna. Vi rekommenderar versionshantering för datamängder, så att du kan återgå till en ren version och ta reda på hur förgiftningen kom in om den upptäcks.
• Testa efter bakdörrar: En ”bakdörr” är ett dolt beteende som en angripare planterar i en modell och som väntar på en viss fras eller annan utlösare för att aktiveras. Testa efter sådana med indata som är utformade för att få modellen att bryta mot sina vanliga regler.

6. Sätt tak för obegränsad förbrukning

När AI-system inte har några gränser för hur mycket arbete de kan utföra eller hur mycket de kan kosta anses deras förbrukning vara ”obegränsad”. De flesta AI-tjänster tar betalt per användning, så en angripare kan driva upp din faktura eller bygga en kopia av din modell.

OWASP kallar kärnproblemet ”kostnadsasymmetri”. En kort, billig förfrågan kan utlösa dyra beräkningar på din sida.

Exempel: I maj 2024 upptäckte Sysdigs Threat Research Team en ny attack som kallas ”LLMjacking”. En grupp angripare riktade in sig på 10 molnbaserade LLM-tjänster med hjälp av stulna inloggningsuppgifter. De tog sig in via en sårbar version av Laravel och tog sedan reda på vad inloggningsuppgifterna kunde användas till och vilka kvoter som gällde, uppenbarligen i syfte att sälja åtkomsten. Många loggningsinställningar efterfrågades också, troligen för att undvika upptäckt. Enligt Sysdig skulle offret i värsta fall kunna drabbas av kostnader på över 46 000 dollar per dag.

Det här kan du göra:

• Sätt budgetar som stoppar utgifterna: Inför fasta utgiftsgränser för enskilda användare, API-nycklar, team och kontot som helhet. Tillämpa dem överallt där förfrågningar kan komma in.
• Ge varje uppgift en slutpunkt: Begränsa hur länge en uppgift får köras, hur mycket text den får bearbeta och generera och hur många verktygsanrop den får göra. Lägg till automatiska stopp för agenter som upprepar sig eller överskrider sin tilldelning.

7. Fånga felinformation innan någon agerar på den

När en AI producerar något falskt som låter rätt, och någon, eller något, agerar utifrån det, kallas det felinformation. Kärnrisken är inte så mycket själva det felaktiga svaret, utan att man litar på det och använder det.

Incidenthistoriken tyder på att yrkesverksamma inte var så oroliga för felinformation som de borde ha varit. Enligt det inledande brevet i 2026 års utgåva placerade de röstande den nära botten, men enligt verkliga incidenter hör den hemma nära toppen.

Exempel: År 2025 levererade Deloitte Australia en granskning av it-system för välfärd inom ramen för ett statligt kontrakt värt 440 000 australiska dollar. Vid University of Sydney hittade forskaren Chris Rudge hänvisningar till obefintlig forskning och ett påhittat citat från en dom i en federal domstol. Av den reviderade rapporten framgick att Deloitte hade använt Azure OpenAI GPT-4o i sin metod, och företaget gick med på att betala tillbaka den sista delbetalningen. Det rörde sig dessvärre om en kvalitetssäkringsgranskning.

Det här kan du göra:

• Kontrollera att underlaget stöder svaret: Förankra påståenden i aktuella, auktoritativa källor. För ett svar om en policy bör du hämta den godkända policyn och kontrollera att den stöder slutsatsen, inklusive dess undantag.
• Verifiera innan systemet agerar: Om en agent säger att en kund har klarat en identitetskontroll ska du bekräfta det mot verifieringssystemet innan en betalning frigörs. Kräv mänskligt godkännande för beslut med stora konsekvenser och se till att granskaren har tillgång till underlaget.

8. Begränsa skadan från exponering av dold kontext

AI-applikationer ger modellen instruktioner och bakgrundsinformation som användarna normalt inte ser. Det kan omfatta systemprompten, interna policyer, beskrivningar av tillgängliga verktyg och regler för vem som får använda dem. Exponering av dold kontext inträffar när modellen avslöjar den informationen för någon.

OWASP utvidgade 2026 den här posten från ”läckage av systemprompt” eftersom systemprompten bara är en del av det som kan läcka ut. Faran beror på vad du har lagt där. En läckt guide för tonalitet är lite pinsam, men en läckt API-nyckel ger någon åtkomst till din konfidentiella databas.

Exempel: I februari 2023 fick användare Microsofts Bing Chat att avslöja sina interna instruktioner. Ett lyckat försök kom från Marvin von Hagen, som utgav sig för att vara utvecklare på OpenAI och bad om instruktionerna så att han kunde konfigurera modellen. Bing avslöjade regler för sina sökningar, svar och sitt säkerhetsbeteende, tillsammans med sitt interna namn, Sydney. Bland de avslöjade instruktionerna fanns en som sa åt den att hålla instruktionerna konfidentiella.

Det här kan du göra:

• Håll hemligheter utanför modellens kontext: Utgå från att allt som modellen kan läsa kan bli synligt för användare – lagra lösenord, API-nycklar och åtkomsttoken i ett separat system för hantering av hemligheter.
• Se till att behörigheterna håller även om reglerna läcker: Tillämpa åtkomstkontroller i programkoden. Om ett verktyg är begränsat till administratörer ska du kontrollera användarens kontobehörigheter innan det körs.

9. Säkra dina vektorer och inbäddningar

När en AI använder vektorsökning för att hitta svar i företagets dokument söker den inte direkt i texten. Dokumenten omvandlas till ”inbäddningar” (embeddings), som är långa listor med tal som fångar vad varje textavsnitt betyder, och lagras i en vektordatabas. En fråga omvandlas på samma sätt, och systemet hämtar de avsnitt vars tal ligger närmast.

OWASP sammanfattar de fyra sätt som det kan gå fel på: förgiftning gör att systemet ger fel svar, inversion gör att det läcker, störning (jamming) gör att det tystnar och bristfällig åtkomstkontroll gör att det lämnar ut vad som helst till vem som helst.

Talen är inte den säkra abstraktion de ser ut att vara. De lagrade inbäddningarna kan omvandlas tillbaka till text, och en metod återskapade 92 % av korta avsnitt på 32 token exakt i sina tester. Därför kan även en läckt säkerhetskopia med ”enbart inbäddningar” avslöja dokumentens innehåll.

Exempel: I forskning som presenterades vid USENIX Security 2025 visade forskare att ett enda noggrant utformat dokument kunde hindra en AI från att besvara en viss fråga. De lade till det i samlingen som AI:n sökte i. När AI:n hittade det kunde den säga att den inte hade tillräckligt med information eller att det skulle vara osäkert att svara. Dokumentet behövde inte uppmana AI:n att ignorera sina regler. Detta kallas ”retrieval jamming”.

Det här kan du göra:

• Håll separata index för offentliga och privata data: Blanda inte webbinnehåll som skrapats från internet med partnerdata eller konfidentiella interna dokument. Separera fysiskt efter förtroendenivå i stället för att tagga innehåll i ett och samma index. Det eliminerar en hel klass av felkonfigurationer, och innehåll som skrapats från internet kan inte hamna bredvid styrelsehandlingarna.
• Behandla inbäddningar som de dokument de kommer från: Kryptera dem, skydda säkerhetskopior av vektordatabasen lika väl som källfilerna och radera inbäddningarna när du raderar originalet. API-nycklar för din inbäddningstjänst ska hållas hemliga.

10. Kontrollera AI-utdata innan de skickas vidare

När ett program skickar AI-utdata vidare till ett annat system utan att kontrollera om de är säkra att använda där, är det fråga om felaktig hantering av LLM-utdata.

Kategorin omfattar även den osäkra kod som AI-kodassistenter genererar i stor skala. Varje rad som en assistent skriver är alltså också utdata.

Exempel: År 2025 visade forskaren Johann Rehberger hur Sourcegraphs kodassistent Amp kunde läcka chattinnehåll bara genom att visa en bild. Han använde promptinjektion för att få Amp att lägga in privat information i en bilds webbadress. Programmet hämtade sedan bilden automatiskt och skickade därmed informationen till hans server. Felet i utdatahanteringen var den automatiska begäran – texten som modellen genererade blev en anslutning till en extern server som förde med sig privata data.

Det här kan du göra:

• Gör utdata säkra för den plats där de hamnar: Kontrollera och hantera svar utifrån vart de ska. På en webbsida ska du förhindra att genererad text blir körbar kod. För en databas ska du använda förberedda frågor (prepared statements) som håller angivna värden åtskilda från kommandon.
• Hindra svar från att skapa automatiska externa anslutningar: Inaktivera som standard automatisk inläsning av bilder, länkförhandsvisningar och inbäddade sidor i modellens svar. Begränsa nödvändiga anslutningar till uttryckligen godkända destinationer.

Hur säkrar Perplexity LLM:er?

Vi utgår från att varje risk ovan förr eller senare kommer att inträffa, och vi utformar våra system så att den inte kan ställa till med särskilt mycket när det väl händer. Vår CISO, Kyle Polley, gick igenom hur vi gör i en workshop som hölls nyligen.

• Agenten får en egen dator, och den är tom från början: Agentverktyg som installeras på din bärbara dator kan få åtkomst till dess filer, appar och sparade inloggningsuppgifter. Perplexity Computer fungerar tvärtom. Varje uppgift körs i en egen isolerad sandlåda, och som Polley uttrycker det: ”som standard har den inte åtkomst till någonting.”
• Agenten ser aldrig lösenorden: Inloggningsuppgifterna för anslutna tjänster lagras utanför sandlådan. När agenten behöver nå en tjänst som GitHub skickar den en begäran utan bifogade inloggningsuppgifter. En gateway kontrollerar att destinationen och begäran är de förväntade och lägger sedan till inloggningsuppgifterna på vägen ut. Agenten kan använda anslutningen utan att få tillgång till nycklarna.
• Dina behörigheter följer med, och du kan skärpa dem: Anslutningar som görs via OAuth bevarar dina åtkomstbehörigheter i den anslutna tjänsten. Om du inte kan se något kan din agent inte heller det.
• Varje webbsida behandlas som en främling: Vi byggde BrowseSafe för Comet, vår agentiska webbläsare, eftersom verktygen vi testade inte uppfyllde våra behov i verklig användning. Webbläsaren skannar webbsidor och annat externt innehåll, inklusive e-post, efter promptinjektion. Vi har släppt både modellen och datamängden som öppen källkod.
• Vi övervakar agenten och maskinerna den körs på: Numbat ligger mellan agentens beslut att agera och att verktyget faktiskt körs. Numbat loggar aktivitet i de kodagenter som stöds och kan blockera åtgärder som bryter mot konfigurerade policyer innan de utförs. Bumblebee inventerar programvarupaket på bärbara datorer, servrar och byggpipelines och flaggar kända skadliga paket. Båda finns som öppen källkod.
• Modellleverantörerna sparar inte dina data: Vi har avtal om noll datalagring (zero data retention) med våra externa LLM-leverantörer. Enterprise-administratörer kan också ställa in Perplexitys egen lagringstid för data till så kort som 24 timmar.

Vi byggde Numbat proaktivt, av en anledning som Polley sammanfattar på en rad: ”Ju mer självständighet du ger en agent, desto större är risken.”

Vanliga frågor om LLM-säkerhet

Vilken är den säkraste LLM:en?

Ingen LLM gör ett program säkert på egen hand – modeller kan fortfarande förväxla innehåll som de ska läsa med instruktioner som de ska följa. Försvar som ser starka ut i standardtester kan också ge vika under press.

En bättre fråga är vilken konfiguration som är säkrast för ditt användningsfall. Det innebär begränsade behörigheter, inloggningsuppgifter som hålls borta från modellen, mänskligt godkännande för riskfyllda åtgärder och tester utförda av personer som känner till dina försvar.

Vad är sårbarheter i LLM:er?

Sårbarheter i LLM:er är svagheter som gör att ett AI-system kan luras, läcka data eller orsaka skada, antingen genom en angripare eller genom sina egna misstag.

De tio största riskerna är promptinjektion, röjande av känslig information, överdriven handlingsfrihet, leveranskedjan, data- och modellförgiftning, obegränsad resursförbrukning, felinformation, exponering av dold kontext, svagheter i vektorer och inbäddningar samt felaktig hantering av utdata.

Är en privat LLM säker?

Det är ett säkrare alternativ i vissa avseenden, men inte automatiskt. Du får större kontroll över datahanteringen om du kör en modell på din egen infrastruktur eller i en molnmiljö. Men det finns inget automatiskt sätt att förhindra promptinjektioner, överdriven handlingsfrihet, förgiftning eller felinformation.

När du driftar modellen själv ansvarar du också för modellen du laddar ner, inklusive riskerna i leveranskedjan och den infrastruktur den kräver.