Cybersecurity en AI agents: de risico's die elk MKB-bedrijf moet kennen

AI agents die offertes opstellen, mails beantwoorden of facturen verwerken, leveren MKB-bedrijven tijd en efficiëntie op. Maar elke agent die toegang heeft tot je mailbox, CRM of boekhouding is ook een nieuw digitaal 'personeelslid' met inloggegevens, rechten en gedrag dat niet altijd voorspelbaar is. Beveiligingsonderzoekers waarschuwen dat deze zogeheten non-human identities inmiddels een van de belangrijkste toegangspoorten voor aanvallers vormen. Dit artikel bespreekt welke risico's AI agents specifiek introduceren, hoe je gevoelige data beschermt, wat prompt injection is, hoe je toegangsrechten minimaliseert en hoe je afwijkend gedrag opspoort — met verwijzingen naar NCSC, Digital Trust Center, ISO 27001, de OWASP LLM Top 10 en de NIS2-richtlijn.

Welke nieuwe beveiligingsrisico's introduceren AI agents in een MKB-omgeving?

Een AI agent verschilt fundamenteel van een chatbot: hij voert zelfstandig acties uit, roept externe systemen aan en neemt soms beslissingen zonder menselijke tussenkomst. Dat maakt de risico's anders dan bij traditionele software. Het Britse NCSC noemt drie concrete risicogebieden bij AI-gebruik op de werkvloer. Zo kan gevoelige bedrijfs- of klantdata uitlekken, met kans op verlies van intellectueel eigendom en het niet halen van wettelijke eisen, en verliezen organisaties zicht op hun eigen informatie omdat gegevens die in consumentendiensten belanden kunnen worden bewaard of gebruikt om het model te verbeteren, buiten de eigen governance om. Het derde risicogebied draait specifiek om AI-agents: complexe softwarecomponenten met mogelijke kwetsbaarheden.

