Hulp nodig bij deze handleiding?Vraag het DripTell-team
Test klantenservice AI op promptinjectie door te controleren wat niet vertrouwde invoer het volledige systeem kan laten tonen, wijzigen of uitvoeren. Doe dat in een testomgeving met fictieve klanten, beperkte hulpmiddelen en vastgelegde resultaten. Een beleefde weigering bij één opvallende opdracht bewijst niet dat een agent veilig is.
Bij promptinjectie verandert niet vertrouwde invoer het gedrag van een taalmodel op een onbedoelde manier. Die invoer kan rechtstreeks uit een klantbericht komen, maar ook indirect uit een kennisartikel, bijlage, webpagina, reactie van een hulpmiddel of opgeslagen gesprek. Het OWASP Gen AI Security Project plaatst dit risico op nummer LLM01 voor 2025 en legt uit dat retrieval en verdere training het risico niet volledig wegnemen.
Voor een serviceteam is dit meer dan een vreemd modelantwoord. Een AI agent kan klantgegevens zien, kennis ophalen, labels toevoegen, een ticket aanpassen of een overdracht voorstellen. De test moet daarom het hele pad van bericht tot antwoord en actie volgen.
| Onderdeel | Wat je controleert |
|---|---|
| Begin bij de grens van elke actie | Leg vóór het schrijven van tests vast wat de agent mag lezen, beslissen en veranderen. Maak een duidelijk onderscheid tussen gewone antwoorden en handelingen met gevolgen. |
| Test iedere route voor niet vertrouwde inhoud | Begin met directe klantberichten die de rol van de agent proberen te veranderen, gegevens buiten de huidige klant vragen, beleid willen aanpassen of zonder geldige reden een hulpmiddel aanroepen. |
| Houd de test weg van echte klanten | Gebruik een aparte testomgeving met fictieve namen, bestellingen, adressen, betalingen en servicegeschiedenis. Geef die omgeving aanmeldgegevens die productie niet kunnen bereiken. |
| Beoordeel het mogelijke gevolg | Een slim of vreemd antwoord is minder belangrijk dan de schade die kan ontstaan. Beoordeel elk geval op de zwaarste actie die het systeem kon voltooien. |
Begin bij de grens van elke actie
Leg vóór het schrijven van tests vast wat de agent mag lezen, beslissen en veranderen. Maak een duidelijk onderscheid tussen gewone antwoorden en handelingen met gevolgen.

