Agentic AI draait tegenwoordig al in productieomgevingen van veel organisaties. Het voert taken uit, verbruikt gegevens en onderneemt actie – hoogstwaarschijnlijk zonder noemenswaardige betrokkenheid van het beveiligingsteam. Het gesprek in de sector heeft dit grotendeels als een beleidskwestie geformuleerd: toestaan, beperken of monitoren? Die framing mist echter het punt.
De urgentere vraag is of beveiligingsprofessionals daadwerkelijk begrijpen waar ze mee te maken hebben. In de meeste organisaties is dat op dit moment niet het geval. En die kloof wordt met de week groter.
Wat je niet begrijpt, kun je niet veiligstellen
Het fundamentele principe van informatiebeveiliging is niet veranderd: er moet sprake zijn van echte beheersing van een technologie voordat je deze op zinvolle wijze kunt verdedigen.
Denk aan firewalls. Je kunt er niet één goed configureren zonder netwerkkennis te hebben. Toen cloud computing zijn intrede deed, kwamen organisaties die het fundamentele werk oversloegen terecht in omgevingen waarover ze niet konden redeneren: aangeschafte tools, geschreven beleid en nog steeds geen echte controle. We hebben tegenwoordig cloudbeveiliging als een eigen discipline, juist omdat de technologie vereiste dat beoefenaars er diepgaande vertrouwdheid mee zouden ontwikkelen voordat de beveiliging kon volgen.
Dezelfde dynamiek speelt zich af bij AI, in een sneller tempo en met hogere inzetten.
De praktische consequentie van een achterstand op het gebied van kunstmatige AI gaat verder dan technische blootstelling. Beveiligingsteams die de taal van AI-engineering niet spreken – die ontwerpbeslissingen niet kunnen aanvechten, werkbare controles kunnen voorstellen of weloverwogen vragen kunnen stellen – worden omzeild. Bedrijfseenheden gaan zonder hen verder, niet uit kwade trouw, maar omdat een beveiligingsteam dat zich niet inhoudelijk met de technologie kan bezighouden, geen bruikbare partner is voor beslissingen daarover. Dit heeft zich de afgelopen twee tot drie decennia bij elke grote technologische verschuiving voorgedaan. AI zal niet anders zijn.
Het uitgangspunt is betrokkenheid. Probeer een agent te bouwen. Experimenteer met de tools die uw ontwikkelaars al gebruiken. Deze praktische vertrouwdheid is waar echt begrip begint, en echt begrip maakt al het andere mogelijk.
Drie categorieën agenten, drie risicocategorieën
Het agentische AI-landschap is breed en het risicoprofiel varieert aanzienlijk. Drie categorieën zijn de moeite waard om duidelijk te begrijpen.
De eerste is codeer- en productiviteitsmiddelen voor algemene doeleinden — tools zoals Claude Code en GitHub Copilot. Deze zijn al ingebed in de workflows voor ontwikkelaars en engineering in uw hele organisatie. Of ze nu formeel zijn goedgekeurd of niet, ze worden gebruikt. Tot welke gegevens ze toegang hebben, hoe ze omgaan met codebases en welke acties ze kunnen ondernemen, is op dit moment basiskennis over beveiliging.
De tweede is door leveranciers gebouwde agenten, mogelijk gemaakt door het Model Context Protocolof MCP. MCP is de integratielaag waarmee agenten verbinding kunnen maken met externe services en namens hen kunnen handelen. Bijna elke grote leverancier heeft een MCP-server in productie of is er actief mee bezig. In de praktijk betekent dit dat een agent die de agenda, het e-mailadres of het interne ticketingsysteem van een gebruiker beheert, input van die kanalen kan ontvangen en daarop actie kan ondernemen. Een kwaadaardige agenda-uitnodiging met verborgen instructies in de gebeurtenisbeschrijving is een echte aanvalsvector: de agent leest deze, interpreteert de ingebedde prompt en voert deze uit. Dit is een live aanvalsoppervlak dat een doelbewuste configuratie en beveiligingsbeoordeling vereist.
De derde categorie is aangepaste agenten gebouwd door individuele gebruikersen dit is waar de dynamiek bijzonder interessant wordt. Jarenlang bestond er een echte barrière tussen beveiligingsprofessionals die risico’s begrepen en de code die in hun omgevingen van toepassing was. De meeste beveiligingsprofessionals zijn geen programmeurs. Voor het bouwen van aangepaste tools waren ontwikkelingsvaardigheden nodig die niet breed verspreid waren onder beveiligingsteams.
Die barrière is verdwenen.
Met agentic AI kan iedereen in de organisatie functionele tools bouwen – automatiseringen, workflows, agenten met echte systeemtoegang – zonder traditionele code te schrijven. Voor beveiligingsteams is dit echt waardevol. Incidentonderzoek, forensische triage, workflows voor het opsporen van bedreigingen – deze kunnen worden versneld wanneer praktijkmensen de tools kunnen bouwen die ze daadwerkelijk nodig hebben. Maar diezelfde mogelijkheid strekt zich uit tot elk ander team. Marketing, financiën, bedrijfsvoering: iedereen kan nu agenten bouwen. Velen zullen dat doen. De meeste van deze agenten zullen geen beveiligingsbeoordeling ondergaan voordat ze live gaan. Dit is een supply chain-probleem in een andere vorm.
De kosten van te laat komen
Wanneer beveiligingsteams achterlopen bij een grote technologische verandering, is het patroon consistent.
Ten eerste gaat de rest van de organisatie vooruit zonder inbreng van de beveiliging. Ontwikkelaars implementeren, bedrijfseenheden adopteren en beveiliging wordt als een formaliteit geraadpleegd – of helemaal niet. Ten tweede de blootstellingsverbindingen. Hoe krachtiger de agenten die een organisatie inzet, hoe meer toegang die agenten nodig hebben. Brede machtigingen maken agenten nuttig: toegang tot agenda’s, communicatieplatforms, bestandssystemen, codeopslagplaatsen, interne API’s. Die toegang is ook wat de explosieradius aanzienlijk maakt als er iets misgaat.
Een agent met toegang tot zowel een terminal als een e-mailinbox kan via het ene kanaal worden gemanipuleerd om in het andere kanaal te handelen. Dat is een zijdelings bewegingspad waar een aanvaller naar zal zoeken. Om erover te kunnen redeneren is inzicht nodig in hoe de agent is gebouwd – het soort inzicht dat alleen voortkomt uit oprechte betrokkenheid bij de technologie.
De vaardigheden die er nu toe doen
Voor het opbouwen van competentie op het gebied van agentische AI-beveiliging zijn twee verschillende kennislagen nodig.
De eerste is begrijpen hoe AI-toepassingen worden ontworpen – vanuit het perspectief van een beoefenaar, niet dat van een datawetenschapper. Wat zijn de componenten van een AI-toepassing? Hoe consumeren agenten input, koppelen ze tools aan elkaar en produceren ze output? Hoe ziet een sessie met een MCP-verbonden agent er vanuit het oogpunt van toegangscontrole eigenlijk uit? Dit is de basis die al het andere uitvoerbaar maakt.
De tweede laag is munteenheid. Het tool- en bedreigingslandschap rond AI verandert snel. Leveranciers bouwen beveiligingscontroles voor AI-systemen, hoewel de meeste nog steeds volwassen worden. Open-sourceframeworks zijn in opkomst. OWASP en anderen publiceren dreigingstaxonomieën die van week tot week evolueren. Zodra de fundamentele laag aanwezig is, wordt actueel blijven de voortdurende discipline: weten welke tools de moeite waard zijn om te evalueren, welke raamwerken aan populariteit winnen en welke vragen je moet stellen als leveranciers met oplossingen komen.
Dat tweede punt is belangrijker dan het lijkt. Beveiligingsteams worden al benaderd door leveranciers die AI-beveiligingsproducten verkopen. Zonder fundamentele kennis van hoe deze applicaties zijn gebouwd, zijn die gesprekken bijna onmogelijk om goed te navigeren. Je kunt een goed ontworpen controlemechanisme niet onderscheiden van een marketingverpakking als je niet begrijpt waar je controle over probeert te krijgen.
Configuratie als beveiligingscontrole
Veel agentische AI-implementaties brengen risico’s met zich mee omdat ze zonder beveiligingsbewuste configuratie zijn opgezet – niet omdat de onderliggende tools fundamenteel kapot zijn.
Neem een zelfgehoste AI-assistent die is aangesloten op een communicatiekanaal zoals Telegram, wat gebruikelijk kan zijn. zonder de juiste controles zou de agent kunnen reageren op iedereen die hem een bericht stuurt. Dat is een wijd open ingangspunt. Een eenvoudige configuratiewijziging – door de agent te koppelen aan één enkel vertrouwd account – sluit het grootste deel van deze blootstelling af. Eén beslissing, vroeg genomen, met een betekenisvol veiligheidsresultaat.
Het bredere principe is reikwijdte. Een agent die is gebouwd om uw agenda te beheren, mag geen toegang hebben tot uw terminal. Een agent die binnenkomende verzoeken verwerkt, mag geen schrijftoegang hebben tot uw coderepository. Door agenten te richten op hun beoogde functie, wordt de straal van de explosie beperkt en wordt het aanvalsoppervlak dat beschikbaar is voor uitbuiting verkleind.
De spanning is reëel: machtige agenten hebben brede toegang nodig om nuttig te kunnen zijn. Dat is de afweging die organisaties zullen maken. Het vinden van de juiste balans vereist betrokkenheid van de beveiliging vroeg in het ontwerpproces – voordat de architectuur is vastgesteld en voordat de machtigingen al aanwezig zijn.
Een voorsprong nemen op SANSFIRE 2026
De organisaties die nu echte AI-beveiligingsvaardigheden opbouwen, zullen in de positie zijn om vorm te geven aan de manier waarop deze systemen worden ingezet. Degenen die te laat komen, zullen merken dat ze opnieuw controles toepassen op een architectuur die al zonder hen tot stand was gekomen.
In juli geef ik SEC545: GenAI en LLM Application Security op SANSFIRE 2026. De cursus behandelt hoe AI-applicaties daadwerkelijk worden gebouwd, hoe agentische systemen in de praktijk werken, de echte aanvalsoppervlakken die beveiligingsteams moeten begrijpen, en de tools en controles die beschikbaar zijn om deze aan te pakken – inclusief praktijkgericht werken met technieken zoals het scannen van modellen om gecompromitteerde modellen te detecteren voordat ze in uw omgeving worden uitgevoerd. Voor praktijkmensen die met AI-systemen aan de slag willen gaan vanuit een basis van echt begrip, is dit waar ze moeten beginnen.
Registreer u hier voor SANSFIRE 2026.
Opmerking: Dit artikel is vakkundig geschreven en bijgedragen door Ahmed Abugharbia, SANS Certified Instructor.
