Hva er LLM-sikkerhet? Slik reduserer du sikkerhetsrisikoene på OWASP Top 10

Et angrep som lurer en KI til å behandle en angripers instruksjoner som kommandoer – promptinjeksjon – har vært nr. 1 på OWASP Top 10 for LLM Applications i alle utgaver siden 2023.

Listen er omtrent så nær konsensus som man kommer innen KI-sikkerhet. Prosjektet startet som en liten gruppe sikkerhetsfolk og trekker nå på mer enn 600 bidragsytende eksperter i over 18 land.

Vi er et KI-selskap som publiserer en guide til hvordan KI kan overtales til ting, så vi skal ikke late som om dette er løst. Wilson, som er med på å lede OWASP-prosjektet, var ganske tydelig om dagens forsvarsmekanismer: «... ærlig talt tror jeg ikke vi er på 99 %.»

2026-utgaven åpner i samme toneart. Prosjektlederen ber oss «slutte å prøve å bygge en modell som ikke kan lures» og i stedet utforme systemet rundt den slik at en modell som er blitt lurt, ikke kan ødelegge noe viktig.

Vi legger det standpunktet til grunn for alle de 10 risikoene på OWASPs liste for 2026.

Hva betyr LLM-sikkerhet?

LLM-sikkerhet handler om å beskytte KI-modeller og applikasjonene som bruker dem, mot angrep og misbruk. Risikoen øker med det modellen er koblet til: filene og dataene den kan lese, og verktøyene den kan bruke, som e-post, søk eller en bedriftsdatabase.

I godt sikret programvare går det et tydelig skille mellom instruksjonene et program følger, og informasjonen det behandler. Men LLM-er har ikke det skillet.

Alt modellen leser, kommer inn som én lang tekststrøm: utviklerens instruksjoner, spørsmålet ditt, en nettside den har slått opp. KI-modeller skal holde styr på hvem som snakker, enten det er utvikleren, brukeren eller modellen selv som resonnerer seg gjennom et problem.

Men forskerne Jasmine Cui og Charles Ye fant ut at modeller stort sett gjetter hvem som snakker, ut fra hvordan teksten høres ut. Hvis en angriper skriver noe som høres ut som modellens egne resonnementer, kan modellen derfor tro at den selv kom på ideen. Det er et problem for ethvert sikkerhetsoppsett som forutsetter at modellen vet hvem som bestemmer.

Vi har støtt på det samme problemet med våre egne KI-agenter. Vår CISO, Kyle Polley, sa til ISMG at agenter «kanskje ikke følger retningslinjer selv om du legger dem inn i systemprompten». Derfor bygde vi Numbat, et verktøy med åpen kildekode som sjekker hva en agent er i ferd med å gjøre, og som kan blokkere handlingen hvis den bryter en konfigurert sikkerhetsregel.

LLM-sikkerhet betyr å akseptere at modellen noen ganger vil ta imot ordre fra feil person, og å bygge KI-sikkerhetsbarrierer rundt den som fortsatt holder når det skjer.

Hva er beste praksis for LLM-sikkerhet?

Vi går gjennom OWASP Top 10 for LLM Applications 2026 i rekkefølge, fra nr. 1 til nr. 10.

For hver risiko får du en lettfattelig forklaring på hvordan ting går galt, og et eksempel fra virkeligheten. Deretter ser vi på praksisene som kan bidra til å forhindre den, eller i det minste begrense skaden.

1. Hold promptinjeksjon i sjakk

En promptinjeksjon skjer når en angriper får en KI til å følge instruksjoner den ikke burde. Disse instruksjonene kan komme direkte i en chat eller være plantet i en e-post, en nettside eller et dokument.

Den andre typen kalles indirekte promptinjeksjon. Du ber assistenten din om å oppsummere et dokument. I dokumentet har noen bedt assistenten om å sende dem de private filene dine. Hvis assistenten følger disse instruksjonene, har personen som skrev dokumentet, i praksis lånt tilgangen din.

PCMag sammenligner promptsikkerhet med å tette hull i en porøs stein. Du tetter én åpning, og vannet finner en annen. «Et angrep finner veien gjennom; det blir fikset, men utallige andre angrepsveier gjenstår å oppdage, rett og slett fordi systemer som LLM-er er så dynamiske.»

