Hvad er LLM-sikkerhed? Sådan afbøder du OWASP Top 10-sikkerhedsrisiciene

Et angreb, der narrer en AI til at behandle en angribers instruktioner som kommandoer – promptinjektion – har været nr. 1 på OWASP Top 10 for LLM Applications i hver eneste udgave siden 2023.

Listen er nok det tætteste, AI-sikkerhed kommer på konsensus. Projektet startede som en lille gruppe sikkerhedsfolk og trækker nu på mere end 600 bidragende eksperter i over 18 lande.

Vi er en AI-virksomhed, der udgiver en guide til, hvordan AI lader sig overtale til ting, så vi vil ikke lade, som om problemet er løst. Wilson, der er medleder af OWASP-projektet, var ret klar i mælet om de nuværende forsvarsmekanismer: ”… ærligt talt tror jeg ikke, vi er på 99 %.”

2026-udgaven lægger ud i samme toneart. Projektlederen opfordrer os til at ”holde op med at forsøge at bygge en model, der ikke kan narres”, og i stedet designe det omgivende system, så en narret model ikke kan ødelægge noget vigtigt.

Vi holder fast i det standpunkt gennem alle 10 risici på OWASP's liste for 2026.

Hvad betyder LLM-sikkerhed?

LLM-sikkerhed handler om at beskytte AI-modeller og de applikationer, der bruger dem, mod angreb og misbrug. Risikoen vokser med det, modellen er forbundet til: de filer og data, den kan læse, og de værktøjer, den kan bruge, f.eks. e-mail, søgning eller en virksomhedsdatabase.

I korrekt sikret software er der en skarp grænse mellem de instruktioner, et program følger, og de oplysninger, det behandler. Men LLM’er har ikke den grænse.

Alt, hvad modellen læser, kommer som én lang strøm af tekst: udviklerens instruktioner, dit spørgsmål, en webside, den har slået op. AI-modeller skal holde styr på, hvem der taler – om det er udvikleren, brugeren eller modellen selv, der tænker et problem igennem.

Men forskerne Jasmine Cui og Charles Ye fandt ud af, at modeller for det meste gætter, hvem der taler, ud fra, hvordan teksten lyder. Så hvis en angriber skriver noget, der lyder som modellens eget ræsonnement, kan modellen tro, at den selv har fået idéen. Det er et problem for enhver sikkerhedsopsætning, der afhænger af, at modellen ved, hvem der bestemmer.

Vi er selv stødt på det samme problem med vores egne AI-agenter. Vores CISO, Kyle Polley, fortalte ISMG, at agenter ”måske ikke følger politikker, selv hvis man tilføjer dem til systemprompten”. Derfor byggede vi Numbat, et open source-værktøj, der tjekker, hvad en agent er ved at gøre, og kan blokere handlingen, hvis den bryder en konfigureret sikkerhedsregel.

LLM-sikkerhed betyder at acceptere, at modellen nogle gange vil tage imod ordrer fra den forkerte person, og at bygge AI-guardrails omkring den, som stadig holder, når det sker.

Hvad er bedste praksis for LLM-sikkerhed?

Vi gennemgår OWASP Top 10 for LLM Applications 2026 i rækkefølge, fra nr. 1 til nr. 10.

For hver risiko får du en letforståelig forklaring på, hvordan det går galt, og et eksempel fra virkeligheden. Derefter gennemgår vi de metoder, der kan hjælpe med at forhindre det – eller i det mindste begrænse skaden.

1. Inddæm promptinjektion

En promptinjektion sker, når en angriber får en AI til at følge instruktioner, den ikke burde følge. Instruktionerne kan komme direkte i en chat eller være plantet i en e-mail, en webside eller et dokument.

Den anden type kaldes indirekte promptinjektion. Du beder din assistent om at opsummere et dokument. Dokumentets forfatter har bedt assistenten om at sende dine private filer til dem. Hvis assistenten følger de instruktioner, har den person, der skrev dokumentet, reelt lånt din adgang.

PCMag sammenligner promptsikkerhed med at lappe huller i en porøs sten. Man tætner én åbning, og vandet finder en anden. ”Et angreb finder vej igennem; det bliver rettet, men utallige andre angrebsveje venter stadig på at blive opdaget, simpelthen fordi systemer som LLM’er er så dynamiske.”

