Zo voorkom je dat je AI agent een security-incident wordt

AI agents zijn krachtig, maar de meeste worden uitgerold zonder fatsoenlijke beveiliging. In dit artikel lopen we in vijf stappen door wat er misgaat en wat je eraan kunt doen: van zero trust en tool-isolatie tot prompt injection, data-exfiltratie en monitoring. Niet vanuit theorie, maar vanuit wat we bij Agentech in de praktijk tegenkomen.

Wat je moet weten voordat het misgaat

Serge — Hoofd Developer Agentech | 2026

Stel je voor dat je net de beste medewerker ooit hebt aangenomen. Iemand die razendsnel werkt, alles kan uitzoeken, met al je systemen overweg kan en dag en nacht doorgaat zonder te klagen. Een droomkandidaat, op papier.

En dan geef je diezelfde medewerker op dag één beheerderstoegang tot álles: geen achtergrondcheck, geen toegangsbeleid, en het wachtwoord staat gewoon in een onbeveiligd configuratiebestand. Dat is hoe de meeste AI agents vandaag worden uitgerold. Het probleem is niet het talent, het is de onboarding.

Bij Agentech bouwen we AI agents voor uiteenlopende organisaties, en we zijn enthousiast over wat deze technologie kan. Maar de afgelopen maanden hebben we ons nadrukkelijk verdiept in de beveiligingskant, en wat we tegenkwamen is zorgwekkend. De kloof tussen wat agents kunnen en hoe organisaties ze beschermen is groot. In dit artikel lopen we het probleem door van begin tot eind, en laten we zien welke stappen je nu al kunt nemen.

Waarom de oude regels hier niet werken

Voordat we bij oplossingen komen, is het belangrijk om te begrijpen waarom de standaard beveiligingsaanpak hier tekortschiet. Agents zijn namelijk geen gewone software.

Een traditionele webapplicatie heeft een vaste UI, gevalideerde API-schema’s en voorspelbaar gedrag. Je weet wat erin gaat en je weet wat eruit komt. Een AI agent gooit alle drie die aannames overboord: hij haalt gevoelige data op op basis van hoe hij taal interpreteert (niet via een vaste query), hij kan API-verzoeken samenstellen waar niemand op had gerekend, hij ketent tools aan elkaar in combinaties die in geen enkele testcase voorkwamen, en als je niet oppast voert hij onomkeerbare acties uit zonder dat iemand bevestigt dat het een goed idee was.

Het kwetsbare oppervlak is daardoor niet langer een bekende set van inputs en outputs, maar een onvoorspelbare mix van taal, logica en actie. En de aanvallen die daarop inspelen zijn niet theoretisch: ze zijn al volop gaande en raken precies de zwakke plekken die je zou verwachten.

In februari 2026 plantte de ClawHavoc-campagne ruim 335 kwaadaardige skills op ClawHub, de belangrijkste marktplaats voor OpenClaw agent-plugins. De aanvallers gebruikten minstens veertien gekaapte developer-accounts om de vergiftigde tools er betrouwbaar uit te laten zien, waarna die skills malware verspreidden en via prompt injection ongemerkt API-sleutels stalen.

Rond dezelfde tijd maakte JFrog CVE-2025-6514 openbaar: een command injection-kwetsbaarheid in het mcp-remote pakket met een CVSS-score van 9.6 op 10. Het pakket was op dat moment ruim 437.000 keer gedownload.

En uit BlackFog-onderzoek van januari 2026 bleek dat 49% van de werknemers bij middelgrote en grote bedrijven AI-tools gebruikt die nooit door hun werkgever zijn goedgekeurd. Dat betekent dat een enorm deel van het AI-gebruik volledig buiten het zicht van security plaatsvindt.

Dit zijn geen uitzonderingen. Het is de nieuwe realiteit, en het vraagt om een nieuw beveiligingsmodel.

Stap 1: Zero trust heroverwegen

De logische plek om te beginnen is zero trust, het meest vertrouwde principe in moderne beveiliging: vertrouw niets standaard, authenticeer elke verbinding en autoriseer elk verzoek. Het probleem is dat zero trust is ontworpen voor netwerkgrenzen, en agents houden zich daar niet aan.

Bij agents is de grens semantisch. Een agent begrijpt taal, context en intentie op een manier die klassieke toegangscontroles niet aankunnen, waardoor de vraag een andere wordt: wat mag de agent zien, wat mag hij doen, en hoeveel mag hij veranderen aan zichzelf en aan de systemen waar hij toegang toe heeft?