Eksempel: I juni 2025 fant forskere i Aim Security EchoLeak, en sårbarhet som lurte Microsoft 365 Copilot til å lekke privat bedriftsinformasjon. Når en ansatt stilte et rutinemessig arbeidsspørsmål, kunne Copilot hente inn e-posten, følge instruksjonene som var skjult i den, og sende sensitiv informasjon til angriperen. Angrepet slapp forbi kontrollene som skulle fange opp ondsinnede instruksjoner og fjerne mistenkelige lenker.

Dette kan du gjøre:

• Følg Metas «Rule of Two»: EchoLeak trengte en KI som kunne lese bedriftsdata, lese ekstern e-post og sende informasjon ut – og den hadde alle tre. Å begrense den til to av disse egenskapene hindrer at en promptinjeksjon får for mye kontroll. Hvis oppgaven krever alle tre, bør du kreve menneskelig godkjenning før hver handling.
• Test mot angripere som kjenner forsvaret ditt: Gi sikkerhetstesterne dine reglene og filtrene du har innført, og la dem finne veier rundt dem. I én studie lyktes angripere som tilpasset seg forsvaret, i mer enn 90 % av tilfellene mot de fleste av de 12 forsvarsmekanismene som ble testet.

2. Hindre at sensitiv informasjon lekker ut

Når KI-systemer gir privat informasjon til personer som ikke skal se den, kalles det utlevering av sensitiv informasjon. Det kan bety å avsløre en kundes betalingsopplysninger eller å legge igjen private samtaler i en delt database.

Mange lekkasjer starter med «overdeling». La oss si at et selskap kobler KI-en sin til disker og kunnskapsbaser med løse tilgangsrettigheter. KI-en henter det den kan nå, akkurat slik den er laget for å gjøre. Ingen trenger å bryte seg inn, men du bør likevel betrakte LLM-en som kompromittert.

Eksempel: I januar 2025 fant forskere hos Wiz en DeepSeek-database som lå åpen mot internett med over en million loggoppføringer, inkludert chathistorikk og API-nøkler, som programvare bruker for å få tilgang til andre tjenester. Forskerne trengte ikke å overtale modellen til å avsløre noe.

Dette kan du gjøre:

• Sjekk tilgang før KI-en leser dataene: Applikasjonen din bør sjekke hvilke dokumenter personen som stiller spørsmålet, har lov til å se, før de sendes videre til modellen.
• Beskytt sporene KI-en etterlater seg: Fjern private opplysninger og hemmelige nøkler før aktivitetslogger lagres, krev innlogging, og begrens tilgangen til dem som trenger den. Angi en lagringsperiode slik at disse dataene ikke hoper seg opp i det uendelige.

3. Tøyle overdreven handlefrihet

KI-er med overdreven handlefrihet har mer makt enn jobben krever: verktøy de ikke trenger, tillatelser som går utover oppgaven, eller frihet til å handle uten kontroll. Årsaken er her uten betydning.

En injeksjonsprompt, en feil eller en modell som rett og slett tar feil, fører til samme resultat. KI-en vil før eller siden gjøre noe destruktivt hvis den har muligheten.

Eksempel: I juli 2025 rapporterte SaaStr-grunnlegger Jason Lemkin at Replits kodeagent hadde slettet databasen hans med 1206 lederoppføringer, til tross for instruksjoner om ikke å gjøre endringer. Agenten sa først at dataene ikke kunne gjenopprettes, men det viste seg senere at gjenoppretting var mulig. Jason fant ut at det å be den la databasen være, ikke hadde fjernet muligheten den hadde til å slette den.

Forstørr

Kilde: X

Dette kan du gjøre:

• Fjern egenskaper oppgaven ikke trenger: Begrens både hvilke verktøy en agent får, og hva disse verktøyene kan gjøre. En assistent som oppsummerer e-poster, trenger tillatelse til å lese dem, ikke til å sende eller slette dem.
• Legg tilgangskontrollene utenfor KI-en: Hver gang en handling blir forespurt, skal den kontrolleres mot sikkerhetsreglene dine, og en person må godkjenne den.

4. Kontroller hva som kommer inn i KI-forsyningskjeden din