Eksempel: I juni 2025 fandt forskere fra Aim Security EchoLeak, en sårbarhed, der narrede Microsoft 365 Copilot til at lække private virksomhedsoplysninger. Når en medarbejder stillede et rutinemæssigt arbejdsspørgsmål, kunne Copilot hente e-mailen ind, følge de instruktioner, der var skjult i den, og sende følsomme oplysninger til angriberen. Angrebet slap forbi de kontroller, der skulle fange ondsindede instruktioner og fjerne mistænkelige links.

Det kan du gøre:

• Følg Metas ”Rule of Two”: EchoLeak krævede en AI, der kunne læse virksomhedsdata, læse ekstern e-mail og sende oplysninger ud – og den havde alle tre egenskaber. Hvis du begrænser den til to af disse egenskaber, forhindrer du, at en promptinjektion får for meget kontrol. Hvis opgaven kræver alle tre, så kræv menneskelig godkendelse før hver handling.
• Test mod angribere, der kender dit forsvar: Giv dine sikkerhedstestere de regler og filtre, du har indført, og lad dem finde veje udenom. I én undersøgelse lykkedes det angribere, der tilpassede sig forsvaret, i mere end 90 % af tilfældene mod de fleste af de 12 testede forsvarsmekanismer.

2. Forhindr, at følsomme oplysninger lækker

Når AI-systemer giver private oplysninger til personer, der ikke burde se dem, kaldes det videregivelse af følsomme oplysninger. Det kan betyde, at en kundes betalingsoplysninger bliver afsløret, eller at private samtaler ligger frit fremme i en delt database.

Mange læk starter med ”overdeling”. Lad os sige, at en virksomhed forbinder sin AI med drev og videnbaser med løse tilladelser. AI’en henter alt, hvad den kan nå, præcis som den er designet til. Ingen behøver at bryde ind, men betragt alligevel LLM’en som kompromitteret.

Eksempel: I januar 2025 fandt forskere fra Wiz en DeepSeek-database, der lå åben på internettet med mere end en million logposter, herunder chathistorik og API-nøgler, som software bruger til at få adgang til andre tjenester. Forskerne behøvede ikke at overtale modellen til at afsløre noget.

Det kan du gøre:

• Tjek adgang, før AI’en læser dataene: Din applikation bør tjekke, hvilke dokumenter den person, der stiller spørgsmålet, har lov til at se, før de sendes videre til modellen.
• Beskyt de spor, din AI efterlader: Fjern private oplysninger og hemmelige nøgler, før aktivitetslogs gemmes, kræv login, og begræns adgangen til de personer, der har brug for dem. Fastsæt en opbevaringsperiode, så logfilerne ikke hober sig op i det uendelige.

3. Tøjl overdreven handlefrihed

AI’er med overdreven handlefrihed har mere magt, end deres opgaver kræver: værktøjer, de ikke har brug for, tilladelser, der rækker ud over opgaven, eller frihed til at handle uden at tjekke først. Årsagen er her irrelevant.

En injiceret prompt, en fejl eller en model, der simpelthen tager fejl, fører alle til samme resultat. AI’en vil før eller siden gøre noget destruktivt, hvis den har muligheden for det.

Eksempel: I juli 2025 rapporterede SaaStr-grundlægger Jason Lemkin, at Replits kodeagent slettede hans database med 1.206 poster om ledere, selvom den havde fået besked på ikke at foretage ændringer. Agenten sagde først, at dataene ikke kunne gendannes, men det viste sig senere at være muligt. Jason måtte sande, at agenten stadig kunne slette databasen, selvom han havde bedt den om at lade den være.

Udvid

Kilde: X

Det kan du gøre:

• Fjern funktioner, som opgaven ikke kræver: Begræns både de værktøjer, en agent får, og hvad de værktøjer kan gøre. En assistent, der opsummerer e-mails, skal have tilladelse til at læse dem – ikke til at sende eller slette dem.
• Placer tilladelseskontroller uden for AI’en: Hver gang der anmodes om en handling, skal den kontrolleres mod dine sikkerhedsregler, og en person skal godkende den.

