Prompt Injection bij website-chatbots: Bescherming voor RAG, tools en data

Een website-chatbot verwerkt niet alleen onschuldige vragen. Bezoekers kunnen proberen de regels te herschrijven, interne instructies te onthullen of ongeoorloofde acties te triggeren. Nog moeilijker te herkennen zijn commando's die niet rechtstreeks in de chat staan, maar verborgen zijn in een gecrawlde webpagina, een geüpload document of een gekoppeld extern systeem.

Wie prompt injection bij website-chatbots wil beperken, mag dan ook niet vertrouwen op alleen een bijzonder streng geformuleerde system prompt. Een gelaagde architectuur is noodzakelijk: invoer en bronnen worden behandeld als niet-vertrouwd, machtigingen worden technisch beperkt, uitvoer wordt gecontroleerd voor verdere verwerking en risicovolle acties worden bevestigd door deterministische code of een mens.

Wat prompt injection bij een website-chatbot betekent

OWASP beschrijft prompt injection als invoer die het gedrag of de uitvoer van een taalmodel onbedoeld verandert. Een directe prompt injection komt rechtstreeks van de gebruiker, bijvoorbeeld als het verzoek om eerdere regels te negeren. Een indirecte prompt injection zit daarentegen in externe inhoud die het systeem later ophaalt: webpagina's, kennisdocumenten, e-mails, productgegevens of bestanden.

Dit onderscheid is belangrijk voor website-beheerders. Een loutere FAQ-chatbot heeft een kleiner aanvalsoppervlak dan een systeem dat continu webpagina's crawlt, interne documenten doorzoekt, CRM-gegevens leest of functies kan uitvoeren. Retrieval-Augmented Generation, kortweg RAG, verbetert weliswaar de inhoudelijke basis van antwoorden, maar neemt het injection-risico niet weg. Ook een goed onderhouden verzameling bronnen kan gemanipuleerde of verkeerd begrepen instructies bevatten.

Risico beoordelen op basis van functies in plaats van modelnaam

De doorslaggevende vraag is niet alleen: „Welk model gebruiken we?“, maar: „Welke impact kan een gemanipuleerd antwoord hebben?“ Maak een eenvoudige functie- en datakaart voor de chatbot:

• Welke openbare en interne bronnen mag hij lezen?
• Welke persoonsgegevens, vertrouwelijke of bedrijfskritische data zijn toegankelijk?
• Kan hij alleen tekst genereren of ook tickets, leads, e-mails, afspraken of bestellingen aanmaken?
• Welke acties veranderen externe systemen?
• Welke beslissingen worden automatisch overgenomen zonder dat een mens ze controleert?

Hoe groter de lees- en schrijfrechten en de mate van automatisering worden, hoe belangrijker technische grenzen buiten het model zijn. Het bestaande overzicht van veelvoorkomende fouten bij AI-chatbots helpt bij de algemene inventarisatie. Voor prompt injection moet u daarnaast datastromen, vertrouwensgrenzen en actierechten documenteren.

Vier vertrouwenszones duidelijk van elkaar scheiden

Een praktisch veiligheidsmodel onderscheidt vier zones, zelfs als ze technisch in dezelfde applicatie worden verwerkt.

Zone 1: Systeemregels en richtlijnen

Hier staan rol, toegestaan doel, antwoordgrenzen en escalatieregels. Deze regels bieden het model oriëntatie, maar vormen geen betrouwbare toegangscontrole. OWASP waarschuwt er uitdrukkelijk voor om system prompts te behandelen als geheim of veiligheidsmechanisme. Inloggegevens, verbindingssleutels en gevoelige interne informatie horen er niet in thuis.

Zone 2: Invoer van bezoekers

Elk chatbericht is niet-vertrouwd. Beperk lengte, bestandstypen en toegestane functies; normaliseer invoer voor technische verwerking en markeer deze in de prompt duidelijk als gebruikersdata. Een filter kan bekende aanvalspatronen herkennen, maar mag legitieme vragen niet generiek blokkeren. Een bezoeker die in een beveiligingsdocumentatie vraagt naar „ignore previous instructions“, heeft mogelijk een terechte vraag.

Zone 3: Opgehaalde bronnen en RAG-context

