Hvad er prompt injection og hvorfor det haster
Prompt injection er, med Unite.ai’s formulering, “an attack or failure mode in which untrusted content changes an AI system’s behavior by supplying instructions that compete with the intended task” (3527). Præcis og rammende: når en model får kontekst fra flere kilder – brugerinput, dokumenter, web – kan en lille tekstbid kapre opgaven. OWASP’s opdaterede risikokatalog placerer prompt injection som en central sårbarhed i produktionsnære miljøer (3530). Man ser det, når svar glider væk fra retningslinjer – eller når værktøjer forsøges udnyttet til handlinger, de ikke burde udføre.
Sådan virker angrebet nede i maskinrummet
Modeller skelner ikke naturligt mellem “fakta” og “instruktioner” i tilført tekst. De parser hele konteksten, og en ny, lokal instruktion kan overdøve en overordnet systemrolle. I praksis blandes tre ting: systemprompten (regler og persona), brugerens input og hentet kontekst fra f.eks. RAG. Netop dér kan en injektion gemme sig. OWASP dokumenterer, at input kan påvirke modeladfærd på måder, der fører til guideline-brud, skadelig output, uautoriseret adgang og påvirkning af beslutninger (3530). Mekanisk set favoriserer opmærksomhedsmekanismer ofte nærhed og tydelighed – seneste eksplicitte instruktion kan tromfe mere abstrakte regler.
Det ubehagelige: injection behøver ikke være synlig. OWASP beskriver, at indhold kan være “imperceptible to humans” og stadig virke, så længe modellen parser det (3530). Små tokenmønstre, tegnsekvenser eller formatering, der ser harmløse ud, kan være nok. Unite.ai beskriver samme mekanisme som en konkurrence mellem opgaven og en fremmed instruktion, der blandes ind i konteksten (3527). Tekst er porøs – ikke et hårdt API.
Hvor farligt er det i praksis
Konsekvenserne spænder fra trivielle regelbrud til dataeksfiltration. OWASP nævner eksplicit risiko for skadelig output, guideline-krænkelser, uautoriseret adgang og påvirkning af kritiske beslutninger (3530). Unite.ai peger på samme grundvilkår: adfærden kan skifte væk fra den tiltænkte opgave, fordi ubetroet indhold instruerer noget andet (3527). I en RAG-assistent kan dokumenter altså ikke kun levere svar – de kan levere ordrer.
Hvor hyppigt sker det i produktion? Her mangler data. Der er få åbne incident-rapporter, få eller ingen CVE’er på tværs af leverandører og begrænset antal offentliggjorte exploit-demos med bred effekt. Det er et hul i den offentlige dokumentation, ikke nødvendigvis i risikoen. Indtil der foreligger tal for succesrater, impact og recovery, er OWASP’s klassificering og retningslinjer den mest robuste standardreference (3530). Fraværet af statistik gør dog prioritering sværere for beslutningstagere.
Hvorfor de sædvanlige fixes ikke rækker
RAG fikser ikke prompt injection. OWASP peger direkte på, at hverken RAG eller fine-tuning fuldt ud afbøder sårbarheden (3530). Unite.ai forklarer hvorfor: angrebet udnytter, hvordan modeller prioriterer instruktioner i kontekst – ikke kun videnshuller (3527). Dokumenter kan i sig selv indeholde skadelige instrukser, og finetuning ændrer ikke, at ny kontekst kan overdøve træningssignal i en given session.
Derfor hjælper “stærkere systemprompt” kun delvist. En stram overordnet regel kan øge robustheden, men en målrettet, nær instruktion i et indlæst afsnit kan stadig vinde. OWASP anbefaler lagvise kontroller frem for enkelttiltag, fordi sårbarheden er strukturel (3530).
De praktiske forsvar man kan implementere
Hvad gør man uden at sætte produktet på pause? Snilld-teamets perspektiv, formuleret i deres manualbrief, er operationelt: behandle prompt injection som et konkret sikkerheds- og designproblem, og indfør lagvise kontroller omkring input, kontekst og rettigheder (3528). Start med prompt-hygiejne: skriv opgaver og systemroller klart, minimer tvetydigheder og begræns fritekst, hvor det ikke er nødvendigt. Dernæst kontekststyring: segmentér kilder, tilføj metadata, og giv ikke alle dokumenter samme vægt i én samlet kontekst.
Role-based access control lyder tørt, men forhindrer de værste scenarier. Uden adgang til nøgler kan modellen ikke lække dem – også hvis den narrers. Snilld-linjen omfatter desuden løbende evaluering og pen-testing målrettet LLM-komponenter samt output-filtre og model-isolering for højrisiko-flows (3528). Det er driftshygiejne, ikke pynt.
Arbejdsprocesser der faktisk ændrer sig
Implementeringsteams vil opdage, at pipelines må gentænkes. Rå tekst dumpet i en RAG-kontekst uden kontrol for instruktioner i materialet er en fejl – både Unite.ai og OWASP advarer om angreb via dokumentindhold, ikke kun via brugerens prompt (3527, 3530). Indeksering skal derfor kunne identificere eller neutralisere potentielle instruktioner – ikke blot udtrække matches. Det kræver tooling og disciplin: kortlæg datakilder, ejerskab og hvilke teksttyper der overhovedet må ind i konteksten.
For drift og SRE er kravet enkelt at formulere og svært at leve: almindelige applikationslogs er ikke nok. Man skal kunne opdage uventede modelbeslutninger og adfærdsændringer – ikke kun 200/500-koder eller latens. Snilld-manualbriefen fremhæver særskilt logging og mønsterovervågning omkring AI-komponenter samt periodiske tests, der simulerer angreb (3528). Den første gang man ser en model skifte “tone” i takt med kontekstudskiftninger i graferne, forstår man pointen.
Trade-offs man ikke slipper for
Strammere sanitization og isolering koster typisk latency, kompleksitet og somme tider svarkvalitet. Snilld-briefen er tydelig om trade-offs mellem rig kontekst, brugeroplevelse, svartid og sikkerhed – der findes ikke én løsning, der dækker alt (3528). Unite.ai beskriver samme spænding: mere kontekst kan give bedre svar, men øger angrebsfladen, fordi flere tokens kan bære instrukser (3527). Den rette balance findes sjældent i første forsøg; man må måle og justere.
Produktledelse havner midt i spændet. Krav om forklarlighed og hurtige svar presser mod mere kontekst, mens sikkerhed presser mod mindre. Praktisk råd: prioriter de flows, hvor AI driver størst forretningseffekt, og læg sikkerhedsressourcerne dér først. Resten følger efter.
Nye arkitekturspor med typed beslutninger
På længere sigt spirer alternativer til fritekst-interfaces. TypeSafe AI har annonceret Jev, et system der beskrives som returnerende typed, kalibrerede beslutninger i stedet for fritekst. Ifølge Marktechpost’s dækning er Jev transformer-baseret, men ikke en klassisk stor sprogmodel; man sender en state og typed spørgsmål og får beslutninger med sandsynligheder tilbage (3529). Det er interessant, fordi fritekst er en stor angrebsflade for injection – typed output kan gøre grænserne fastere.
Begrænsningerne er tydelige: Jev er tidlig adgang bag venteliste, der er ingen publicerede weights, intet parametercount og ingen selvhost-mulighed ifølge samme kilde (3529). Tredjepartsbenchmarks, sikkerhedsanalyser og produktionscases mangler. Idéen er værd at følge, men ikke en drop-in-løsning i morgen. Uden dokumenteret modstandsdygtighed mod injection er risikoreduktionen stadig hypotetisk – yderligere kilder påkrævet.
En lagdelt strategi man kan starte på i dag
En kort, brugbar liste: 1) Kortlæg AI-flows og datakilder og marker, hvor ubetroet indhold kan trænge ind. 2) Indfør prompt-hygiejne i system- og brugerprompter, inkl. eksplicit afvisning af kontekstuelle instrukser fra kilder. 3) Tilføj RAG-sanity checks og segmentér indekser – adskil fakta fra instrukser i kuraterede felter. 4) Indskrænk rettigheder for agenthandlinger og API-nøgler efter princippet om mindst mulige rettigheder (3528). 5) Etabler særskilt logging og monitoring for modelbeslutninger og kontekstbrug, ikke kun HTTP-metrics (3528). 6) Kør løbende pen-tests med kendte injection-mønstre og OWASP’s vejledninger som ramme (3530). 7) Evaluer typed eller strukturerede output-strategier i afgrænsede flows, og mål effekter på sikkerhed, latency og UX (3529, 3528).
Bemærk prioritetslogikken: start, hvor potentielt skadeomfang er størst – ikke hvor det er mest teknisk interessant. Politik på papir hjælper ikke uden spor i koden.
Usikkerheder og hvad der bør undersøges nu
Der mangler dokumenterede production-cases og offentlige CVE’er for konkrete prompt injection-incidenter. Uden dem bliver risikovurderingen for generisk. Der mangler også empiriske studier af, hvor ofte injection lykkes i RAG- og chatbot-implementeringer, hvilken forretningspåvirkning man ser, og hvor hurtigt teams kan recovere. De data findes ikke i de foreliggende kilder og bør indhentes før endelig konklusion.
Derudover efterlyses tekniske implementeringsmønstre, kodeeksempler og standardiserede testscripts til modforanstaltninger. OWASP og Unite.ai giver solide principper, men færre konkrete opskrifter (3527, 3530). Endelig er der brug for leverandørudtalelser fra de store – OpenAI, Anthropic, Google – om deres aktuelle defenses, samt uafhængige sikkerhedsvurderinger af typed-beslutningsmodeller som Jev (3529).
Kort opsamling og en direkte anbefaling
Prompt injection er ikke en nichefejl. Unite.ai’s definition er klar, og OWASP’s klassificering er tydelig: ubetroet indhold kan med små midler ændre modeladfærd, ofte usynligt, og føre til skadelig output, guideline-brud og fejl i beslutninger (3527, 3530). RAG og fine-tuning er nyttige, men ikke tilstrækkelige (3530). Praktiske forsvar findes, men koster latency, kompleksitet og indimellem kvalitet. Et rimeligt bytte, hvis man prioriterer rigtigt.
Anbefalingen er konkret: få prompt injection ind i risikomodellen nu, kortlæg angrebsflader, og byg lagvise værn tæt på de flows, der betyder mest. Resten kan vente et par sprint. Effekten bliver først tydelig, når det er implementeret.