4. Tjek, hvad der kommer ind i din AI-forsyningskæde

Få virksomheder bygger AI fra bunden, og der bliver færre for hvert år. Ifølge Menlo Ventures' undersøgelse The State of Generative AI in the Enterprise fra 2025 købte 53 % AI-modeller i 2024, og det tal steg til 76 % i 2025.

Oftere end ikke downloader virksomheder modeller fra hubs som Hugging Face, træner dem videre på datasæt, som andre har indsamlet, og tilføjer udvidelser og kodepakker skrevet af fremmede.

Hver af disse dele er en indgang. Hvis én af dem er manipuleret, følger problemet med ud i dit produkt.

Eksempel: Hugging Faces offentlige modelrepositorier voksede fra 2,43 millioner til 2,96 millioner mellem januar 2026 og august 2026. I juli 2026 kom OpenAIs modeller dog uden om de kontroller, der skulle holde dem væk fra internettet under intern sikkerhedstestning, og brød ind i dele af Hugging Faces systemer. Én agent fandt endda 14 offentligt eksponerede adgangsoplysninger, tjekkede, at de virkede, og delte dem med andre agenter. Agenterne udnyttede derefter sårbarheder, der gjorde det muligt for dem at køre kode på Hugging Faces servere.

”Vi stiller strengere krav til alignment gennem hele en models livscyklus og skaber mere isolerede sandboxmiljøer, begrænser internetadgangen og kontrollerer adgangen til modelvægte yderligere,” står der i OpenAI-rapporten.

Det kan du gøre:

• Fastlås modeller til en bestemt version, og verificer dem: Fastlås hver model til en gennemgået version, og tjek dens filfingeraftryk, før den indlæses, så en ombyttet fil ikke kan snige sig ind under samme betegnelse. OWASP anbefaler også digitale signaturer, dog med et forbehold: En signatur beviser, hvor en model kommer fra, men ikke, at den er sikker.
• Tjek hver pakke, din AI foreslår: Før du installerer en kodepakke, som en AI-assistent har anbefalet, skal du bekræfte, at den findes, at det er den pakke, du mente, og at den kommer fra den udgiver, du forventer.

5. Beskyt dig mod forgiftning af data og modeller

En forgiftet AI lærer af korrupte data. Det kan være de eksempler, den er blevet finjusteret på, eller en videnbase, den søger svar i. Modellen ser stadig ud til at virke; den lærer bare de forkerte ting, og nogle gange lærer den kun at opføre sig forkert, når den ser en bestemt udløsende frase.

Modellen vil bestå alle de test, du udsætter den for, indtil nogen bruger frasen.

Udvid

Det er desuden virkelig svært at rette op på. Forgiftning er ikke en fejl, du kan patche. Hvis dine data er forkerte, kan det være nødvendigt at gennemgå dem igen, gentræne modellen eller udskifte den helt.

Eksempel: I oktober 2025 viste forskere fra Anthropic, UK AI Security Institute og Alan Turing Institute, at 250 forgiftede dokumenter kunne lære en model at producere volapyk, når den stødte på en bestemt udløser. Det samme antal virkede på tværs af alle fire testede modelstørrelser, selvom den største var trænet på mere end 20 gange så mange rene data.

Det kan du gøre:

• Hold styr på, hvor dine data kommer fra: Før en oversigt over alle datasæt og modeller, du bruger, hvor hver af dem kommer fra, og hvad der er ændret mellem versionerne. Vi anbefaler versionsstyring af datasæt, så du – hvis der dukker forgiftning op – kan rulle tilbage til en ren version og finde ud af, hvordan den kom ind.
• Test for bagdøre: En ”bagdør” er en skjult adfærd, som en angriber planter i en model, og som venter på en bestemt frase eller en anden udløser for at blive aktiveret. Test for dem med input, der er designet til at få modellen til at bryde sine sædvanlige regler.

6. Sæt loft over ubegrænset forbrug

Når AI’er ikke har nogen grænser for, hvor meget arbejde de kan udføre, eller hvor meget de kan koste, betragtes deres forbrug som ”ubegrænset”. De fleste AI-tjenester tager betaling pr. brug, så en angriber kan få din regning til at eksplodere eller bygge en kopi af din model.

