Prompt injection i website-chatbots: Beskyttelse af RAG, værktøjer og data

En website-chatbot behandler ikke kun harmløse spørgsmål. Besøgende kan forsøge at omskrive dens regler, afsløre interne instrukser eller udløse uautoriserede handlinger. Endnu sværere at opdage er kommandoer, der ikke står direkte i chatten, men er skjult på en crawlet webside, i et uploadet dokument eller i et tilsluttet tredjepartssystem.

Hvis man vil begrænse prompt injection i website-chatbots, kan man derfor ikke alene forlade sig på en særligt strengt formuleret system-prompt. Der er brug for en flerlagsarkitektur: Inputs og kilder behandles som ubetroede, rettigheder begrænses teknisk, output kontrolleres før viderebehandling, og risikable handlinger bekræftes af deterministisk kode eller et menneske.

Hvad prompt injection i en website-chatbot betyder

OWASP beskriver prompt injection som et input, der utilsigtet ændrer en sprogmodels adfærd eller output. En direkte prompt injection kommer umiddelbart fra brugeren, for eksempel som en opfordring til at ignorere tidligere regler. En indirekte prompt injection gemmer sig derimod i eksternt indhold, som systemet henter senere: websider, vidensdokumenter, e-mails, produktdata eller filer.

Denne adskillelse er vigtig for website-ejere. En ren FAQ-chatbot har en mindre angrebsflade end et system, der løbende crawler websider, gennemsøger interne dokumenter, læser CRM-data eller kan udføre funktioner. Retrieval-Augmented Generation (forkortet RAG) forbedrer det faglige fundament for svarene, men fjerner ikke injection-risikoen. Selv en velplejet kildesamling kan indeholde manipulerede eller misforståede instrukser.

Vurder risiko ud fra funktioner i stedet for modelnavn

Det afgørende spørgsmål er ikke kun: „Hvilken model bruger vi?“, men: „Hvilken konsekvens kan et manipuleret svar få?“ Opret et enkelt funktions- og datakort over chatbotten:

• Hvilke offentlige og interne kilder må den læse?
• Hvilke personhenførbare, fortrolige eller virksomhedskritiske data er tilgængelige?
• Kan den kun generere tekst, eller kan den også oprette tickets, leads, e-mails, aftaler eller ordrer?
• Hvilke handlinger ændrer eksterne systemer?
• Hvilke beslutninger godkendes automatisk, uden at et menneske kontrollerer dem?

Jo større læserettigheder, skriverettigheder og automatiseringsgraden bliver, desto vigtigere er tekniske grænser uden for modellen. Den eksisterende oversigt over hyppige AI-chatbot-fejl hjælper med den generelle statusopgørelse. I relation til prompt injection skal du desuden dokumentere datastrømme, tillidsgrænser og handlingsrettigheder.

Adskil fire tillidszoner klart fra hinanden

En praktisk sikkerhedsmodel skelner mellem fire zoner, selvom de teknisk set behandles i den samme applikation.

Zone 1: Systemregler og retningslinjer

Her fastlægges rolle, tilladt formål, svarafgrænsninger og eskaleringsregler. Disse regler giver modellen retning, men udgør ikke en pålidelig adgangskontrol. OWASP advarer udtrykkeligt mod at behandle system-prompts som en hemmelighed eller sikkerhedsmekanisme. Adgangsoplysninger, forbindelsesnøgler og følsomme interne oplysninger hører ikke hjemme her.

Zone 2: Inputs fra besøgende

Enhver chatbesked skal betragtes som ubetroet. Begræns længde, filtyper og tilladte funktioner; normaliser inputs til den tekniske behandling, og marker dem tydeligt i prompten som brugerdata. Et filter kan genkende kendte angrebsmønstre, men må ikke blokere legitime spørgsmål generelt. En besøgende, der spørger efter „ignore previous instructions“ i en sikkerhedsdokumentation, kan have et berettiget ærende.

Zone 3: Hentede kilder og RAG-kontekst