Het nuttigste kader dat we zijn tegengekomen komt uit de beveiligingspraktijk van Meta: de “Rule of Two”. Het principe werkt als volgt: voordat een agent een gevoelige actie mag uitvoeren, moeten minstens twee van de volgende drie voorwaarden kloppen. De input komt van een geverifieerde bron, de data is niet gevoelig, of de actie is omkeerbaar en niet-destructief. Klopt er maar één of geen enkele? Dan moet een mens goedkeuring geven.

Die ene regel, consequent toegepast, had een flink deel van de incidenten van het afgelopen jaar kunnen voorkomen.

Daarnaast zijn minimale rechten niet onderhandelbaar. Een agent die klantgegevens opvraagt hoort geen toegang te hebben tot financiële data of broncode. Elke tool hoort in een eigen, afgeschermde omgeving te draaien. En de identiteit van een agent moet je behandelen als een service account: uniek, cryptografisch verifieerbaar, met regelmatige rotatie van credentials en een compleet auditspoor.

Stap 2: De tools onder controle krijgen

MCP-servers (Model Context Protocol) zijn de tools waarmee agents communiceren met externe systemen, en op dit moment vormen ze een van de grootste risicogebieden. De reden is simpel: de manier waarop ze met credentials omgaan is fundamenteel onveilig.

Astrix Security onderzocht meer dan vijfduizend open-source MCP-serverimplementaties en vond dat 88% credentials nodig heeft om te functioneren. Van die 88% vertrouwt meer dan de helft (53%) op onveilige, langlevende statische geheimen zoals API-sleutels en persoonlijke tokens. Slechts 8,3% ondersteunt OAuth. Dat is een structureel probleem, en het zit gewoon in het volle zicht.

Maar het gaat verder dan slechte credentials. De aanvalstechnieken op MCP-servers worden steeds creatiever, en wat ons het meest verontrust is hoe eenvoudig sommige ervan zijn.

Bij tool poisoning krijgt een aanvaller schrijftoegang tot een server en past die aan zodat er stilletjes data weglekt, zonder dat de agent doorheeft dat hij met een gecompromitteerde tool praat. Tool shadowing is nog geraffineerder: je registreert een tool met een naam die bijna identiek is aan een legitieme variant, en het taalkundige begrip van de agent doet de rest.

Dan is er stored prompt injection, waarbij aanvallers kwaadaardige instructies verstoppen in de respons van een MCP-server (in een beschrijvingsveld of documentatie). De agent leest het, en het oorspronkelijke doel wordt overschreven.

En er zijn rug pull attacks: je publiceert een onschuldige tool, wacht tot agents hem vertrouwen, en duwt er vervolgens een update doorheen met kwaadaardige functionaliteit. Elke agent die automatisch bijwerkt is in één klap gecompromitteerd.

De maatregelen zijn niet spectaculair, maar wel onmisbaar: houd een eigen intern register bij van goedgekeurde tools, zet toolversies vast en schakel automatische updates uit, draai elke MCP-server in een geïsoleerde container, gebruik kortlevende tokens in plaats van statische geheimen, en log alles (elke aanroep, elk argument, elke retourwaarde, elke afzender).

Stap 3: Prompt injection: het onopgeloste probleem

Na twee jaar onderzoek is er nog steeds geen waterdichte verdediging tegen prompt injection. We hebben lagen (inputvalidatie, guardrails in systeemprompts, outputfiltering) en die helpen, maar geen ervan is volledig. Iedereen die beweert prompt injection “opgelost” te hebben, verkoopt je iets wat niet bestaat.

Wat wél anders is dan twee jaar geleden: indirecte injection is nu de dominante aanvalsmethode. Aanvallers plaatsen geen kwaadaardige instructies meer in de prompt van de gebruiker, maar verstoppen ze in de databronnen waar de agent uit leest. Denk aan een gecompromitteerde webpagina, een vergiftigde database-entry of een gemanipuleerd document. De agent leest de data, volgt de verborgen instructie, en doet precies wat de aanvaller wilde. Bij multi-agent systemen wordt dat extra gevaarlijk, omdat één gecompromitteerde agent als springplank kan dienen naar elke agent waarmee hij communiceert.

Dat we dit risico niet kunnen elimineren betekent niet dat we machteloos zijn. We kunnen het wél beheersen. Concreet betekent dat: strikte scheiding tussen systeem-instructies en externe data, validatielagen die de output van de agent controleren voordat die wordt uitgevoerd, sandboxing zodat een gecompromitteerde agent niet bij alles kan, en een extra bevestigingsstap voor gevoelige acties, ongeacht wat de agent denkt dat de bedoeling is.

Het verschil tussen elimineren en beheersen is relevant voor iedereen die beslissingen neemt over het uitrollen van agents. Perfecte beveiliging bestaat niet, maar een doordachte aanpak maakt het verschil tussen een beheersbaar incident en een serieus probleem.