Een groot deel van dit risico ontstaat doordat medewerkers zelf AI-tools inzetten zonder medeweten van IT — 'shadow AI'. Onderzoek waar het NCSC naar verwijst laat zien dat 71 procent van de werknemers AI-tools gebruikt die niet zijn goedgekeurd door de werkgever. In Nederland blijkt uit eerder onderzoek dat een op de vijf werknemers zelfs zelf AI-tools aanschaft voor het werk. Daarnaast groeit het aantal 'niet-menselijke identiteiten' — service-accounts, API-sleutels en AI-agents — explosief, en die krijgen vaak niet dezelfde controle als een menselijk account. Non-human identities (NHI's) – de AI-agents, service accounts, API-sleutels en authenticatietokens die verbinding maken met interne systemen – zijn volgens onderzoek de meest gebruikte route voor aanvallers de organisatie binnen, en compromised NHI's zijn bijna twee keer zo vaak het primaire toegangspunt als phishing. Voor een MKB-bedrijf met beperkte IT-capaciteit is dat een fors risico, omdat elke nieuwe agent in feite een nieuw account met eigen rechten en kwetsbaarheden toevoegt.

Hoe voorkom je dat een AI agent toegang krijgt tot gevoelige bedrijfsdata?

Het belangrijkste uitgangspunt is dat een AI agent nooit standaard toegang moet krijgen tot meer data dan strikt noodzakelijk voor de taak. Het NCSC wijst erop dat ook het gebruik van generatieve AI door werknemers risico's met zich meebrengt: gevoelige informatie kan op servers buiten je organisatie belanden. Concreet betekent dit voor het MKB:

• Gebruik zakelijke, afgeschermde AI-omgevingen in plaats van gratis consumentenversies waarvan de invoer kan worden hergebruikt voor modeltraining.
• Koppel een agent alleen aan de specifieke systemen (bijvoorbeeld één mailbox-map of één CRM-module) die nodig zijn voor zijn taak, niet aan de volledige omgeving.
• Verplicht menselijke goedkeuring voor onomkeerbare acties. Menselijke goedkeuring is verplicht voordat een AI-agent een e-mail verstuurt, een betaling initieert of gegevens deelt buiten je organisatie.
• Classificeer data vooraf (openbaar, intern, vertrouwelijk) en sluit vertrouwelijke categorieën standaard uit van agent-toegang.
• Leg vast welke leverancier de onderliggende AI-dienst levert en waar data wordt verwerkt en opgeslagen — essentieel bij een eventuele AVG-toets of NIS2-ketenbeoordeling.

Een positieve securitycultuur helpt hierbij minstens zoveel als techniek. Het NCSC adviseert een positieve securitycultuur waarin open gesprekken over beveiliging ervoor zorgen dat medewerkers minder snel naar niet-goedgekeurde diensten grijpen, gecombineerd met het veilig integreren van AI-systemen op de werkvloer.

Wat is prompt injection en hoe bescherm je je daartegen?

Prompt injection is inmiddels het bekendste en meest genoemde beveiligingsrisico specifiek voor AI-taalmodellen en agents, en staat niet voor niets bovenaan de OWASP LLM Top 10. Een prompt injection-kwetsbaarheid ontstaat wanneer prompts het gedrag of de output van een LLM op onbedoelde wijze veranderen; deze invoer hoeft niet zichtbaar of leesbaar te zijn voor mensen, zolang de inhoud door het model wordt verwerkt. Er zijn twee varianten: prompt injection kan direct optreden wanneer een gebruiker kwaadaardige instructies in de chat typt, of indirect wanneer het model onvertrouwde inhoud leest uit websites, documenten, e-mails, tickets, coderepositories of kennisbanken.

Een praktijkvoorbeeld: een aanvaller past een document aan in een repository die wordt gebruikt door een RAG-toepassing; wanneer de zoekopdracht van een gebruiker die aangepaste inhoud teruggeeft, verandert de kwaadaardige instructie de output van het model en genereert misleidende resultaten. Voor een AI agent die e-mails leest of documenten samenvat, betekent dit dat een verborgen instructie in een binnenkomende factuur, e-mail of bijlage de agent kan aanzetten tot ongewenst gedrag — bijvoorbeeld het doorsturen van gegevens of het uitvoeren van een betaling.

Bescherming tegen prompt injection

• Behandel alle externe input (e-mails, documenten, webpagina's) als onvertrouwd, ook als die van een bekende afzender lijkt te komen.
• Scheid systeeminstructies strikt van gebruikersinvoer en valideer output voordat een agent een actie uitvoert.
• Beperk wat een agent kan doen na het lezen van externe content (bijvoorbeeld: nooit automatisch geld overmaken op basis van tekst uit een e-mail).
• Gebruik gespecialiseerde filters of monitoring die verdachte instructiepatronen detecteren in binnenkomende content.
• Raadpleeg de OWASP LLM Top 10 en de bijbehorende cheat sheets als vast onderdeel van elke AI-implementatie, ook als je geen eigen ontwikkelaars hebt maar een kant-en-klare oplossing inkoopt.

Welke toegangsrechten moet je een AI agent minimaal geven (least privilege)?

Het least-privilege-principe — nooit meer rechten geven dan strikt nodig — is voor AI agents nog belangrijker dan voor menselijke gebruikers, omdat agents sneller, autonomer en op grotere schaal kunnen handelen dan een mens. Zodra een AI agent in productie wordt gezet, ontstaat een nieuw type gebruiker: een identiteit die authenticeert, API-sleutels vasthoudt, de database leest en namens een klant handelt, zonder gezicht, laptop of werkdag. Traditionele rechtenmodellen zijn hier niet op ingericht.

De praktijk beweegt daarom richting contextgebonden autorisatie in plaats van vaste rollen. De verschuiving is richting intent-based access: autoriseer de actie in context, niet alleen de identiteit. De vraag wordt of deze agent, handelend namens deze gebruiker, op dit moment toestemming heeft om deze specifieke actie uit te voeren — bijvoorbeeld een terugbetalingsagent die tot 50 euro automatisch mag terugbetalen, grotere bedragen moet doorzetten naar een mens, en nooit een uitbetaling mag aanraken waar niet naar is gevraagd. Die grenzen liggen vast in beleid dat op het moment van de actie wordt gecontroleerd.

Concreet betekent dit voor het MKB:

Type taak	Minimale rechten
E-mail samenvatten of concept opstellen	Leesrechten op specifieke mailbox, geen verzendrechten
Factuurverwerking	Alleen invoeren in boekhoudsysteem, geen goedkeuringsrecht voor betalingen
Klantcontact via chatbot	Toegang tot FAQ- en orderdata, geen toegang tot betaalgegevens of wachtwoorden
Interne kennisbank doorzoeken	Alleen documenten binnen het eigen team, geen bedrijfsbrede zoekopdracht

Behandel elke agent als een apart account met eigen, tijdelijke en beperkte inloggegevens in plaats van als verlengstuk van een bestaand medewerkersaccount, en verwijder of deactiveer die toegang direct zodra een agent niet meer wordt gebruikt. Ga er daarbij vanuit dat een agent gecompromitteerd of misleid kan worden — prompt injection is een reëel risico — en richt de omgeving zo in dat zelfs een misleide agent niet verder kan komen dan zijn afgebakende taak.

Hoe monitor je het gedrag van een AI agent op afwijkingen of misbruik?

Monitoring is misschien wel de zwakste schakel in de praktijk. Onderzoek laat zien dat organisaties structureel te weinig zicht hebben op wat hun agents daadwerkelijk doen. Een onderzoek van de Cloud Security Alliance vond dat 68 procent van de organisaties niet betrouwbaar onderscheid kan maken tussen de activiteit van een AI-agent en die van een mens, en dat 80 procent van de IT-leiders agents heeft zien handelen buiten hun verwachte gedrag. Nog opvallender: 95 procent van de organisaties denkt zicht te hebben op hun AI- en machine-identiteitsrisico's, terwijl slechts 36 procent die daadwerkelijk monitort.

Praktische stappen voor MKB-monitoring:

• Log elke actie die een agent onderneemt (welk systeem, welke data, welk resultaat) en bewaar die logs net zo lang als je andere beveiligingslogs.
• Stel drempelwaarden in: een agent die plotseling veel meer records opvraagt, buiten kantooruren actief is, of ongebruikelijke systemen aanroept, moet een alert genereren.
• Voer periodieke steekproeven uit op agent-output, vooral bij taken met financiële of juridische impact.
• Wijs één verantwoordelijke aan (ook in een klein bedrijf) die logs beoordeelt en incidenten opvolgt.
• Neem AI-gerelateerde incidenten op in je bestaande incidentresponsplan, inclusief het protocol voor melding bij het NCSC.

NCSC, Digital Trust Center, ISO 27001 en NIS2: het wettelijk en institutioneel kader

Nederlandse MKB-bedrijven kunnen voor ondersteuning terecht bij het Nationaal Cyber Security Centrum (NCSC). Sinds kort is deze rol nog centraler geworden: het Digital Trust Center is op 1 januari 2026 opgegaan in het NCSC, en richtte zich als doelgroep op 2,2 miljoen bedrijven — van zzp'er tot groot bedrijf — die niet tot de vitale sectoren zoals banken, telecom, energie en water behoren. Dat maakt het NCSC nu het centrale aanspreekpunt voor zowel vitale als niet-vitale organisaties op het gebied van AI-risico's, dreigingsinformatie en praktisch advies.

Op wetgevingsvlak is de NIS2-richtlijn het belangrijkste kader. Deze Europese cybersecurityrichtlijn wordt in Nederland omgezet in de Cyberbeveiligingswet. De Cyberbeveiligingswet treedt op 15 augustus 2026 in werking, waarna nieuwe verplichtingen gelden voor organisaties die onder de wet vallen. Voor het MKB is vooral de indirecte impact relevant: MKB-bedrijven met minder dan 50 medewerkers vallen er vaak niet direct onder, maar wel indirect via hun klanten, omdat NIS2 direct geldt voor middelgrote en grote organisaties in kritieke sectoren maar via de keten ook duizenden kleinere bedrijven raakt. De kernverplichtingen zijn helder omschreven: zorgplicht (tien maatregelen), meldplicht (24 uur), registratieplicht en leveranciersverantwoordelijkheid. Onder de zorgplicht vallen concrete maatregelen die direct raken aan AI-agentbeveiliging: risicoanalyse, een plan voor als er iets misgaat, toegangsbeheer, multifactorauthenticatie (MFA), beveiliging van leveranciers, encryptie, medewerkerstraining en actueel houden van systemen. Ernstige incidenten — ook als een AI agent daarbij betrokken is — moeten worden gemeld: onder NIS2 ben je verplicht een ernstig incident binnen 24 uur te melden bij het NCSC.

ISO 27001 is geen wettelijke verplichting, maar wel een waardevol fundament. De Cyberbeveiligingswet verplicht organisaties niet om ISO 27001-gecertificeerd te zijn, maar de norm biedt een uitstekende basis voor het inrichten van informatiebeveiliging, en veel onderdelen sluiten nauw aan op de eisen uit de Cyberbeveiligingswet, zoals risicomanagement, managementbetrokkenheid, continue verbetering en informatiebeveiligingsbeleid. Voor een MKB-bedrijf dat AI agents structureel inzet, is een ISO 27001-achtige aanpak — ook zonder volledige certificering — een praktische manier om AI-risicobeheer aantoonbaar te maken richting klanten en toezichthouders.

Tot slot is de OWASP LLM Top 10 het referentiekader voor technische AI-risico's. Dit rapport identificeert de belangrijkste beveiligingsrisico's in AI-systemen, waaronder prompt injection, datalekken, supply chain-aanvallen, model poisoning, buitensporige agent-rechten, misinformatie en resource abuse, en benadrukt dat niet alleen het model maar ook de data, tools, integraties en workflows eromheen beveiligd moeten worden. Voor MKB-bedrijven die AI-oplossingen inkopen, is het zinvol om leveranciers te vragen of en hoe zij deze risico's afdekken.

Praktisch stappenplan voor MKB

• Breng in kaart welke AI-tools en agents nu al binnen je organisatie worden gebruikt, inclusief schaduw-AI.
• Stel per agent een minimale rechtenset op volgens het least-privilege-principe en leg dit vast.
• Verplicht menselijke goedkeuring bij financiële, juridische of extern gerichte acties.
• Richt logging en alerting in voor afwijkend agentgedrag, ook als je geen eigen SOC hebt.
• Toets nieuwe AI-leveranciers aan de OWASP LLM Top 10 en vraag naar hun beveiligingsmaatregelen.
• Volg de NCSC-richtlijnen en bereid je voor op de Cyberbeveiligingswet, ook als je er niet direct onder valt.

AI agents zijn geen reden om automatisering te vermijden, maar wel om beveiliging vanaf de eerste implementatie serieus mee te nemen. Een agent die zonder controle mag handelen, is in de praktijk een extra medewerker zonder toezicht — en dat risico is met een paar concrete maatregelen goed te beheersen.