Også crawlet indhold, PDF'er og resultater fra eksterne tjenester forbliver data, ikke instrukser. Adskil deres indhold synligt fra styrekonteksten, gem oprindelse og hentningstidspunkt, og tillad kun godkendte kilder. Artiklen om opdatering af AI-chatbotters vidensbase viser, hvordan kildeinventar, crawl-kadence og QA samspiller.

Zone 4: Værktøjer, handlinger og output

Funktionskald må ikke udføres, blot fordi modellen genererer en passende tekst. En deterministisk controller tjekker funktionsnavn, parametre, rettigheder, sessionskontekst og tilladte målsystemer. Model-outputs, der senere bruges som HTML, Markdown, SQL, filsti eller API-parametre, kræver validering og kodning, der passer til den konkrete kontekst.

Least privilege begrænser konsekvenserne

Prompt injection kan på nuværende tidspunkt ikke forhindres pålideligt med en enkelt foranstaltning. Derfor skal applikationen opbygges således, at et succesfuldt manipulationsforsøg har så lille en effekt som muligt. OWASP og Microsoft anbefaler princippet om mindste privilegium (least privilege).

• Brug adskilte tekniske identiteter til læsning og skrivning.
• Tildel kun adgang til de data, der er nødvendige for chatbotten specifikke formål.
• Begræns funktioner til små, klart definerede parameterskemaer.
• Brug kortvarige rettigheder, hvis en handling overhovedet kræver det.
• Kræv en udtrykkelig bekræftelse ved risikable eller uigenkaldelige trin.
• Overlad aldrig autorisering til modellens frie tekst.

En support-chatbot kan for eksempel forberede et ticket-udkast, men bør ikke automatisk bestemme vilkårlige modtagere, prioriteter eller interne adgangsrettigheder. En lead-chatbot kan modtage strukturerede kontaktdata uden derved at få læserettigheder til hele CRM-systemet.

Kontroller og isoler RAG-kilder

Indirekte prompt injection gør kildepipelinen til en del af sikkerhedsarkitekturen. En manipuleret side kan virke harmløs visuelt og alligevel indeholde tekst, som en model fortolker som en instruks. I multimodale systemer kan billeder eller andre filformater også spille en rolle.

Indfør derfor et kildeindtag med godkendelsesregler: tilladte domæner og dokumentområder, sporbare ejere, versionsstyring, malware- og filkontrol samt et review af nyt eller usædvanligt ændret indhold. Marker hentede afsnit i modelkonteksten udtrykkeligt som untrusted content. Et søgeresultat må levere informationer, men ikke ændre systemregler eller værktøjsrettigheder.

Kontroller desuden, om svaret reelt er understøttet af kilderne. Vejledningen til svarkvalitet for AI-chatbots med Golden Set og RAG-tests beskriver groundedness og kildesammenligning. Denne kvalitetstest supplerer sikkerhedskontroller, men erstatter dem ikke.

Input- og outputfiltre er ét lag, ikke hele løsningen

Specialiserede beskyttelsestjenester kan opdage direkte og indirekte angrebsforsøg. Microsoft Prompt Shields skelner for eksempel mellem angreb i brugerinputs og skjulte instrukser i dokumenter. Google anbefaler i sine sikkerhedsretningslinjer ligeledes beskyttelsesforanstaltninger mod prompt injection, snævrere afgrænsede opgaver, bruger-ID'er, mængdebegrænsninger og menneskeligt tilsyn ved højere risiko.

Sådanne filtre leverer probabilistiske signaler. Planlæg derfor en gradueret reaktion: bloker, svar sikkert, skift til en snævert begrænset tilstand, eller overdrag til et menneske. Log beslutningsklassen og den tekniske version, men undgå unødvendig fuldtekstlagring. For personoplysninger gælder desuden de kontrolområder, der beskrives i artiklen om AI-chatbots og GDPR. Denne artikel udgør ikke juridisk rådgivning.

Valider model-output før viderebehandling

