Een chatbot op de website, een assistent in uw softwarepakket, een zoekfunctie die antwoorden haalt uit interne documenten: steeds meer Vlaamse bedrijven bouwen AI in hun eigen toepassingen. Daarmee komt een kwetsbaarheid binnen die anders werkt dan wat ontwikkelaars kennen. In het Cobalt State of Pentesting Report 2026 was 32 procent van de bevindingen in AI- en taalmodeltoepassingen hoog of kritiek, 2,7 keer vaker dan bij conventionele software. Meer daarover in onze analyse van de meest gevonden kwetsbaarheden bij pentests.
Dit artikel legt uit wat prompt injection is, wat een pentest bij een AI-toepassing concreet nagaat, welke incidenten al publiek zijn en welke maatregelen een ontwikkelteam neemt. Het gaat over AI die uw bedrijf zelf bouwt of integreert. Over medewerkers die zelf AI-tools gebruiken, gaat ons artikel over shadow AI.
In het kort
- Prompt injection is een aanval waarbij tekst in de invoer of in een document een taalmodel andere instructies laat volgen dan de ontwikkelaar bedoelde.
- Het Britse NCSC waarschuwde in december 2025 dat prompt injection misschien nooit volledig te verhelpen is. De verdediging zit in wat het model mag zien en doen.
- Een AI-pentest test daarom vooral de omgeving van het model: autorisatie in de documentbronnen, de rechten van agents en de verwerking van de output.
- EchoLeak in Microsoft 365 Copilot toonde in 2025 dat één binnenkomende e-mail volstond om gegevens weg te sluizen, zonder dat de gebruiker iets aanklikte.
- Test vóór de lancering en opnieuw na elke wissel van model.
Wat is prompt injection?
Prompt injection is een aanval waarbij iemand tekst aanlevert die een taalmodel als instructie leest. Bij directe prompt injection typt de aanvaller die tekst zelf in het chatvenster. Bij indirecte prompt injection zit ze verstopt in een document, e-mail of webpagina die de AI-toepassing verwerkt, zonder dat de gebruiker het merkt.
De instructies van de ontwikkelaar, de opgehaalde documenten en de vraag van de gebruiker komen bij een taalmodel samen in één tekststroom, zonder harde grens tussen opdracht en gegevens. Een zin in een geüploade pdf kan dus hetzelfde gewicht krijgen als de regels die het ontwikkelteam schreef.
OWASP zet prompt injection als LLM01 bovenaan de Top 10 for LLM Applications van 2025. In MITRE ATLAS, de kennisbank van aanvallen op AI-systemen, is het techniek AML.T0051, met directe en indirecte injectie als subtechnieken. En de meldingen stijgen snel: HackerOne telde in zijn rapport van oktober 2025 540 procent meer geldige meldingen van prompt injection dan een jaar eerder.
Waarom is prompt injection niet weg te patchen?
SQL-injectie, de bekende aanval op databases, is op te lossen door gegevens en opdrachten strikt te scheiden. Het Britse NCSC legde in een blog van 8 december 2025 uit waarom die vergelijking misleidt: taalmodellen dwingen die scheiding niet af, en prompt injection is daardoor misschien nooit volledig te verhelpen. Het NCSC raadt aan om in te zetten op het beperken van de gevolgen. Filters en zogenaamde guardrails verhogen de drempel, maar bieden geen garantie.
Dat leidt tot een begrijpelijke vraag: als het toch niet op te lossen is, waarom zou u dan testen? Omdat een AI-pentest niet nagaat of het model te misleiden is. Dat is het bijna altijd. De test meet wat er gebeurt als het lukt. Leest de aanvaller dan klantgegevens van iemand anders, laat die een mail versturen of een record wijzigen, of blijft het bij een vreemd antwoord? Het verschil tussen die drie is het verschil tussen een curiositeit en een datalek. Niemand stopt met het testen van webtoepassingen omdat fouten in software onvermijdelijk zijn.
Wat vindt een pentest in een AI-toepassing?
Een AI-pentest volgt de OWASP Top 10 for LLM Applications 2025. De tabel vertaalt elk risico naar een gewone kmo-toepassing en naar wat de tester concreet nagaat.
| Code | Risico | In een kmo-toepassing | Wat de test nagaat |
|---|---|---|---|
| LLM01 | Prompt Injection | Een klant of een document stuurt de chatbot een andere kant op | Weerstand tegen directe en indirecte injectie, ook via uploads en documentbronnen |
| LLM02 | Sensitive Information Disclosure | De chatbot geeft klantgegevens, interne afspraken of sleutels prijs | Of gerichte vragen gevoelige gegevens opleveren |
| LLM03 | Supply Chain | Een model, plug-in of koppeling van een derde partij is aangetast | Herkomst en rechten van modellen, bibliotheken en koppelingen |
| LLM04 | Data and Model Poisoning | Iemand plaatst een vals document in de kennisbank | Wie documenten kan toevoegen en wat het model daarmee doet |
| LLM05 | Improper Output Handling | Het antwoord van het model gaat ongefilterd naar de browser of de backend | Cross-site scripting of injectie via de output |
| LLM06 | Excessive Agency | Een assistent mag mails versturen of gegevens wijzigen | Of een gemanipuleerd model acties uitvoert zonder menselijke bevestiging |
| LLM07 | System Prompt Leakage | Interne instructies en regels lekken naar gebruikers | Of de systeemprompt te achterhalen is en of er geheimen in staan |
| LLM08 | Vector and Embedding Weaknesses | Zoeken in documenten negeert wie welk document mag zien | Of een gebruiker via de chatbot documenten van een andere afdeling of klant te zien krijgt |
| LLM09 | Misinformation | Een fout antwoord wordt een toezegging aan een klant | Of de toepassing bronnen toont en haar grenzen aangeeft |
| LLM10 | Unbounded Consumption | Iemand jaagt het verbruik en de kosten op | Limieten op sessies, tokens en herhalingen |
De zwaarste bevindingen zitten zelden in het model zelf. Ze zitten in LLM08 en LLM06: een zoekfunctie die documenten ophaalt zonder te kijken wie de vraag stelt, en een assistent met meer rechten dan zijn taak vraagt. IBM stelde in zijn Cost of a Data Breach Report 2025 vast dat 13 procent van de organisaties een inbreuk op AI-modellen of -toepassingen meldde, en dat 97 procent van die groep geen degelijke toegangscontrole op AI had. Voor agents die zelf acties plannen, publiceerde OWASP daarnaast een Top 10 for Agentic Applications voor 2026, met onder meer het kapen van het doel van een agent en het misbruik van tools. Hoe u de koppelingen achter zo’n agent beveiligt, leest u in ons artikel over API-beveiliging.
Welke incidenten met AI-toepassingen zijn al publiek?
| Product | Datum | Wat er gebeurde | Bron |
|---|---|---|---|
| Microsoft 365 Copilot (EchoLeak, CVE-2025-32711) | Juni 2025 | Een e-mail met verborgen instructies kon Copilot gegevens laten wegsluizen, zonder klik van de gebruiker. CVSS 9.3. Microsoft loste het op aan zijn kant; misbruik werd niet vastgesteld. | Microsoft, Aim Security |
| Slack AI | Augustus 2024 | Een verborgen instructie in een publiek kanaal liet Slack AI in een demonstratie gegevens uit privékanalen lekken. | PromptArmor |
| GitHub Copilot (CVE-2025-53773) | Augustus 2025 | Instructies in codebestanden konden instellingen van de ontwikkelomgeving wijzigen en code laten uitvoeren. CVSS 7.8. | Microsoft |
| Chatbot van Air Canada | Februari 2024 | De chatbot gaf foute informatie over een tarief. Het tribunaal hield de luchtvaartmaatschappij aansprakelijk voor wat haar chatbot beloofde. | Moffatt v. Air Canada, 2024 BCCRT 149 |
Het patroon is telkens hetzelfde: de aanval zat niet in het model, maar in wat de toepassing het model liet lezen of doen. Een publiek bevestigd Belgisch geval vonden we niet.
Hoe verloopt een AI-pentest?
- Dreigingsmodel en architectuur. Welke documenten kan het model zien, welke tools mag het aanroepen, wie zijn de gebruikers en wat mogen ze zeker niet zien? Dat is de vertaling van threat modeling naar AI.
- Verkenning. De tester brengt endpoints, koppelingen en documentbronnen in kaart.
- Geautomatiseerde tests. Tools zoals garak, PyRIT en promptfoo testen snel een breed scala aan bekende aanvalspatronen.
- Manuele aanvalsketens. De tester combineert stappen, bijvoorbeeld een document met verborgen instructies dat leidt tot een actie onder de sessie van een andere gebruiker. Dat vraagt menselijk inzicht.
- Rapport, herstel en hertest. Elke bevinding komt met bewijs en hersteladvies, en na de aanpassingen volgt een hertest.
De test draait bij voorkeur op een acceptatieomgeving met testdata. Een AI-pentest is een verdieping van een gewone applicatietest: authenticatie en sessiebeheer blijven even belangrijk, zoals we uitleggen in ons artikel over de applicatiepentest. Een bredere oefening die ook mensen en detectie test, is red teaming; het verschil leest u in ons artikel over red teaming of pentest.
Scopechecklist voor een AI-pentest
- Welke modellen en endpoints zijn in gebruik, en via welke leverancier?
- Deelt u de systeemprompt met de tester (grey box), of moet de tester die zelf achterhalen (black box)? Grey box levert bij dezelfde inspanning meer op.
- Welke documentbronnen zijn gekoppeld, en bevatten die testdata of echte gegevens?
- Welke tools, API’s en koppelingen mag de AI aanroepen, en met welke rechten?
- Minstens twee gebruikersrollen, zoals bezoeker en ingelogde klant, of medewerker en beheerder, om te testen of de ene rol gegevens van de andere te zien krijgt.
Plan ook een hertest na elke wissel van model. Een nieuwe modelversie leest dezelfde instructies anders, en wat vorige maand standhield, kan na een update anders uitpakken.
“Wij gebruiken een model van een grote leverancier”
Grote leveranciers investeren veel in de veiligheid van hun modellen, en een kmo kan dat niet evenaren. Toch haalt dit bezwaar twee dingen door elkaar. De leverancier beveiligt het model en zijn infrastructuur. De leverancier weet niet dat medewerker A het loonbriefje van medewerker B niet mag zien, of dat uw assistent geen bestellingen mag annuleren. Die regels leven in uw toepassing, en daar ligt ook de verantwoordelijkheid.
Welke maatregelen neemt een ontwikkelteam?
- Autorisatie vóór het ophalen. Filter in de zoekopdracht naar de documentbron op gebruiker en klant, zodat het model alleen ziet wat de gebruiker sowieso mag zien. Laat autorisatie nooit over aan een instructie in de prompt.
- Minimale rechten voor tools. Een assistent die vragen beantwoordt, heeft leesrechten nodig, geen schrijfrechten op de productiedatabase.
- Menselijke bevestiging. Acties met gevolgen, zoals een betaling, een verwijdering of een mail naar een klant, zet de AI klaar, maar een mens keurt ze goed.
- Output als onbetrouwbare invoer. Codeer het antwoord vóór het in een browser verschijnt en valideer gestructureerde output tegen een vast schema.
- Limieten. Begrens tokens per sessie, lengte van invoer en het aantal herhalingen van een agent.
- Logging. Leg beslissingen en tool-aanroepen vast voor onderzoek, maar filter persoonsgegevens eruit.
- Geen geheimen in de systeemprompt. Ga ervan uit dat die vroeg of laat uitlekt.
Hoe u zulke controles vanaf het ontwerp inbouwt, leest u in ons artikel over de secure development lifecycle. De klassieke risico’s van webtoepassingen, zoals cross-site scripting, staan in ons overzicht van de OWASP Top 10 voor 2026.
Uw AI-functie testen vóór de lancering?
Cyberplan neemt AI-functies mee in een applicatiepentest: de chatbot, de documentbronnen, de koppelingen en de rechten erachter, op een omgeving en binnen een scope die u vooraf goedkeurt. In een kennismakingsgesprek bekijken we wat uw toepassing doet en wat een test zinvol maakt. Meer over onze aanpak leest u op onze pagina over de applicatiepentest.
Veelgestelde vragen
Wat is het verschil tussen directe en indirecte prompt injection?
Bij directe prompt injection typt een aanvaller zelf instructies in het chatvenster om de regels van de toepassing te omzeilen. Bij indirecte prompt injection zitten de instructies verstopt in een document, e-mail of webpagina die de AI-toepassing verwerkt. De gebruiker merkt dan niets, terwijl het model de verborgen opdracht uitvoert.
Kan prompt injection volledig opgelost worden?
Waarschijnlijk niet. Volgens het Britse NCSC maken taalmodellen geen harde scheiding tussen instructies en gegevens, waardoor prompt injection misschien nooit volledig te verhelpen is. De verdediging zit daarom in het beperken van de gevolgen: wat het model mag zien, welke acties het mag uitvoeren en hoe de output verwerkt wordt.
Wat test een pentester bij een chatbot?
Een pentester test of de chatbot te misleiden is, maar vooral wat er dan gebeurt. Krijgt een gebruiker documenten of gegevens van een ander te zien, lekt de systeemprompt, kan de chatbot acties uitvoeren zonder bevestiging, en leidt het antwoord tot scripts in de browser? De OWASP Top 10 for LLM Applications is het kader.
Beveiligt de leverancier van het taalmodel mijn toepassing?
Nee. De leverancier beveiligt het model en zijn eigen infrastructuur. Wie welke gegevens mag zien, welke tools de AI mag gebruiken en hoe de output in uw software terechtkomt, bepaalt uw toepassing. Fouten in die autorisatie en die koppelingen vallen onder de verantwoordelijkheid van het bedrijf dat de AI integreert.
Wanneer laat u een AI-toepassing opnieuw testen?
Na elke wissel van model, na nieuwe koppelingen met tools of documentbronnen, en na grote wijzigingen in de rechten van gebruikers. Een nieuwe modelversie kan dezelfde instructies anders interpreteren, waardoor maatregelen die eerder werkten plots minder goed standhouden. Een hertest bevestigt dat de beveiliging nog klopt.