Få selskaper lager KI fra bunnen av, og det blir færre for hvert år. Ifølge Menlo Ventures' undersøkelse The State of Generative AI in the Enterprise fra 2025 kjøpte 53 % KI-modeller i 2024, en andel som økte til 76 % i 2025.

Som oftest laster selskaper ned modeller fra plattformer som Hugging Face, trener dem videre på datasett andre har samlet inn, og kobler til tillegg og kodepakker skrevet av fremmede.

Hver av disse delene er en vei inn. Hvis én av dem blir manipulert, følger problemet med i produktet ditt.

Eksempel: Hugging Faces offentlige modellrepositorier vokste fra 2,43 millioner til 2,96 millioner mellom januar 2026 og august 2026. I juli 2026 kom imidlertid OpenAIs modeller seg rundt kontroller som skulle holde dem unna internett under intern sikkerhetstesting, og brøt seg inn i deler av Hugging Faces systemer. Én agent hentet til og med ut 14 offentlig eksponerte påloggingsopplysninger, sjekket at de fungerte, og delte dem med andre agenter. Agentene gikk deretter videre med å utnytte sårbarheter som lot dem kjøre kode på Hugging Faces servere.

«Vi stiller strengere krav til justering (alignment) gjennom hele livssyklusen til en modell og oppretter mer isolerte sandboxer, begrenser internettilgangen og kontrollerer tilgangen til modellvekter ytterligere», står det i OpenAI-rapporten.

Dette kan du gjøre:

• Lås modeller til en eksakt versjon, og verifiser dem: Lås hver modell til en gjennomgått versjon, og sjekk filens fingeravtrykk før du laster den inn, slik at en byttet fil ikke kan snike seg inn under samme merkelapp. OWASP anbefaler også digitale signaturer, med et forbehold – en signatur beviser hvor en modell kommer fra, ikke at den er trygg.
• Sjekk hver pakke KI-en foreslår: Før du installerer en kodepakke en KI-assistent har anbefalt, må du bekrefte at den finnes, at det er pakken du mente, og at den kommer fra utgiveren du forventer.

5. Beskytt mot data- og modellforgiftning

En forgiftet KI lærer av korrupte data. Det kan være eksemplene den ble finjustert på, eller en kunnskapsbase den søker i etter svar. Modellen ser fortsatt ut til å fungere; den lærer bare feil lærdommer, og noen ganger lærer den å oppføre seg feil bare når den ser en bestemt utløserfrase.

Frasen vil slippe gjennom alle testene dine helt til noen faktisk bruker den.

Forstørr

Dessuten er det svært vanskelig å reversere. Forgiftning er ikke en feil du kan rette med en oppdatering. Hvis dataene dine er feil, kan det hende du må kontrollere dem på nytt, trene modellen på nytt eller erstatte den helt.

Eksempel: I oktober 2025 viste forskere ved Anthropic, UK AI Security Institute og Alan Turing Institute at 250 forgiftede dokumenter kunne lære en modell å produsere volapyk hver gang den møtte en bestemt utløser. Det samme antallet fungerte på tvers av alle de fire modellstørrelsene som ble testet, selv om den største var trent på over 20 ganger så mye rene data.

Dette kan du gjøre:

• Spor hvor dataene dine kommer fra: Før oversikt over alle datasett og modeller du bruker, hvor hver av dem kommer fra, og hva som er endret mellom versjoner. Vi anbefaler versjonskontroll for datasett, slik at du kan rulle tilbake til en ren versjon og finne ut hvordan forgiftningen kom inn, hvis den oppdages.
• Test for bakdører: En «bakdør» er en skjult atferd som en angriper planter i en modell, og som venter på en bestemt frase eller en annen utløser for å aktiveres. Test for dette med inndata som er utformet for å få modellen til å bryte de vanlige reglene sine.

6. Sett tak på ubegrenset forbruk

Når KI-er ikke har noen grenser for hvor mye arbeid de kan utføre eller hvor mye de kan koste, regnes forbruket deres som «ubegrenset». De fleste KI-tjenester tar betalt per bruk, så en angriper kan drive opp regningen din eller bygge en kopi av modellen din.

OWASP kaller kjerneproblemet «kostnadsasymmetri». En kort, billig forespørsel kan utløse kostbare beregninger på din side.