Ook gecrawlde inhoud, pdf's en resultaten van externe diensten blijven data, geen instructies. Scheid de inhoud zichtbaar van de stuurcontext, sla herkomst en ophaaltijdstip op en sta alleen goedgekeurde bronnen toe. Het artikel over het actueel houden van de AI-chatbot-kennisbank laat zien hoe bronneninventaris, crawlfrequentie en QA samenwerken.

Zone 4: Tools, acties en uitvoer

Functie-aanroepen mogen niet louter worden uitgevoerd omdat het model passende tekst genereert. Een deterministische controller controleert functienaam, parameters, machtigingen, sessiecontext en toegestane doelsystemen. Model-uitvoer die later als HTML, Markdown, SQL, bestandspad of API-parameter wordt gebruikt, heeft de voor die context passende validatie en codering nodig.

Least privilege beperkt de impact

Prompt injection kan volgens de huidige stand van de techniek niet betrouwbaar worden uitgesloten met één enkele maatregel. Daarom moet de applicatie zo worden gebouwd dat een succesvolle manipulatiepoging zo min mogelijk schade kan aanrichten. OWASP en Microsoft adviseren hiervoor het principe van de minste privileges (least privilege).

• Gebruik gescheiden technische identiteiten voor lezen en schrijven.
• Verleen alleen toegang tot de data die noodzakelijk zijn voor het specifieke doel van de chatbot.
• Beperk functies tot kleine, helder gedefinieerde parameter-schema's.
• Maak gebruik van kortstondige machtigingen als een actie die überhaupt nodig heeft.
• Vraag uitdrukkelijke bevestiging voor risicovolle of onomkeerbare stappen.
• Laat autorisatie nooit over aan de vrije tekst van het model.

Een support-chatbot kan bijvoorbeeld een conceptticket voorbereiden, maar zou niet automatisch willekeurige ontvangers, prioriteiten of interne toegangsrechten moeten kunnen bepalen. Een lead-chatbot kan gestructureerde contactgegevens ontvangen zonder dat deze leestochten krijgt in het gehele CRM.

RAG-bronnen controleren en isoleren

Indirecte prompt injection maakt de bronnenpijplijn tot onderdeel van de veiligheidsarchitectuur. Een gemanipuleerde pagina kan er visueel onschuldig uitzien en toch tekst bevatten die door een model als instructie wordt geïnterpreteerd. Bij multimodale systemen kunnen ook afbeeldingen of andere bestandsformaten een rol spelen.

Voer daarom een bronnen-ingangscontrole in met goedkeuringsregels: toegestane domeinen en documentbereiken, traceerbare eigenaren, versiebeheer, malware- en bestandscontrole en een review voor nieuwe of ongebruikelijk gewijzigde inhoud. Markeer opgehaalde passages in de modelcontext uitdrukkelijk als niet-vertrouwde inhoud. Een zoekresultaat mag informatie leveren, maar geen systeemregels of toolmachtigingen veranderen.

Controleer bovendien of het antwoord daadwerkelijk door de bronnen wordt ondersteund. De gids voor het meten van antwoordkwaliteit bij AI-chatbots met Golden Sets en RAG-tests beschrijft groundedness en bronnenvergelijking. Deze kwaliteitscontrole vormt een aanvulling op beveiligingscontroles, maar vervangt ze niet.

Invoer- en uitvoerfilters zijn één laag, niet de volledige oplossing

Gespecialiseerde beveiligingsdiensten kunnen directe en indirecte aanvalspogingen herkennen. Microsoft Prompt Shields onderscheidt bijvoorbeeld aanvallen in gebruikersinvoer van verborgen instructies in documenten. Google adviseert in zijn beveiligingsrichtlijnen eveneens beschermingsmaatregelen tegen prompt injection, strakker afgebakende taken, gebruikers-id's, volumebeperkingen en menselijk toezicht bij een hoger risico.

Zulke filters leveren probabilistische signalen. Plan daarom gestaffeld gedrag: blokkeren, veilig antwoorden, overschakelen naar een strikt beperkte modus of overdragen aan een mens. Sla de beslissingsklasse en technische versie op in de logs, maar vermijd onnodige opslag van de volledige tekst. Bij persoonsgegevens gelden daarnaast de controlepunten die worden beschreven in het artikel over AI-chatbots en AVG/GDPR. Dit artikel vormt geen juridisch advies.

Model-uitvoer valideren voor verdere verwerking