Stap 4: Data-exfiltratie voorkomen

Aanvallers gebruiken slimme technieken om data uit agents te trekken, en de meeste traditionele DLP-oplossingen (Data Loss Prevention: software die voorkomt dat gevoelige gegevens je organisatie verlaten) missen ze volledig. Als je vandaag een agent draait die klantdata kan inzien, is de kans reëel dat je bestaande beveiligingstools een datalek niet zouden detecteren. Dat komt doordat die tools zijn gebouwd voor een wereld waarin data via bekende kanalen beweegt, terwijl agents nieuwe kanalen openen die DLP-software nooit heeft leren herkennen.

Een veelgebruikte methode is het injecteren van een markdown image-tag in de output van de agent. Dat ziet eruit als een gewone afbeeldings-URL, maar stuurt in werkelijkheid data naar een server van de aanvaller zodra de respons gerenderd wordt. Een andere methode is het coderen van gevoelige data als base64 of hex voordat het wordt weggeschreven, waardoor het zonder moeite langs elke DLP-scanner glipt die zoekt op leesbare tekst. Een derde variant is de agent opdracht geven om gevoelige data mee te sturen als argumenten bij een toolaanroep, via logs die waarschijnlijk niet goed beveiligd zijn.

De tegenmaatregelen: DLP-scanning die specifiek naar agent-output kijkt (niet alleen naar netwerkverkeer), allowlists voor uitgaande domeinen, rate limiting op datavolume per sessie, en gestructureerde antwoorden afdwingen in plaats van vrije tekst. Dat laatste beperkt de creatieve ruimte die aanvallers misbruiken.

Stap 5: Zien wat je agents doen

Zichtbaarheid voor agents is iets heel anders dan traditionele applicatiemonitoring. Je volgt niet alleen requests en foutpercentages, maar moet ook bijhouden welke doelen de agent heeft gekregen, of die tussentijds zijn gewijzigd, welke tools hij aanroept en met welke data, hoe hij tot beslissingen komt, en of zijn gedrag afwijkt van wat je zou verwachten.

Het concept dat we het meest waardevol vinden is goal monitoring: een agent werkt onder een opgegeven doel, en elke actie zou aantoonbaar richting dat doel moeten werken. Drijft het gedrag af (dat kun je meten met semantische vergelijking) dan is er waarschijnlijk iets mis. Of de agent is verkeerd geconfigureerd, of hij is gecompromitteerd. Hoe dan ook: elke wijziging van het doel zou opnieuw door een mens bevestigd moeten worden.

Dit is ook de plek waar je de aanvallen uit de vorige stappen vangt: onverwachte toolaanroepen uit stap 2, prompt injection uit stap 3, en verdachte datastromen uit stap 4. Als je hier niet op let, kom je er pas achter als de schade al is aangericht.

Hoe wij dit in de praktijk brengen

Tot zover de risico’s en de maatregelen. Maar hoe vertaalt dit zich naar de dagelijkse praktijk? Bij Agentech bouwen we wekelijks agents die toegang hebben tot klantdata, interne systemen en externe API’s. De risico’s uit de stappen hierboven zijn voor ons geen abstracte dreigingen, maar zaken waar we actief tegenaan lopen en oplossingen voor moeten bouwen.

Tot zover de risico’s en de maatregelen. Maar hoe vertaalt dit zich naar de dagelijkse praktijk? Bij Agentech bouwen we wekelijks agents die toegang hebben tot klantdata, interne systemen en externe API’s. De risico’s uit de stappen hierboven zijn voor ons geen abstracte dreigingen maar zaken waar we actief tegenaan lopen en oplossingen voor moeten bouwen.

Onze projecten zijn tot nu toe greenfield: we bouwen agents vanaf nul, niet bovenop bestaande systemen. Dat geeft ons het voordeel dat we beveiligingskeuzes kunnen maken vóórdat er code is niet erna.

In de praktijk betekent dat drie dingen.

• We ontwerpen vooraf wat een agent wel en niet mag. Voordat we een regel code schrijven, definiëren we welke tools een agent mag aanroepen, welke data hij mag inzien, en welke acties een menselijke bevestiging vereisen. Het is verleidelijk om breed te beginnen en later in te perken, maar dat “later” komt zelden.

• We behandelen AI-generated code als onbetrouwbaar. Een groeiend deel van de code in agent-projecten wordt geschreven of voorgesteld door AI. Onze ervaring is dat AI-tooling regelmatig authn/authz-lagen verkeerd implementeert of middleware-configuratie niet goed begrijpt. Daarom controleren we bij elke pull request expliciet hoe authenticatie, autorisatie en middleware zijn opgezet, ongeacht wie of wat de code heeft geschreven.

