LLM-sikkerhed

LLM-sikkerhed er den specialiserede disciplin, der handler om at beskytte applikationer bygget på store sprogmodeller mod en unik klasse af trusler, som ikke eksisterede i traditionel softwaresikkerhed. Efterhånden som organisationer implementerer AI-chatbots, autonome agenter og LLM-drevne arbejdsgange i stor skala, bliver forståelse og håndtering af LLM-specifikke sårbarheder et kritisk operationelt krav.

Hvorfor LLM’er kræver en ny sikkerhedstilgang

Traditionel applikationssikkerhed antager en klar grænse mellem kode (instruktioner) og data (brugerinput). Inputvalidering, parameteriserede forespørgsler og outputkodning fungerer ved at håndhæve denne grænse strukturelt.

Store sprogmodeller ophæver denne grænse. De behandler alt — udviklerinstruktioner, brugermeddelelser, hentede dokumenter, værktøjsoutput — som en samlet strøm af naturlige sprogtokens. Modellen kan ikke pålideligt skelne en systemprompt fra et ondsindet brugerinput designet til at ligne en. Denne grundlæggende egenskab skaber angrebsflader uden tilsvarende i traditionel software.

Derudover er LLM’er kapable agenter, der bruger værktøjer. En sårbar chatbot er ikke kun en indholdsrisiko — den kan være en angrebsvektor til at eksfiltere data, udføre uautoriserede API-kald og manipulere tilsluttede systemer.

OWASP LLM Top 10

Open Worldwide Application Security Project (OWASP) udgiver LLM Top 10 — industristandarden for kritiske LLM-sikkerhedsrisici:

LLM01 — Prompt Injection: Ondsindede input eller hentet indhold tilsidesætter LLM-instruktioner. Se Prompt Injection .

LLM02 — Usikker outputhåndtering: LLM-genereret indhold bruges i downstream-systemer (webrendering, kodeudførelse, SQL-forespørgsler) uden validering, hvilket muliggør XSS, SQL injection og andre sekundære angreb.

LLM03 — Forgiftning af træningsdata: Ondsindet data injiceret i træningsdatasæt forårsager forringelse af modeladfærd eller introducerer bagdøre.

LLM04 — Model Denial of Service: Beregningsintensive input forårsager overdreven ressourceforbrug, hvilket forringer tjenestens tilgængelighed.

LLM05 — Sårbarheder i forsyningskæden: Kompromitterede prætrænede modeller, plugins eller træningsdata introducerer sårbarheder før implementering.

LLM06 — Afsløring af følsomme oplysninger: LLM’er afslører fortrolige data fra træningsdata, systemprompts eller hentede dokumenter. Se Dataeksfiltrering (AI-kontekst) .

LLM07 — Usikkert plugin-design: Plugins eller værktøjer tilsluttet LLM’er mangler korrekt autorisation, hvilket muliggør eskaleringangreb.

LLM08 — Overdreven handlefrihed: LLM’er, der får overdrevne tilladelser eller kapaciteter, kan forårsage betydelig skade, når de manipuleres.

LLM09 — Overafhængighed: Organisationer undlader at evaluere LLM-output kritisk, hvilket gør det muligt for fejl eller fabrikerede oplysninger at påvirke beslutninger.

LLM10 — Modeltyveri: Uautoriseret adgang til eller replikering af proprietære LLM-vægte eller -kapaciteter.

Klar til at vokse din virksomhed?

Start din gratis prøveperiode i dag og se resultater inden for få dage.

Anmod om demo Log ind

Centrale LLM-sikkerhedskontroller

Privilegieadskillelse og mindste autoritet

Den mest effektfulde enkeltforanstaltning: begræns, hvad din LLM kan få adgang til og gøre. En kundeservicechatbot behøver ikke adgang til HR-databasen, betalingsbehandlingssystemer eller admin-API’er. Anvendelse af princippet om mindste privilegium reducerer dramatisk omfanget af et vellykket angreb.

Sikkerhed for systemprompt

Systemprompts definerer chatbot-adfærd og indeholder ofte forretningsfølsomme instruktioner. Sikkerhedshensyn omfatter:

• Inkluder ikke hemmeligheder, API-nøgler eller legitimationsoplysninger i systemprompts
• Design prompts til at være modstandsdygtige over for tilsidesættelsesforsøg
• Instruer eksplicit modellen om ikke at afsløre promptindhold
• Test promptfortrolighed som en del af regelmæssige sikkerhedsvurderinger (se Systemprompt-ekstraktion )

Input- og outputvalidering

Selvom intet filter er idiotsikkert, reducerer validering af input angrebsfladen:

• Marker og bloker almindelige injektionsmønstre og instruktionslignende formuleringer i brugerinput
• Valider modeloutput, før de sendes til downstream-systemer
• Brug strukturerede outputformater (JSON-skemaer) til at begrænse modelresponser

RAG-pipeline-sikkerhed

Retrieval-augmented generation introducerer nye angrebsflader. Sikre RAG-implementeringer kræver:

• Streng kontrol med, hvem der kan tilføje indhold til indekserede vidensbaser
• Indholdsvalidering før indeksering
• Behandling af alt hentet indhold som potentielt upålideligt
• Overvågning for forsøg på RAG-forgiftning

Runtime-sikkerhedsforanstaltninger

Lagdelte runtime-sikkerhedsforanstaltninger giver forsvar i dybden ud over alignment på modelniveau:

• Indholdsmodereringsfiltre på både input og output
• Adfærdsanomalidetektion
• Hastighedsbegrænsning og forebyggelse af misbrug
• Auditlogning til retsmedicinsk analyse

Regelmæssig sikkerhedstest

LLM-angrebsteknikker udvikler sig hurtigt. AI-penetrationstest og AI red teaming bør udføres regelmæssigt — minimum før større ændringer og årligt som baseline-vurderinger.

Relaterede termer

• Prompt Injection — den mest kritiske LLM-sårbarhed
• OWASP LLM Top 10 — den omfattende LLM-sikkerhedsrisikoramme
• AI Red Teaming — systematisk adversarial sikkerhedstest
• RAG-forgiftning — angreb med kontaminering af vidensbase
• AI-penetrationstest — strukturerede sikkerhedsvurderinger for AI-systemer