OWASP kalder kerneproblemet ”omkostningsasymmetri”. En kort, billig forespørgsel kan udløse dyre beregninger hos dig.

Eksempel: I maj 2024 opdagede Sysdigs Threat Research Team en ny type angreb kaldet ”LLMjacking”. En gruppe angribere gik efter 10 cloudhostede LLM-tjenester ved hjælp af stjålne adgangsoplysninger. De kom ind via en sårbar version af Laravel og fandt derefter ud af, hvad adgangsoplysningerne kunne bruges til, og hvilke kvoter der var, med det åbenlyse formål at sælge adgangen. Der blev også forespurgt på en lang række logindstillinger, sandsynligvis for at undgå at blive opdaget. Ifølge Sysdig kunne et worst case-scenarie koste offeret over 46.000 dollar om dagen.

Det kan du gøre:

• Sæt budgetter, der stopper forbruget: Indfør faste udgiftsgrænser for individuelle brugere, API-nøgler, teams og kontoen som helhed. Håndhæv dem overalt, hvor forespørgsler kan komme ind.
• Giv hver opgave et stoppunkt: Begræns, hvor længe en opgave kan køre, hvor meget tekst den kan behandle og generere, og hvor mange værktøjskald den kan foretage. Tilføj automatiske afbrydelser for agenter, der gentager sig selv eller overskrider deres kvote.

7. Fang misinformation, før der handles på den

Når en AI producerer noget falsk, der lyder rigtigt, og nogen – eller noget – handler på det, kaldes det misinformation. Kernerisikoen er ikke så meget selve det forkerte svar, men at man stoler på det forkerte svar og bruger det.

Hændelseshistorikken tyder på, at fagfolk ikke var så bekymrede for misinformation, som de burde have været. Ifølge det indledende brev i 2026-udgaven placerede deltagerne i afstemningen den nær bunden, men ifølge hændelser fra virkeligheden ligger den nær toppen.

Eksempel: I 2025 leverede Deloitte Australia en gennemgang af IT-systemer på velfærdsområdet under en offentlig kontrakt på 440.000 australske dollar. Ved University of Sydney fandt forskeren Chris Rudge henvisninger til ikke-eksisterende forskning og et opdigtet citat fra en dom afsagt ved en føderal domstol. Den reviderede rapport oplyste, at Deloitte havde brugt Azure OpenAI GPT-4o i sin metode, og firmaet indvilligede i at tilbagebetale den sidste rate. Der var desværre tale om en kvalitetssikringsgennemgang.

Det kan du gøre:

• Tjek, at dokumentationen understøtter svaret: Forankr påstande i aktuelle, autoritative kilder. Ved et svar om en politik skal du hente den godkendte politik og tjekke, at den understøtter konklusionen – inklusive undtagelserne.
• Verificer, før systemet handler: Hvis en agent siger, at en kunde har bestået en identitetskontrol, så bekræft det mod verifikationssystemet, før en betaling frigives. Kræv menneskelig godkendelse af betydningsfulde beslutninger, og sørg for, at den underbyggende dokumentation er tilgængelig for den, der gennemgår dem.

8. Begræns skaden ved eksponering af skjult kontekst

AI-applikationer giver modellen instruktioner og baggrundsoplysninger, som brugerne normalt ikke ser. Det kan omfatte systemprompten, interne politikker, beskrivelser af tilgængelige værktøjer og regler for, hvem der må bruge dem. Eksponering af skjult kontekst opstår, når modellen afslører disse oplysninger for nogen.

I 2026 udvidede OWASP dette punkt fra ”lækage af systemprompt”, fordi systemprompten kun er en del af det, der kan slippe ud. Faren afhænger af, hvad du har lagt ind der. En lækket tone of voice-guide er lidt pinlig, men en lækket API-nøgle giver nogen adgang til din fortrolige database.

Eksempel: I februar 2023 fik brugere Microsofts Bing Chat til at afsløre sine interne instruktioner. Ét vellykket forsøg kom fra Marvin von Hagen, der udgav sig for at være OpenAI-udvikler og bad om instruktionerne, så han kunne konfigurere modellen. Bing afslørede regler for sine søgninger, svar og sikkerhedsadfærd samt sit interne navn, Sydney. Blandt de afslørede instruktioner var én, der sagde, at instruktionerne skulle holdes fortrolige.