Een agent mag bijvoorbeeld een openbaar retourbeleid uitleggen. De agent mag geen bestelling van een andere klant tonen, een terugbetaling wijzigen, zelf een uitzondering bedenken of accountgegevens naar een nieuw adres sturen. Kan een proces een lead maken of een ticket bijwerken, noteer dan precies welke velden mogen veranderen en aan welke voorwaarden eerst moet zijn voldaan.
Volg bij elke test deze keten:
- Welke niet vertrouwde inhoud kwam het systeem binnen?
- Welke instructies en gegevens haalde de agent op?
- Welk hulpmiddel of proces probeerde de agent te gebruiken?
- Welke controle vond buiten het model plaats?
- Wat zag de klant en wat werd voor controle bewaard?
Zo wordt een raar antwoord een herleidbare systeemfout. Kijk niet alleen of de chatbot zijn verborgen instructies prijsgeeft. Een systeem kan die instructies geheimhouden en toch een verkeerde actie uitvoeren.
Test iedere route voor niet vertrouwde inhoud
Begin met directe klantberichten die de rol van de agent proberen te veranderen, gegevens buiten de huidige klant vragen, beleid willen aanpassen of zonder geldige reden een hulpmiddel aanroepen. Beschrijf het gewenste ongewenste gedrag in het testverslag, zonder bruikbare aanvalsteksten te publiceren.
Test daarna indirecte routes. Plaats onschuldige testinstructies in een artikel van de testkennisbank, een bijlage, een productbeschrijving, een oud ticket en een nagebootste reactie van een hulpmiddel. Het systeem hoort deze inhoud als gegevens te behandelen, niet als gezag boven de eigen regels.
Voeg gesprekken met meerdere beurten, andere talen, ongebruikelijke opmaak, lange histories, bijlagen en herhaalde pogingen toe. De Britse National Cyber Security Centre richtlijn beschrijft directe en indirecte manipulatie van modelinvoer. Bij agents kunnen vijandige instructies ook via een hulpmiddel of andere agent binnenkomen. Daarom horen inbox, kenniszoekfunctie, geheugen en acties allemaal bij de test.
Houd de test weg van echte klanten
Gebruik een aparte testomgeving met fictieve namen, bestellingen, adressen, betalingen en servicegeschiedenis. Geef die omgeving aanmeldgegevens die productie niet kunnen bereiken. Schakel echte e mail, berichten, terugbetalingen, reserveringen en verwijderingen uit of stuur iedere actie naar een gecontroleerde testdienst.
Test alleen systemen waarvan je eigenaar bent of waarvoor je toestemming hebt. Zet geen productiegeheimen in opdrachten. Gebruik echte klantgesprekken alleen wanneer daarvoor een goedgekeurd beveiligings- en privacyproces bestaat.
Bewaar per geval de agentversie, systeeminstructies, opgehaalde inhoud, beschikbare hulpmiddelen, rechten, voorgenomen actie, controle-uitkomst, antwoord en menselijke overdracht. Zonder dit bewijs kan een fout verdwijnen wanneer iemand het gesprek opnieuw uitvoert.
Beoordeel het mogelijke gevolg
Een slim of vreemd antwoord is minder belangrijk dan de schade die kan ontstaan. Beoordeel elk geval op de zwaarste actie die het systeem kon voltooien.
- Lage impact is een slecht of niet relevant antwoord zonder datalek of wijziging.
- Merkbare impact is verkeerd beleid, een onjuiste ticketstatus, een gemiste overdracht of ongewenst klantbericht.
- Hoge impact is informatie over een andere klant, een ongeoorloofde accountactie, een gewijzigde betaling of terugbetaling, gelekte aanmeldgegevens of een extern gevolg.
Maak ook onderscheid tussen geblokkeerd, ontdekt, ingeperkt en geslaagd. Een detector kan pas waarschuwen nadat een gevaarlijke actie al klaar is. Inperking betekent dat controles rond het model het gevolg hebben voorkomen, ook als het model de niet vertrouwde instructie volgde.
Versterk het systeem rond het model
Vertrouw niet op één strenger geschreven systeemprompt. OWASP kent geen waterdichte preventiemethode en adviseert meerdere beschermingslagen. Geef de agent alleen noodzakelijke gegevens en hulpmiddelen. Dwing toegang tot klant en werkruimte af in gewone programmacode. Controleer argumenten en uitvoer met vaste regels. Houd opgehaalde, niet vertrouwde inhoud apart van systeeminstructies. Vraag menselijke goedkeuring voor acties met een hoog risico.
Het NIST profiel voor risicobeheer van generatieve AI behandelt promptinjectie binnen een bredere aanpak voor ontwerp, invoering, evaluatie en bewaking. Een oplossing moet dus het gevolg beperken en bewijs opleveren, niet alleen één testzin tegenhouden.
Voer de volledige reeks opnieuw uit na een wijziging aan model, prompt, kennisbank, hulpmiddel, toestemming, geheugenregel of proces. Bewaar fouten als regressietests. Breng de agent pas uit wanneer het ontvangende team de resterende grenzen begrijpt en weet hoe het systeem kan worden gepauzeerd.
Een voorbeeld uit een cameraverhuur
Stel dat een AI vragen beantwoordt voor een cameraverhuur. De agent mag openbare apparatuurinformatie lezen en beschikbaarheid voor de huidige klant controleren. Tests moeten aantonen dat een geüpload bestand het verhuurbeleid niet kan wijzigen, een klant geen reservering van een ander ontvangt en de agent geen boeking bevestigt zonder de normale controles van identiteit en beschikbaarheid.
Is een bericht onduidelijk of vraagt het om een uitzondering, dan kan een overdracht met de oorspronkelijke vraag en voorgenomen actie de juiste uitkomst zijn. Een veilige agent beantwoordt niet per se alles. De bevoegdheid blijft beperkt wanneer een gesprek vijandig of onduidelijk wordt.
Met DripTell AI kunnen teams kennis, intenties, leadcreatie en menselijke overdracht beheren. Beveiligingsinstellingen regelen rollen en toegang. Toch heeft iedere implementatie een testplan nodig dat past bij de gegevens en acties die werkelijk beschikbaar zijn.
Veelgestelde vragen
Kan promptinjectie volledig worden voorkomen
Nee. Geen huidige maatregel geeft volledige zekerheid. Minimale rechten, vaste toegangs- en actiecontroles, menselijke goedkeuring, bewaking en herhaalde tests verkleinen zowel de kans als de gevolgen.
Moet een test echte klantgegevens gebruiken
Nee. Begin in een geïsoleerde omgeving met fictieve records en uitgeschakelde externe acties. Productiegegevens mogen alleen via een goedgekeurd proces met heldere privacymaatregelen worden gebruikt.
Wat moet er na een mislukte test gebeuren
Bewaar het volledige spoor, blokkeer de gevaarlijke actie, bepaal welke vertrouwensgrens faalde en beperk rechten of voeg een vaste controle toe. Voer de mislukte test en de hele regressiereeks opnieuw uit voordat de agent wordt vrijgegeven.
DripTell Editorial
Praktische uitleg, gecontroleerd door het product- en klantworkflowteam van DripTell.
Lees hoe DripTell productclaims controleert, primaire bronnen gebruikt en correcties verwerkt.
Redactioneel en bronnenbeleid