Eksempel: I mai 2024 oppdaget Sysdigs Threat Research Team en ny angrepstype kalt «LLMjacking». En gruppe angripere gikk etter 10 skybaserte LLM-tjenester ved hjelp av stjålet påloggingsinformasjon. De kom seg inn via en sårbar versjon av Laravel, og fant deretter ut hva påloggingsinformasjonen ga tilgang til, og hvilke kvoter som gjaldt, med det åpenbare målet å selge tilgang. Mange logginnstillinger ble også undersøkt, trolig for å unngå å bli oppdaget. Ifølge Sysdig kan et verst tenkelig scenario koste offeret over 46 000 dollar om dagen.

Dette kan du gjøre:

• Sett budsjetter som stanser forbruket: Innfør harde utgiftsgrenser for enkeltbrukere, API-nøkler, team og kontoen som helhet. Håndhev dem overalt der forespørsler kan komme inn.
• Gi hver oppgave et stoppunkt: Begrens hvor lenge en oppgave kan kjøre, hvor mye tekst den kan behandle og generere, og hvor mange verktøykall den kan gjøre. Legg inn automatiske stopp for agenter som gjentar seg selv eller overskrider kvoten sin.

7. Avdekk feilinformasjon før noen handler på den

Når en KI produserer noe usant som høres riktig ut, og noen – eller noe – handler ut fra det, kalles det feilinformasjon. Kjernerisikoen er ikke så mye selve det gale svaret som at folk stoler på det gale svaret og tar det i bruk.

Hendelseshistorikken tyder på at fagfolk ikke var så bekymret for feilinformasjon som de burde ha vært. Ifølge åpningsbrevet i 2026-utgaven plasserte de som stemte, den nær bunnen, men ut fra faktiske hendelser hører den hjemme nær toppen.

Eksempel: I 2025 leverte Deloitte Australia en gjennomgang av IT-systemer for velferdsordninger under en statlig kontrakt verdt 440 000 australske dollar. University of Sydney-forskeren Chris Rudge fant henvisninger til forskning som ikke finnes, i tillegg til et oppdiktet sitat fra en dom i en føderal domstol. Den reviderte rapporten opplyste at Deloitte hadde brukt Azure OpenAI GPT-4o i metodikken sin, og firmaet gikk med på å tilbakebetale det siste avdraget. Dette var dessverre en kvalitetssikringsgjennomgang.

Dette kan du gjøre:

• Sjekk at belegget støtter svaret: Forankre påstander i oppdaterte, autoritative kilder. For et svar om retningslinjer bør du hente frem de godkjente retningslinjene og sjekke at de støtter konklusjonen, inkludert unntakene.
• Verifiser før systemet handler: Hvis en agent sier at en kunde har bestått en identitetskontroll, må du bekrefte det mot verifiseringssystemet før en betaling frigis. Krev menneskelig godkjenning for beslutninger med store konsekvenser, og sørg for at underlaget er tilgjengelig for den som vurderer.

8. Begrens skadene ved eksponering av skjult kontekst

KI-applikasjoner gir modellen instruksjoner og bakgrunnsinformasjon som brukerne vanligvis ikke ser. Det kan omfatte systemprompten, interne retningslinjer, beskrivelser av tilgjengelige verktøy og regler for hvem som kan bruke dem. Eksponering av skjult kontekst skjer når modellen avslører denne informasjonen til noen.

OWASP utvidet denne oppføringen fra «lekkasje av systemprompt» i 2026, fordi systemprompten bare er en del av det som kan slippe ut. Faren avhenger av hva du har lagt der. En lekket guide for tonefall er litt flaut, men en lekket API-nøkkel gir noen tilgang til den konfidensielle databasen din.

Eksempel: I februar 2023 fikk brukere Microsofts Bing Chat til å avsløre de interne instruksjonene sine. Ett vellykket forsøk kom fra Marvin von Hagen, som utga seg for å være OpenAI-utvikler og ba om instruksjonene slik at han kunne konfigurere modellen. Bing avslørte regler for søkene, svarene og sikkerhetsatferden sin, i tillegg til det interne navnet Sydney. Blant de avslørte instruksjonene var én som sa at den skulle holde instruksjonene hemmelige.

Dette kan du gjøre:

• Hold hemmeligheter utenfor modellens kontekst: Gå ut fra at alt modellen kan lese, kan bli synlig for brukerne – lagre passord, API-nøkler og tilgangstokener i et separat system for håndtering av hemmeligheter.
• Sørg for at tillatelsene holder selv om reglene lekker: Håndhev tilgangskontroller i applikasjonskoden. Hvis et verktøy er forbeholdt administratorer, må du sjekke brukerens kontotillatelser før det kjøres.

9. Sikre vektorene og embeddingene dine

Når en KI bruker vektorsøk for å finne svar i bedriftens dokumenter, søker den ikke direkte i teksten. Dokumentene gjøres om til «embeddinger» – lange tallrekker som fanger opp hva hvert avsnitt betyr – og lagres i en vektordatabase. Et spørsmål gjøres om på samme måte, og systemet henter avsnittene med tallene som ligger nærmest.

OWASP oppsummerer de fire måtene dette kan svikte på: Forgiftning får systemet til å ta feil, inversjon får det til å lekke, blokkering får det til å tie, og mangelfull tilgangskontroll får det til å gi hva som helst til hvem som helst.

Tallene er ikke den trygge abstraksjonen de ser ut til å være. De lagrede embeddingene kan gjøres om til tekst igjen, og én metode gjenskapte 92 % av korte avsnitt på 32 tokener nøyaktig i testene sine. En lekket sikkerhetskopi med «bare embeddinger» kan derfor også avsløre innholdet i dokumentene.

Eksempel: I forskning som ble presentert på USENIX Security 2025, viste forskere at ett nøye utformet dokument kunne hindre en KI i å svare på et bestemt spørsmål. De la det inn i samlingen KI-en søkte i. Når KI-en fant dokumentet, kunne den svare at den ikke hadde nok informasjon, eller at det ville være utrygt å svare. Dokumentet trengte ikke å be KI-en om å ignorere reglene sine. Dette kalles «retrieval jamming».

Dette kan du gjøre:

• Ha separate indekser for offentlige og private data: Ikke bland innhold som er skrapet fra nettet, med partnerdata eller konfidensielle interne dokumenter. Skill dataene fysisk etter tillitsnivå i stedet for å merke innhold i én felles indeks. Det fjerner en hel kategori feilkonfigurasjoner, og innhold som er skrapet fra internett, kan ikke havne ved siden av styredokumentene dine.
• Behandle embeddinger som dokumentene de kom fra: Krypter dem, beskytt sikkerhetskopier av vektordatabasen like godt som kildefilene, og slett embeddingene når du sletter originalen. API-nøklene til embeddingtjenesten bør holdes hemmelige.

10. Kontroller KI-utdata før du sender dem videre

Når en applikasjon sender KI-utdata videre til et annet system uten å kontrollere om de er trygge å bruke der, er det feilaktig håndtering av LLM-utdata.

Oppføringen dekker også den usikre koden som KI-kodeassistenter genererer i stor skala. Hver linje en assistent skriver, er dermed også utdata.

Eksempel: I 2025 viste forskeren Johann Rehberger hvordan Sourcegraphs kodeassistent Amp kunne lekke chatinnhold bare ved å vise et bilde. Han brukte promptinjeksjon til å få Amp til å legge privat informasjon inn i nettadressen til et bilde. Applikasjonen hentet deretter bildet automatisk og sendte dermed informasjonen til serveren hans. Feilen i utdatahåndteringen var denne automatiske forespørselen – teksten modellen genererte, ble en tilkobling til en ekstern server som tok med seg private data.

Dette kan du gjøre:

• Gjør utdataene trygge der de skal brukes: Kontroller og håndter svar ut fra hvor de skal. På en nettside må du hindre at generert tekst blir kjørbar kode. I en database bør du bruke parameteriserte spørringer som holder oppgitte verdier atskilt fra kommandoer.
• Ikke la svar opprette eksterne tilkoblinger automatisk: Deaktiver automatisk innlasting av bilder, lenkeforhåndsvisninger og innebygde sider i modellsvar som standard. Begrens nødvendige tilkoblinger til destinasjoner som er eksplisitt godkjent.

Hvordan sikrer Perplexity LLM-er?