• We passen standaard DevSecOps toe op elke repo. Gitleaks voor credential-detectie, Snyk of SonarQube voor kwetsbaarheidsscans, en geautomatiseerde checks in de CI-pipeline. Dat is geen agent-specifieke security, dat is basishygiëne. Maar het is hygiëne die er onder tijdsdruk snel bij inschiet, bij ons net zo goed als bij ieder ander.

Wat we nog niet doen: runtime goal monitoring en semantische DLP zoals beschreven in stap 4 en 5 zijn bij ons nog niet in productie. We zien dat als de volgende stap, niet als iets dat we al hebben opgelost.

Het punt is niet dat je elk risico kunt uitsluiten. Het punt is dat je er bewust mee omgaat en dat je de juiste vangnetten inbouwt voordat je een agent live zet.

Alles bij elkaar: beveiliging in lagen

Je hebt nu het hele plaatje: een nieuw vertrouwensmodel, geharde tools, verdediging tegen prompt injection, bescherming tegen data-exfiltratie, en zichtbaarheid om het geheel te bewaken. Maar geen van die maatregelen werkt op zichzelf. Het moeten lagen zijn, en dat is misschien het saaiste wat je over security kunt zeggen, maar ook het meest waar.

Denk aan het als een estafette. Inputafhandeling vangt de meest voor de hand liggende aanvallen op: valideren tegen verwachte schema’s, invoer opschonen, rate limiting tegen fuzzing, en detectie van injection-patronen. Wat er doorheen glipt wordt afgevangen door de toegangscontrole: fijnmazige rechten, toegang gekoppeld aan het verklaarde doel van de agent, en expliciete goedkeuring voor gevoelige data. Wat ook dáár doorheen komt botst op runtime-controles die het gedrag van de agent begrenzen: timeouts, resourcelimieten, detectie van goal drift, en kill switches.

Gedragsmonitoring kijkt over al die lagen heen om patronen te herkennen die geen enkele individuele laag zou opmerken. En daarboven zit supply chain-hygiëne: alle afhankelijkheden doorlichten, ondertekende artefacten vereisen, versies vastzetten, en continu scannen op kwetsbaarheden.

Het punt is niet dat elke laag waterdicht is (dat is geen enkele), maar dat een aanvaller door alle lagen tegelijk heen moet.

Wat er aankomt

Overheden beginnen aandacht te besteden aan agents. De Singaporese mediatoezichthouder IMDA publiceerde in januari 2026 het eerste overheids-governanceframework specifiek voor AI agents, en aanpassingen van de EU AI Act voor agentische systemen worden verwacht.

De OWASP Agentic Top 10 (een lijst van de tien grootste beveiligingsrisico’s voor AI agents, samengesteld door het Open Web Application Security Project) werd in december 2025 gepubliceerd en groeit uit tot de standaard voor het meten van volwassenheid op het gebied van agentbeveiliging. Identiteitsbeheer voor niet-menselijke accounts (zoals service accounts voor agents) wordt een eigen vakgebied, en AI-firewalls die semantische beleidsregels handhaven tijdens runtime komen snel op. Dat zijn firewalls die begrijpen wat een agent probeert te doen, niet alleen op welke poort hij praat.

Conclusie

Terug naar die droomkandidaat van het begin. Het probleem was nooit het talent, het was hoe we die medewerker lieten beginnen: zonder kaders, zonder toezicht, zonder grenzen. En precies zo staan we er nu voor met agents.

Begin met de basis: minimale rechten, tool-isolatie, goal monitoring, en menselijke checkpoints voor onomkeerbare acties. Bouw zichtbaarheid er vanaf het begin in (niet achteraf) en accepteer dat het beveiligen van agents een doorlopend proces is, niet een vakje dat je eenmalig afvinkt.

Dat klinkt misschien alsof het probleem daarmee opgelost is, en dat is het niet. Prompt injection heeft nog geen waterdichte oplossing, multi-agent security heeft nog geen productiestandaard, en risicokwantificering voor agents mist de historische data die je zou willen hebben. Een flink deel van de statistieken in dit vakgebied komt bovendien uit onderzoek van leveranciers met voor de hand liggende belangen, inclusief een aantal cijfers die we hier zelf hebben aangehaald.

Maar dat is geen reden om stil te zitten. Het is een reden om pragmatisch te zijn.

Agentbeveiliging is geen feature die je erop schroeft als de demo werkt. Het is architectuur die je vanaf dag één ontwerpt, of het is de zwakke plek die iemand met slechtere bedoelingen als eerste vindt.