Veilige invoer garandeert geen veilige uitvoer. OWASP noemt onvoldoende uitvoerverwerking als een zelfstandig risico: modeltekst kan later terechtkomen in HTML, scripts, databasequeries of bestandspaden. Behandel daarom ook elke model-uitvoer in eerste instantie als niet-vertrouwd.

Vereis voor geautomatiseerde processen een strikt gestructureerd formaat en valideer dit tegen een schema. Gebruik allowlists voor functienamen en doelsystemen. Codeer zichtbare tekst voor de specifieke uitvoercontext. Verwerp onverwachte velden, externe URL's en parameters buiten de toegestane waarden. Gevoelige data moeten voor weergave of overdracht nogmaals een eigen richtlijnencontrole doorlopen.

Prompt injection testen met een beveiligingstestset

Vul de inhoudelijke Golden Set aan met kwaadwillige (adversariale) testgevallen. De tests moeten het daadwerkelijke productiesysteem testen inclusief retrieval, tools en machtigingslogica, niet alleen het basismodel. Een nuttige set bevat:

• directe pogingen om regels te vervangen of interne instructies op te vragen;
• meertalige, gecodeerde en over meerdere berichten verspreide varianten;
• onschuldige inhoudelijke vragen die soortgelijke trefwoorden bevatten en niet ten onrechte geblokkeerd mogen worden;
• gemanipuleerde passages in een test-kennisbron;
• ongeoorloofde functienamen, extra parameters en vreemde doeladressen;
• pogingen om vertrouwelijke data of eerdere sessie-inhoud uit te voeren;
• tests voor HTML-, Markdown- en link-uitvoer;
• afbreek-, handoff- en bevestigingsroutes bij risicovolle acties.

Meet niet alleen of een filter aanslaat. Controleer het eindresultaat: Is een ongeoorloofde actie voorkomen? Bleven vertrouwelijke gegevens beschermd? Bleef een legitieme vraag gewoon werken? Is een verdacht geval herleidbaar gelogd?

Praktisch stappenplan voor websiteteams

1. Omvang in kaart brengen: databronnen, tools, schrijfrechten en externe doelen documenteren.
2. Vertrouwenszones scheiden: systeemregels, gebruikersinvoer, RAG-inhoud en actie-uitvoer technisch markeren.
3. Machtigingen beperken: ongebruikte toegang verwijderen en schrijfacties opdelen in kleine functies.
4. Validatie toevoegen: invoergrenzen, gestructureerde uitvoer, allowlists en contextspecifieke codering invoeren.
5. Bevestiging instellen: risicovolle acties en gevoelige datastromen beveiligen met human-in-the-loop.
6. Testset uitvoeren: directe, indirecte en legitieme controlegevallen testen voor elke relevante release.
7. Werking monitoren: filtergebeurtenissen, geweigerde acties, ongebruikelijke bronwijzigingen en vals-positieven regelmatig reviewen.

Checklist: Prompt injection-bescherming

• De system prompt bevat geen secrets en vervangt geen autorisatie.
• Gebruikersteksten en externe bronnen gelden standaard als niet-vertrouwd.
• RAG-bronnen hebben goedkeuring, herkomst, versie en verantwoordelijke eigenaren.
• Tools volgen least privilege en accepteren alleen gevalideerde parameters.
• Risicovolle acties vereisen een herleidbare bevestiging.
• Model-uitvoer wordt gecontroleerd voordat deze in HTML, API, CRM of andere doelsystemen terechtkomt.
• Beveiligingsfilters worden geëvalueerd op false positives en false negatives.
• Directe en indirecte aanvalstests worden regelmatig en na wijzigingen uitgevoerd.

Conclusie

Prompt injection is geen louter prompt-engineeringprobleem. Voor website-chatbots ontstaat een robuuste bescherming pas wanneer de applicatie invoer, bronnen, uitvoer en acties als gescheiden vertrouwenszones behandelt. Filters kunnen aanvallen herkennen, maar least privilege, deterministische validatie en menselijke bevestiging beperken hun mogelijke impact.

Begin met de functie- en datakaart van uw chatbot. Verwijder onnodige rechten, isoleer RAG-inhoud en test het volledige traject tot aan de externe actie. Zo blijft de chatbot nuttig zonder dat vrije modeltekst beslist over machtigingen of bedrijfskritische wijzigingen.

Bronnen

• 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