Et sikkert input garanterer ikke et sikkert output. OWASP angiver utilstrækkelig outputhåndtering som en særskilt risiko: Modeltekst kan senere ende i HTML, scripts, databaseforespørgsler eller filstier. Behandl derfor også ethvert model-output som ubetroet i første omgang.

Kræv et snævert, struktureret format til automatiserede workflows, og valider det mod et skema. Brug allowlists (positivlister) til funktionsnavne og målsystemer. Kod synlig tekst til den respektive outputkontekst. Kassér uventede felter, eksterne URL'er og parametre uden for de tilladte værdier. Følsomme data bør gennemgå en særskilt retningslinjekontrol før visning eller overførsel.

Test prompt injection med et sikkerhedstest-sæt

Suppler det faglige Golden Set med modpartstests (adversarial test cases). Testene skal afprøve det faktiske produktionssystem inklusive retrieval, værktøjer og rettighedslogik – ikke kun basismodellen. Et nyttigt test-sæt indeholder:

• direkte forsøg på at erstatte regler eller forespørge på interne instrukser;
• flersprogede, kodede og over flere beskeder fordelte varianter;
• harmløse faglige spørgsmål, der indeholder lignende nøgleord og ikke må blokeres fejlagtigt;
• manipulerete afsnit i en test-videnskilde;
• uautoriserede funktionsnavne, ekstra parametre og fremmede måladresser;
• forsøg på at udlæse fortrolige data eller tidligere sessionsindhold;
• tests af HTML-, Markdown- und link-outputs;
• afbrydelses-, handoff- og bekræftelsesveje ved risikable handlinger.

Mål ikke kun, om et filter udløses. Kontroller det endelige resultat: Blev en uautoriseret handling forhindret? Forblev fortrolige data beskyttet? Fungerede en legitim forespørgsel stadigvæk? Blev et mistænkeligt tilfælde logget på en sporbart måde?

Praktisk implementeringsplan for website-teams

1. Kortlæg omfanget: Dokumenter datakilder, værktøjer, skriverettigheder og eksterne mål.
2. Adskil tillidszoner: Marker systemregler, brugerinputs, RAG-indhold og handlings-outputs teknisk.
3. Reducer rettigheder: Fjern ubrugte adgange, og opdel skrivehandlinger i små funktioner.
4. Tilføj validering: Indfør inputgrænser, strukturerede outputs, positivlister og kontekstspecifik kodning.
5. Fastlæg bekræftelse: Sikr risikable handlinger og følsomme datastrømme med Human-in-the-Loop.
6. Kør test-sættet: Tjek direkte, indirekte og legitime kontroltilfælde før enhver relevant release.
7. Overvåg driften: Gennemgå regelmæssigt filterhændelser, afviste handlinger, usædvanlige kildeændringer og falske alarmer.

Tjekliste: Beskyttelse mod prompt injection

• System-prompten indeholder ingen secrets og erstatter ikke autorisering.
• Brugertekster og eksterne kilder betragtes som udgangspunkt som ubetroede.
• RAG-kilder har godkendelse, oprindelse, version og ansvarlige ejere.
• Værktøjer følger least privilege og accepterer kun validerede parametre.
• Risikable handlinger kræver en sporbar bekræftelse.
• Model-outputs kontrolleres før HTML, API, CRM eller andre målsystemer.
• Sikkerhedsfiltre evalueres i forhold til falske positive og falske negative.
• Direkte og indirekte angrebstests afvikles regelmæssigt og efter ændringer.

Konklusion

Prompt injection er ikke et rent prompt-engineering-problem. For website-chatbots opstår en robust beskyttelse først, når applikationen behandler inputs, kilder, outputs og handlinger som adskilte tillidszoner. Filtre kan opdage angreb, men least privilege, deterministisk validering og menneskelig bekræftelse begrænser deres mulige konsekvenser.

Start med et funktions- og datakort over din chatbot. Fjern unødvendige rettigheder, isoler RAG-indhold, og test hele forløbet helt frem til den eksterne handling. På den måde forbliver chatbotten nyttig, uden at fri modeltekst bestemmer over rettigheder eller virksomhedskritiske ændringer.

Kilder

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance