AI & LLM Security in de praktijk: de complete gids

Kort antwoord

AI-security is het beveiligen van systemen waarin taalmodellen een rol spelen. De kern van het probleem: een taalmodel maakt van nature geen onderscheid tussen instructies en gegevens. Alles wat in de context verschijnt, kan als opdracht worden gelezen, ook als het bedoeld was als invoer. Daardoor blijven de klassieke beveiligingsprincipes onverkort geldig, maar moet je ze op nieuwe onderdelen toepassen: de prompt, de context, de databronnen en de tools die het model mag aansturen.

Waarom iedereen het erover heeft (en waarom security meestal achteraan komt

Volg de vergaderingen van een willekeurige Nederlandse organisatie en je hoort hetzelfde: er moet “iets met AI”. Een chatbot op de website, een copilot voor het supportteam, een agentic assistent die zelfstandig mailt en agenda’s beheert. En terecht, want de techniek werkt. Het probleem is alleen de volgorde. De functie wordt bedacht, gebouwd en live gezet, en pas daarna, als er iets gruwelijk misgaat, komt de vraag: “moeten we hier eigenlijk iets aan beveiligen?”

Dit artikel is het fundament. Het legt uit waarom AI-systemen een ander aanvalsoppervlak hebben dan klassieke software, hoe dat aanvalsoppervlak er uitziet, welke risicocategorieën er volgens de OWASP-standaarden echt toe doen, en welke verdedigingslagen in de praktijk werken. De diepgaande artikelen over de drie grootste risico’s, prompt injection, datalekken via LLM-systemen en zelfstandig handelende AI-agenten, hangen aan deze hubpagina en worden hieronder gelinkt.

Waarom AI-security anders is dan applicatie-security

Klassieke software is deterministisch. Een webformulier dat een e-mailadres verwacht, kan elk veld controleren tegen een strak patroon: hier een apenstaartje, daar een punt, verder niks. De stap tussen “toegestane invoer” en “geweigerde invoer” is hard en afdwingbaar, omdat jij als bouwer de grammatica van de invoer definieert.

Een taalmodel draait dat principe om. De interface is natuurlijke taal, en natuurlijke taal heeft geen vaste grammatica die je kunt afdwingen. Erger nog: het model zelf moet úítmaken wat instructie is en wat gegeven. Zet je de gebruikersvraag, de systeeminstructies en drie opgehaalde documenten in dezelfde context, dan is er technisch geen enkele grens die zegt: “dit stuk is van de gebruiker en betekent letterlijk wat er staat, en dat stuk is documentatie en moet alleen worden samengevat.”

Drie eigenschappen maken het model daardoor een geliefd aanvalsdoel:

Invoer is ook programma. De prompt is tegelijk data en besturing. Iemand die jouw RAG-pijplijn voedt met een “handig” samengevat document, schrijft feitelijk mee aan de instructies die jouw model volgt. Dit is dezelfde kernkwetsbaarheid als klassieke commando-injectie, maar dan in vloeibare, natuurlijke taal in plaats van shell-syntax. Wie onze analyse van de HNAP-commando-injectie heeft gelezen, herkent het patroon: één invoerveld dat twee rollen speelt.

De output is niet gegarandeerd. Een functie die 99 van de 100 keer correcte SQL genereert, is geen correcte functie, maar een dobbelsteen met goede marketing. Alles wat je met modeloutput doet, insluiten in HTML, in SQL, in een shell-commando, in een API-call, moet daarom worden gevalideerd alsof het vijandige invoer is. Dat is het ook.

De aanspreekbaarheid is vaag. Als een agent een foutieve actie uitvoert, is de vraag niet “welke regel in de code was fout” maar “welke redenering van het model was fout”, en dat antwoord is niet reproduceerbaar. Dat maakt forensisch onderzoek, auditing en aansprakelijkheid lastiger dan bij traditionele software.

Maar, en dat is de geruststellende boodschap: het feit dat de mechaniek nieuw is, betekent niet dat de beveiligingsleer nieuw is. Least privilege, defense in depth, validatie aan de grenzen, logging en monitoring: het blijft exact hetzelfde gereedschap. Je past het alleen toe op onderdelen die vijf jaar geleden niet bestonden.

Het aanvalsoppervlak van een LLM-systeem, onderdeel voor onderdeel

Een modern LLM-systeem is zelden “gewoon een chatbox”. Het is een keten van onderdelen, en elk onderdeel heeft zijn eigen dreigingen.

De prompt van de gebruiker. Directe invoer van een onbekende partij. Hier woont de klassieke prompt injection: de gebruiker probeert de systeeminstructies te negeren, te onthullen of te overschrijven.

De systeeminstructies. Vaak worden hier gevoelige zaken in gestopt: API-sleutels, bedrijfslogica, algoritmes voor prijsbepaling of risicoscreening. System prompt leakage is dus een confidentiality-probleem, geen “leuk bugje”.

De context en bronnen (RAG). Haalt jouw model informatie op uit webpagina’s, PDF’s, tickets of mailboxen? Dan is al dat materiaal óók invoer die als instructie kan worden gelezen. Dit heet indirecte prompt injection en het is in de praktijk de gevaarlijkste variant, omdat de aanvaller niet eens jouw interface hoeft te raken. Een vergiftigde webpagina die jouw bot later bezoekt, volstaat.

De tools en plugins. Mag het model e-mails versturen, bestanden lezen, betalingen initiëren of servers beheren? Dan heeft je taalinterface ineens handen. De security van het hele systeem is dan niet groter dan de rechten van de domst mogelijke tool-call.

De output. Modeloutput belandt vaak ongefilterd in een volgende laag: een webpagina (XSS), een database (SQL-injectie), een terminal of een API. De output van een model moet worden behandeld als onbetrouwbare invoer van buiten.

De pijplijn zelf. De modelgewichten die je downloadt, de Python-packages van je framework, de third-party API’s en vectorstores: je AI-stack is een supply chain, net zo goed als je npm-dependencies. Onbekende actoren met goede marketing horen daar helaas bij.

De mens. Wie de output van een model klakkeloos overneemt, is zelf de kwetsbaarheid. Social engineering werkt in 2026 net zo goed als in 2015, alleen nu met geloofwaardigere tekst.

De OWASP Top 10 voor LLM-applicaties

De OWASP GenAI Security Project brengt sinds 2023 de Top 10 voor LLM-applicaties uit, in 2026 in een vernieuwde versie die is afgestemd op wat er de afgelopen jaren écht is misgegaan, en daarnaast een nieuwe Top 10 specifiek voor agentische applicaties. De LLM-lijst in het kort:

  • LLM01: Prompt injection – invoer die de instructies van het systeem overschrijft
  • LLM02: Sensitive information disclosure – het model verklapt gegevens die het niet had mogen delen
  • LLM03: Excessive agency – het model mag en doet meer dan de taak vereist
  • LLM04: Supply chain – vergiftigde modellen, packages en componenten
  • LLM05: Data en model poisoning – trainings- of brondata die subtiel is gemanipuleerd
  • LLM06: Unbounded consumption – bronuitputting door misbruik (kosten, rekenkracht)
  • LLM07: Misinformation – hallucinaties en overtuigende onzin
  • LLM08: Hidden context exposure – gevoelige gegevens die onzichtbaar in contexten doorreizen
  • LLM09: Multimodal kwetsbaarheden – aanvallen via beeld, audio en andere modaliteiten
  • LLM10: Model theft en misuse – model-exfiltratie en misbruik van aangeraakt IP

In de praktijk clusteren de incidenten van de afgelopen jaren vooral rond drie categorieën, en die drie vormen de pijlers van dit cluster op hackerscollectief.nl.

Pijler 1: Aanvallen op de logica (prompt injection)

De meest actieve aanvalscategorie. De aanvaller communiceert niet met je server, maar met je model, en probeert het te laten doen wat híj wil in plaats van wat jóuw applicatie wil. Direct, via de eigen interface, of indirect, via een bron die jouw systeem later inleest. Het verschil tussen beide varianten is het belangrijkste concept dat je moet snappen: bij directe injectie is de aanvaller de gebruiker, bij indirecte injectie is de aanvaller een derde die langs de weg iets neerlegt.

Waarom faalt klassieke input-validatie hier, en welke verdediging werkt dan wél? Dat lees je in het diepgaande artikel: Prompt injection: hoe aanvallen op taalmodellen werken.

Pijler 2: Data en privacy (sensitive information disclosure)

Het tweede praktijkrisico is confidentiality. Modellen verklappen: gevoeligheden uit trainingdata, uit documenten die iemand “even snel” in de context plakte, of uit een RAG-pijplijn die personeelsdossiers en klantgegevens aan iedereen beschikbaar stelt die de juiste vraag stelt. De vectorstore die jouw kennisbank sneller maakt, kent geen autorisatie; die zit in een laag die de meeste bouwers overslaan.

Hoe je die laag wél bouwt, wat data poisoning is en wanneer zelf hosten wel en niet helpt, lees je in: Data en privacy bij LLM’s: lekken, RAG-security en verdediging.

Pijler 3: Autonomie (excessive agency)

De derde categorie is de jongste en de snelst groeiende. Steeds meer systemen zijn geen vraag-en-antwoord-machine meer, maar een agent: het model denkt, kiest een actie, voert die uit via tools en kijkt naar het resultaat. Koppeldat aan een mailbox, een CRM of een cloudconsole, en je hebt een systeem dat niet alleen advies geeft, maar beslissingen uitvoert. Eén injectie in een ontvangen e-mail, en je assistent werkt voor de aanvaller, met de rechten die jij hem hebt gegeven.

Waarom “excessive agency” hét risico van dit moment is, en hoe je een agent in bedwang houdt met least privilege, bevestigingsmomenten en kill switches: AI-agents en excessive agency: als modellen zelf gaan handelen.

Wat wél blijft werken: de klassieke principes

AI verandert het aanvalsoppervlak, niet de beveiligingsleer. Vijf principes doen al het werk:

Least privilege, nu ook voor tools. Geef een agent nooit een API-sleutel met breder bereik dan de taak vereist. Een mail-assistent hoeft alleen mails te kunnen versturen op naam van één account, en niet het hele adresboek te kunnen uitkopen.

Defense in depth, zonder heilige lagen. Een guardrail in de prompt is een filter, geen muur. Verdediging die werkt, zit in meerdere lagen achter elkaar: bronfiltering, toolbeperking, outputvalidatie en menselijke controle.

Validatie aan de grenzen. Alle invoer die het model bereikt (gebruiker én bronnen) is onbetrouwbaar, en alle output die het model verlaat is onbetrouwbaar. Laat de ene laag de andere niet ongefilterd vertrouwen; het model zelf is de minst betrouwbare schakel in de keten.

Logging en monitoring. Wat vroeg het model, welke bronnen laadde het in, welke tools riep het aan, met welke argumenten? Zonder die log heb je geen incidentrespons, alleen een schouderophalen.

Zero trust voor context. Elke bron die je systeem inleest, kan gemanipuleerd zijn. Behandel een opgehaalde webpagina met dezelfde argwaan als een gebruikersinvoer: alsof er een aanvaller in meeschrijft. Vaak is dat ook zo.

Praktische verdedigingsarchitectuur

Van principes naar lagen. Een verdedigingsopzet die in de praktijk standhoudt, ziet er globaal zo uit:

1. Toegangscontrole – wie mag het model gebruiken, met welke data en vanuit welke rol? Authenticatie en autorisatie vóór de prompt, niet erna. 2. Bronfiltering – de RAG-pijplijn haalt uit goedgekeurde, gecontroleerde bronnen, met een autorisatiecheck op het moment van ophalen, niet op het moment van genereren. 3. Toolbeheersing – tools zijn ge-whitelist, per scope begrensd, en rate-limited. Destructieve acties bestaan bij voorkeur helemaal niet in de toolset. 4. Menselijke bevestiging – alles wat onomkeerbaar is (versturen, wissen, betalen) passeert een mens. Dat is geen gebrek aan vertrouwen, maar gezond verstand. 5. Outputvalidatie – modeloutput wordt geformatteerd, gesanitiseerd en gecheckt vóór het ergens in belandt, van HTML tot SQL tot JSON. 6. Monitoring en incidentrespons – logs van elke prompt, context en tool-call; waarschuwingen bij afwijkend gedrag, zoals onverwachte tool-keuzes of in volume toenemende acties.

Daaromheen geldt de governance die voor Nederlandse organisaties steeds minder vrijblijvend wordt. De Europese AI-wetgeving (AI Act) legt verplichtingen op die deels al gelden, en voor organisaties onder de NIS2 hoort een AI-systeem met toegang tot gevoelige gegevens simpelweg bij de risico-inventarisatie. Wie een LLM op klantgegevens zet, doet er bovendien goed aan vooraf een privacy-impactanalyse te maken. Niet omdat het papier leuk is, maar omdat het je dwingt de vraag te beantwoorden: wat mag dit systeem eigenlijk zien, en voor wie?

Checklist: bouw je veilig met LLM’s?

  • Staat het LLM-systeem in je risicoregister, met eigenaar en dreigingsanalyse?
  • Heeft elke agent en elke tool het kleinst mogelijke bereik (least privilege, per scope)?
  • Passeren destructieve of onomkeerbare acties altijd een menselijke bevestiging?
  • Filter je RAG-bronnen, en controleer je autorisatie op het moment van ophalen?
  • Is er een guardrail- en outputfiltering-laag die onafhankelijk van de prompt werkt?
  • Log je prompts, contexten en tool-calls, en kijk je er structureel naar?
  • Weet je wat er in je systeemprompt staat, en zit daar iets geheims in dat er niet hoort?
  • Is er een kill switch en een plan voor het geval de agent ongewenst gedrag vertoont?
  • Behandel je modeloutput overal als onbetrouwbare invoer (HTML, SQL, shell, API)?
  • Heb je met het team afgesproken wanneer een AI-functie niet live gaat?

Verder lezen in dit cluster

Verder lezen elders op hackerscollectief.nl

De officiële bronnen voor wie verder wil: de OWASP GenAI Security Project-pagina’s met de Top 10 voor LLM-applicaties en de nieuwe lijst voor agentische applicaties.