Vi går ut fra at alle risikoene ovenfor før eller siden vil slå til, og vi designer systemene slik at de ikke kan gjøre stor skade når det skjer. Sikkerhetssjefen vår (CISO), Kyle Polley, gikk gjennom hvordan i en nylig workshop.

• Agenten får sin egen datamaskin, og den starter tom: Agentverktøy som er installert på den bærbare datamaskinen din, kan få tilgang til filene, appene og de lagrede påloggingsopplysningene på den. Perplexity Computer fungerer motsatt. Hver oppgave kjører i sin egen isolerte sandbox, og som Polley sier det: «Som standard har den ikke tilgang til noe.»
• Agenten ser aldri passordene: Påloggingsopplysningene for tilkoblede tjenester lagres utenfor sandboxen. Når agenten trenger å nå en tjeneste som GitHub, sender den en forespørsel uten påloggingsopplysninger. En gateway kontrollerer at destinasjonen og forespørselen er som forventet, og legger deretter til påloggingsopplysningene på vei ut. Agenten kan bruke tilkoblingen uten å få nøklene.
• Tillatelsene dine følger med, og du kan stramme dem inn: Tilkoblinger som opprettes via OAuth, bevarer tilgangstillatelsene dine i den tilkoblede tjenesten. Hvis du ikke kan se noe, kan ikke agenten din det heller.
• Hver nettside behandles som en fremmed: Vi bygde BrowseSafe for Comet, den agentiske nettleseren vår, fordi verktøyene vi testet, ikke dekket behovene våre i praktisk bruk. Nettleseren skanner nettsider og annet eksternt innhold, inkludert e-post, etter promptinjeksjon. Vi har gjort både modellen og datasettet tilgjengelige som åpen kildekode.
• Vi overvåker agenten og maskinene den kjører på: Numbat ligger mellom det øyeblikket en agent bestemmer seg for å handle, og det øyeblikket verktøyet faktisk kjører. Numbat logger aktivitet på tvers av støttede kodeagenter og kan blokkere handlinger som bryter med konfigurerte retningslinjer, før de utføres. Bumblebee kartlegger programvarepakker på bærbare datamaskiner, servere og byggepipelines og markerer pakker som er kjent som ondsinnede. Begge er åpen kildekode.
• Modelleverandørene beholder ikke dataene dine: Vi har avtaler om null datalagring med våre eksterne LLM-leverandører. Enterprise-administratorer kan også sette Perplexitys egen lagringstid for data ned til 24 timer.

Vi bygde Numbat proaktivt, av en grunn Polley oppsummerer i én setning: «Jo mer autonomi du gir en agent, desto større er risikoen.»

Vanlige spørsmål om LLM-sikkerhet

Hva er den sikreste LLM-en?

Ingen LLM gjør en applikasjon sikker på egen hånd – modeller kan fortsatt forveksle innhold de skal lese, med instruksjoner de skal følge. Forsvar som virker sterke i standardtester, kan også svikte under press.

Et bedre spørsmål er hvilket oppsett som er sikrest for ditt bruksområde. Det betyr begrensede tillatelser, påloggingsopplysninger som holdes unna modellen, menneskelig godkjenning av risikable handlinger og testing utført av folk som kjenner forsvarene dine.

Hva er LLM-sårbarheter?

LLM-sårbarheter er svakheter som gjør at et KI-system kan lures, lekke data eller forårsake skade, enten på grunn av en angriper eller sine egne feil.

De ti største risikoene er promptinjeksjon, avsløring av sensitiv informasjon, overdreven handlefrihet, forsyningskjeden, forgiftning av data og modeller, ubegrenset ressursforbruk, feilinformasjon, eksponering av skjult kontekst, svakheter i vektorer og embeddinger samt feilaktig håndtering av utdata.

Er private LLM-er trygge?

De er et tryggere alternativ for enkelte formål, men ikke automatisk. Du har mer kontroll over datahåndteringen hvis du kjører en modell på din egen infrastruktur eller i et skymiljø. Men det finnes ingen automatisk beskyttelse mot promptinjeksjon, overdreven handlefrihet, forgiftning eller feilinformasjon.

Når du hoster selv, er du også ansvarlig for modellen du laster ned, inkludert risikoene i forsyningskjeden og infrastrukturen den krever.