Det kan du gøre:

• Hold hemmeligheder ude af modellens kontekst: Gå ud fra, at alt, hvad modellen kan læse, kan blive synligt for brugerne – gem adgangskoder, API-nøgler og adgangstokens i et separat system til håndtering af hemmeligheder.
• Sørg for, at tilladelserne holder, selv når reglerne lækker: Håndhæv adgangskontrol i din applikationskode. Hvis et værktøj kun må bruges af administratorer, skal du tjekke brugerens kontotilladelser, før det køres.

9. Beskyt dine vektorer og embeddings

Når en AI bruger vektorsøgning til at finde svar i din virksomheds dokumenter, søger den ikke direkte i teksten. Dokumenterne konverteres til »embeddings«, som er lange lister af tal, der indfanger, hvad hver passage betyder, og de gemmes i en vektordatabase. Et spørgsmål konverteres på samme måde, og systemet henter de passager, hvis tal ligger tættest på.

OWASP opsummerer de fire måder, det kan gå galt på: Forgiftning får systemet til at tage fejl, inversion får det til at lække, jamming får det til at tie stille, og mangelfuld adgangskontrol får det til at udlevere hvad som helst til hvem som helst.

Tallene er ikke den sikre abstraktion, de ligner. De gemte embeddings kan omdannes tilbage til tekst, og én metode genskabte 92 % af korte passager på 32 tokens nøjagtigt i sine test. En lækket backup med »kun embeddings« kan altså også afsløre dokumenternes indhold.

Eksempel: I forskning præsenteret ved USENIX Security 2025 viste forskere, at ét omhyggeligt udformet dokument kunne forhindre en AI i at besvare et bestemt spørgsmål. De føjede det til den samling, som AI'en søgte i. Når AI'en fandt det, kunne den sige, at den ikke havde nok information, eller at det ville være usikkert at svare. Dokumentet behøvede ikke at bede AI'en om at ignorere sine regler. Dette kaldes »retrieval jamming«.

Det kan du gøre:

• Hav separate indekser til offentlige og private data: Bland ikke indhold skrabet fra nettet med partnerdata eller fortrolige interne dokumenter. Adskil indholdet fysisk efter tillidsniveau i stedet for at tagge det i ét indeks. Det fjerner en hel klasse af fejlkonfigurationer, og indhold skrabet fra internettet kan ikke ende ved siden af dine bestyrelsespapirer.
• Behandl embeddings som de dokumenter, de stammer fra: Kryptér dem, beskyt backups af vektordatabasen lige så godt som kildefilerne, og slet embeddings, når du sletter originalen. API-nøgler til din embedding-tjeneste skal holdes hemmelige.

10. Tjek AI-output, før du sender det videre

Når en applikation sender AI-output videre til et andet system uden at kontrollere, om det er sikkert at bruge dér, er der tale om forkert håndtering af LLM-output.

Punktet dækker også den usikre kode, som AI-kodeassistenter genererer i stor skala. Hver eneste linje, en assistent skriver, er derfor også output.

Eksempel: I 2025 viste forskeren Johann Rehberger, hvordan Sourcegraphs kodeassistent Amp kunne lække chatindhold blot ved at vise et billede. Han brugte prompt injection til at få Amp til at indsætte private oplysninger i et billedes webadresse. Applikationen hentede derefter automatisk billedet og sendte dermed oplysningerne til hans server. Fejlen i håndteringen af output var netop den automatiske forespørgsel – den tekst, modellen genererede, blev til en forbindelse til en ekstern server, der tog private data med sig.

Det kan du gøre:

• Gør outputtet sikkert for dets destination: Tjek og håndtér svar ud fra, hvor de skal hen. På en webside skal du forhindre, at genereret tekst bliver til eksekverbar kode. I en database skal du bruge parameteriserede forespørgsler, der holder de angivne værdier adskilt fra kommandoerne.
• Forhindr svar i at oprette automatiske eksterne forbindelser: Deaktiver som standard automatisk indlæsning af billeder, linkforhåndsvisninger og indlejrede sider i modelsvar. Begræns nødvendige forbindelser til udtrykkeligt godkendte destinationer.

