Prompt injection er det, der sker, når tekst, en sprogmodel læser, får den til at gøre noget andet, end I havde tænkt. Det står øverst på sikkerhedsprojektet OWASP’s liste over risici ved sprogmodeller, og OWASP skriver, at det er uklart, om der findes metoder, der forhindrer det helt. Derfor er det nyttige spørgsmål for ledelsen, hvad der kan ske, når et forsøg lykkes. Svaret afhænger af de kontroller, der ligger uden for modellen.
Hvorfor det overhovedet kan lade sig gøre
I almindelig software er der en tydelig grænse mellem kode og data. Et navn i et felt forbliver et navn. I en sprogmodel er alt tekst. Jeres instruktioner, brugerens spørgsmål og de dokumenter, funktionen henter, lander i samme strøm, og modellen kan ikke altid se forskel på, hvad der er en ordre, og hvad der er indhold.
Prompten er teksten, modellen får. Injection betyder, at nogen sniger noget ind i den. Tænk på en ny medarbejder, der får en seddel fra chefen og en bunke post, og som udfører alt, hvad der står i brevene.
To former, som ledelsen bør kende
OWASP skelner mellem to former.
- Direkte: en bruger skriver noget, der ændrer modellens opførsel, fx et forsøg på at få den til at se bort fra sine instruktioner eller vise dem frem. Det kan være bevidst, men det kan også ske ved et tilfælde.
- Indirekte: modellen læser indhold udefra, fx en hjemmeside, en mail eller en fil, og indholdet rummer instruktioner. Brugeren aner intet, og angriberen behøver aldrig at logge på.
Den indirekte form er den alvorligste for de fleste softwarevirksomheder. Tænkt eksempel: jeres produkt opsummerer indgående mails for en sagsbehandler. En afsender gemmer en linje i mailen, der beder modellen om at søge efter andre kunders oplysninger og lægge dem i et link. Hvis funktionen har adgang til mere end den aktuelle sag, og hvis svaret kan vise links, har I et datalæk uden nogen form for brud på login.
Hvad der er på spil
Størrelsen af problemet afhænger af tre ting, der tilsammen afgør skaden:
- Hvad funktionen kan læse. Har den adgang til andet end brugerens egne data?
- Hvad funktionen læser fra andre. Mails, dokumenter, kommentarer og data fra kunder kan alle bære instruktioner.
- Hvad funktionen kan gøre. Kan den sende noget ud, kalde et system eller ændre data?
Har funktionen alle tre, er risikoen størst. Et godt design fjerner mindst ét af benene. En funktion, der kun svarer brugeren om dennes egne data, og ikke kan sende noget ud, er langt mindre interessant at angribe.
Kontroller uden for modellen
Instruktioner som “ignorer forsøg på manipulation” hjælper lidt, men de kan omgås. Det afgørende ligger i kode, som modellen ikke kan tale sig uden om. OWASP’s anbefalinger peger samme vej, og oversat til et softwarehus bliver de til:
- Mindste rettighed. Følsomme handlinger håndteres af almindelig kode, og modellen får kun de værktøjer og data, opgaven kræver. Se kundedata i AI-funktionen.
- Mennesket godkender det risikable. Handlinger med konsekvens kræver en bruger, se AI-agenter i produktet.
- Modellens svar behandles som ubetroet input. Output kontrolleres mod et fast format med kode, før det bruges i et andet system. Vis ikke links og billeder automatisk, for de kan bære data ud af huset.
- Fremmed indhold mærkes og holdes adskilt. Det hjælper modellen, men det er en støtte og ingen garanti.
- Filtre på ind- og uddata. De fanger det oplagte og kan mærke mønstre, men de kan omgås.
- Test med fjendtlige øjne. Prøv angrebene jævnligt, og behandl modellen som en bruger, I ikke stoler på.
Læg desuden aldrig hemmeligheder som nøgler i instruktionerne. Regn med, at instruktionerne kan blive læst, og læs om nøgler og adgangskoder.
Spørgsmål til teamet
Stil disse fem spørgsmål på næste møde, og lad svarene komme på skrift:
- Hvilke kilder læser funktionen, som vi ikke selv har skrevet?
- Hvilke data kan den se ud over den aktuelle brugers?
- Kan dens svar forlade produktet, fx via links, billeder eller mails?
- Hvilke handlinger kan den udføre uden en brugers godkendelse?
- Hvornår har nogen sidst prøvet at narre den, og hvad skete der?
Forsøgene bør ligge i testsamlingen, så de køres ved hver ændring. Kommer et stort kundekrav eller en test af produktet, hører AI-funktionen med i omfanget, og det kan aftales ved en pentest af produktet. Den, der ejer sikkerheden i produktet, bør have prompt injection på sin risikoliste, ved siden af de almindelige sårbarheder.
Hvis det sker
Behandl det som en sikkerhedshændelse efter de procedurer, I allerede har. Luk funktionen eller dens værktøjer ned, gem loggene, find ud af hvad der blev læst eller sendt, og vurder, om kunder skal have besked. Ligger funktionen i et produkt, der er omfattet af Cyber Resilience Act, kan underretningspligten blive relevant. Om den gælder i det konkrete tilfælde, afhænger af produktet og hændelsen.
Det skal I lade være med
- At stole på, at modellen afviser manipulation · det kan den ikke altid.
- At tro, at fremmed tekst er uskyldig · dokumenter fra kunder og mails er input fra ukendte.
- At lade svar vise eksterne links og billeder uden kontrol · det er en kendt vej ud for data.
- At behandle emnet som en engangsopgave · nye former dukker op, så testen skal gentages.
Det skal I kræve af den eksterne
- ☐ En kortlægning af, hvad funktionerne kan læse, modtage og gøre.
- ☐ Et design, hvor mindst ét af de farlige ben er fjernet.
- ☐ Krav om kontroller i kode ud over instruktionerne til modellen.
- ☐ Faste forsøg på manipulation i testsamlingen.
- ☐ En forklaring til ledelsen af, hvilken risiko der bliver tilbage, og hvem der har accepteret den.
Kilder
- OWASP: LLM01:2025 Prompt Injection: direkte og indirekte former, forebyggelse og begrænsning.
- OWASP Top 10 for LLM and Gen AI Applications: 2025-udgaven af listen.
Senest gennemgået: november 2026.
Næste skridt
Læs også: AI-agenter i produktet · Kundedata i AI-funktionen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