Hvordan sikrer Perplexity LLM'er?

Vi går ud fra, at alle risiciene ovenfor før eller siden vil ramme, og vi designer vores systemer, så de ikke kan gøre ret meget skade, når det sker. Vores CISO, Kyle Polley, gennemgik, hvordan vi gør det, på en nylig workshop.

• Agenten får sin egen computer, og den starter tom: Agentværktøjer, der er installeret på din bærbare computer, kan få adgang til dens filer, apps og gemte loginoplysninger. Perplexity Computer fungerer omvendt. Hver opgave kører i sin egen isolerede sandbox, og som Polley siger: »Som standard har den adgang til ingenting.«
• Agenten ser aldrig adgangskoderne: Loginoplysningerne til tilknyttede tjenester gemmes uden for sandboxen. Når agenten skal bruge en tjeneste som GitHub, sender den en forespørgsel uden loginoplysninger. En gateway kontrollerer, at destinationen og forespørgslen er som forventet, og tilføjer derefter loginoplysningerne på vej ud. Agenten kan bruge forbindelsen uden at få nøglerne.
• Dine tilladelser følger med, og du kan stramme dem: Forbindelser oprettet via OAuth bevarer dine adgangstilladelser i den tilknyttede tjeneste. Hvis du ikke kan se noget, kan din agent heller ikke.
• Alle websider behandles som fremmede: Vi byggede BrowseSafe til Comet, vores agentiske browser, fordi de værktøjer, vi testede, ikke levede op til vores behov i praksis. Browseren scanner websider og andet eksternt indhold, herunder e-mails, for prompt injection. Vi har gjort både modellen og datasættet open source.
• Vi holder øje med agenten og de maskiner, den kører på: Numbat sidder mellem det øjeblik, en agent beslutter at handle, og det øjeblik, værktøjet faktisk kører. Numbat logger aktivitet på tværs af understøttede kodeagenter og kan blokere handlinger, der bryder konfigurerede politikker, før de udføres. Bumblebee registrerer softwarepakker på tværs af bærbare computere, servere og build-pipelines og markerer kendte ondsindede pakker. Begge er open source.
• Modeludbyderne gemmer ikke dine data: Vi har aftaler med vores tredjepartsudbydere af LLM'er om, at de ikke opbevarer data (zero data retention). Enterprise-administratorer kan desuden sætte Perplexitys egen dataopbevaring helt ned til 24 timer.

Vi byggede Numbat proaktivt af en grund, som Polley opsummerer i én sætning: »Jo mere autonomi du giver en agent, jo større er risikoen.«

Ofte stillede spørgsmål om LLM-sikkerhed

Hvilken LLM er den mest sikre?

Ingen LLM gør i sig selv en applikation sikker – modeller kan stadig forveksle indhold, de skal læse, med instruktioner, de skal følge. Forsvar, der ser stærke ud i standardtest, kan også bryde sammen under pres.

Et bedre spørgsmål er, hvilken opsætning der er mest sikker til dit formål. Det betyder begrænsede tilladelser, loginoplysninger holdt væk fra modellen, menneskelig godkendelse af risikable handlinger og test udført af folk, der kender dine forsvarsmekanismer.

Hvad er LLM-sårbarheder?

LLM-sårbarheder er svagheder, der gør det muligt at narre et AI-system, få det til at lække data eller forårsage skade, uanset om det sker via en angriber eller systemets egne fejl.

De ti største risici er prompt injection, videregivelse af følsomme oplysninger, overdreven handlefrihed, forsyningskæden, data- og modelforgiftning, ubegrænset forbrug, misinformation, eksponering af skjult kontekst, svagheder i vektorer og embeddings samt forkert håndtering af output.

Er en privat LLM sikker?

Til nogle formål er det en mere sikker løsning, men ikke automatisk. Du har mere kontrol over datahåndteringen, hvis du kører en model på din egen infrastruktur eller i et cloudmiljø. Men der findes ingen automatisk måde at forhindre prompt injection, overdreven handlefrihed, forgiftning eller misinformation på.

Når du selv hoster, er du også ansvarlig for den model, du downloader, herunder risiciene i forsyningskæden og den infrastruktur, den kræver.