Steeds vaker zie je dezelfde belofte voorbij komen wanneer organisaties een agentic pentesting-oplossing evalueren: je wijst een target aan, waarna het systeem zelfstandig ontdekt, valideert en aanvalspaden test alsof een echte aanvaller aan het werk is. Die claim is belangrijk genoeg om serieus te nemen—maar ook om kritisch tegen het licht te houden.
In de praktijk draait een goede evaluatie om drie vragen: wat kan een test echt bewijzen, wanneer ontstaat die bewijsvoering en hoeveel van je omgeving wordt er daadwerkelijk meegenomen. Veel trajecten blijven steken bij het eerste punt. Juist de tweede en derde vraag bepalen of je validation programma echt waarde levert.
Waarom de focus verschuift naar validatie
De urgentie rond agentic pentesting komt niet uit de lucht vallen. Het aantal bekende kwetsbaarheden groeit explosief en het tempo waarmee aanvallen plaatsvinden, versnelt. In de bron worden vier signalen genoemd die maken dat “eens per jaar testen” steeds minder dekt:
- Volume: in de eerste helft van 2026 werden tienduizenden CVE’s gevonden (met een sterke stijging jaar-op-jaar).
- Prioritering: slechts een klein deel van de gepubliceerde kwetsbaarheden wordt daadwerkelijk “in the wild” misbruikt, waardoor lijstgedreven prioriteit vaak achter de feiten aanloopt.
- Snelheid: de tijd tussen disclosure en daadwerkelijke exploit is sterk gekrompen.
- Patch-capaciteit: veel kwetsbaarheden hebben geen upstream oplossing of patch, zelfs nadat ze grootschalig zijn ontdekt.
Daar komt bij dat je niet alleen wilt weten of je kwetsbaar bent, maar vooral hoe snel je dat kunt bevestigen nadat er iets wijzigt. Gartner beschrijft het verschuiven van een punt-in-tijd benadering naar Continuous Offensive Security Testing (COST): meer trigger-gedreven, risicogestuurd en binnen tijdvensters die passen bij de daadwerkelijke risico’s. In die context is de kernvraag niet langer “hebben we getest?”, maar “hoe snel valideren we nieuwe exposure?”.
Twee soorten bewijs die ertoe doen
Elke pentest heeft één onderliggende doelstelling: ben je exploiteerbaar? Volgens de bron levert agentic pentesting vooral twee vormen van bewijs die relevant zijn voor besluitvorming en herstel:
1) Exploitability per blootgestelde kwetsbaarheid
Het systeem probeert niet alleen te gokken op basis van versienummers. Het bewijs wordt geleverd door een exploit veilig uit te voeren om te bevestigen of een kwetsbaarheid in jouw context echt misbruikt kan worden. Met andere woorden: niet “lijkt kwetsbaar”, maar “is exploiteerbaar (en onderbouwd)”.
2) Ketenbereik naar impact
Daarna draait het om bereik: leidt een realistische aanvalsketen (van initiële toegang via privilege escalation en laterale beweging) tot een kritieke asset? De aanpak richt zich op het aantonen van het pad met evidence—zodat je remediation niet op hoop baseert, maar op een bevestigde route naar impact.
Belangrijk detail uit de bron: de overtuigingskracht geldt “op de assets die worden bereikt”. Dat is precies waar je bij de evaluatie scherp moet zijn: wat valt buiten scope en waarom?
Waar agentic pentesting stopt: het probleem met “bewijs op de klok”
Veel tools kunnen in weken een grote sweep doen. Dat is al een verbetering ten opzichte van langlopende trajecten. Toch is “weken” in een wereld waarin exploitvensters kunnen dalen tot uren, nog steeds een mismatch.
De bron beschrijft dat een grondige aanpak stap voor stap werkt: foothold, enumeratie, pivot, chaining en daarna bewijsvoering, vaak iteratief. Wanneer je dit over een heel groot netwerk (bijvoorbeeld tienduizenden tot meer dan honderdduizenden endpoints) toepast, kan de duur oplopen. Ondertussen verandert je omgeving—waardoor een deel van de resultaten mogelijk al verouderd is wanneer de scan klaar is.
Met andere woorden: een diepe sweep kan niet automatisch het gat dichten tussen “beschikbaar moment van een exploit” en “moment waarop jij je evidence hebt”. Daarom wordt in de bron het punt gemaakt dat alleen bereik niet genoeg is; de timing van validatie moet passen bij hoe snel echte aanvallen zich ontwikkelen.
Waar agentic pentesting stopt: het probleem van coverage
Naast de tijd speelt dekking. Live exploitatie kun je niet overal heen richten. Productieomgevingen, vitale systemen, grote segmenten of afgesloten zones (bijvoorbeeld om stabiliteit of veiligheidsredenen) worden vaak niet toegestaan voor werkende exploits. Ook CVE’s zonder werkende exploit geven het systeem weinig of niets om te testen.
Dat betekent dat zelfs een slimme agentic pentesting niet altijd het volledige exploitability-spectrum kan afdekken. In de bron wordt dat samengevat als een typische mate van “real exploitability” die zo’n aanpak kan zien (ongeveer in de orde van 20–30%). En zelfs als je meerdere tools stapelt, verandert de onderliggende methodische plafondwaarde niet—zeker niet wanneer tools dezelfde categorie-aanpak delen.
Daarnaast heeft beperkte coverage een ander risico: onzekerheid verschuift. Je weet dan mogelijk meer over de assets die wel getest zijn, maar aanvallers hoeven maar één overgeslagen plek te benutten om alsnog impact te realiseren.
Hoe je de juiste validatiemethode kiest bij elke verandering
In plaats van één vaste werkwijze benadrukt de bron dat verandering de keuze moet sturen. Het idee: laat de trigger bepalen welke validatievorm het snelst én veiligst antwoord geeft.
Bij een nieuwe kwetsbaarheid: exploitability-validatie
Als er een kwetsbaarheid landt, is de kernvraag: “is dit exploiteerbaar in onze omgeving?” Exploitability-validatie richt zich op het testen van de aanvalstechnieken die de kwetsbaarheid mogelijk maken. De aanpak kan zo binnen uren antwoord geven over het getroffen bereik, zonder dat er per se een “werkende exploit” nodig is om de conclusie te trekken.
Dit adresseert ook een veelgehoorde tegenwerping: “wordt dit niet al gedekt door pentesten?” Ja, maar doorgaans alleen voor zover een live test ook daadwerkelijk kan komen waar het nodig is. Validatie is breder, zolang de aanpak veilig en methodisch passend is.
Bij een nieuwe aanval of veranderende controls: security control validation
Wanneer er een campagne wordt waargenomen of een control wijzigt, verschuift de vraag naar “kunnen we dit stoppen?” Dan wordt de validatie gericht op de relevante technieken tegen je verdedigingsstack: worden ze voorkomen, gedetecteerd of gemist?
Bij infrastructuurwijzigingen: keten- en attack-path validatie
Als je infrastructuur verandert, is de cruciale vraag of dat een nieuw aanvalspad opent. De bron beschrijft dat een agentic aanpak dit bevestigt met chained live proof: een onderbouwde route naar een asset, in plaats van alleen aannames op basis van configuratie.
Voorkom islands: één gedeeld bevindingenmodel
Een waarschuwing in de bron is dat vulnerability management kan versnipperen in “eilanden”: elke methode genereert eigen bevindingen, eigen prioriteiten en eigen werkvoorraad. Dan krijg je dubbele conclusies of conflicterende tickets, en de kans is groot dat je teams opnieuw discussiëren over dezelfde blootstelling.
Daarom is het belangrijk dat de verschillende validatievormen uitkomen in één gedeeld bevindingenmodel. Dat model moet gededupliceerd zijn, gebaseerd op evidence en asset-bewust, met één backlog en één closure status per blootstelling.
Een praktisch voorbeeld: van trigger naar gevalideerde exposure
De bron geeft een voorbeeld van een tijdlijn die laat zien hoe snel het proces kan lopen wanneer de juiste methode wordt gekozen. In dat scenario gaat het om een kritieke CVE:
- Uur 1: verrijking met threat intelligence.
- Uur 2: mapping van getroffen assets, criticaliteit en relevante controles eromheen.
- Uur 4: exploitability assessment per getroffen asset; waar veilig, bevestiging van aanvalspaden via live testing; daarnaast testen van controls tegen relevante technieken.
- Uur 6: inzet van lage-risico mitigaties en doorrouting van de rest naar verantwoordelijken; fix wordt vóór afsluiting opnieuw gevalideerd.
Het kernpunt is niet dat elke organisatie exact dezelfde tijden haalt, maar dat je dezelfde logica kunt gebruiken: elke verandering wordt omgezet in validatie die past bij het risico en binnen een werkbaar tijdvenster.
Wat betekent dit voor jouw evaluatie?
Als je nu een oplossing voor agentic pentesting beoordeelt, leg dan de focus op drie toetsstenen (conform de drie vragen uit de bron), maar maak ze concreet:
- Bewijs: baseert de rapportage zich op echte, veilig uitgevoerde tests en keten-evidence, of op interpretaties van versies?
- Timing: hoe snel krijg je gevalideerde resultaten na een trigger, en hoe verhoudt dat zich tot je eigen risicovensters?
- Dekking: welke segmenten of assettypen worden niet getest met live exploitatie, en hoe wordt die onzekerheid geadresseerd?
Door deze vragen centraal te zetten, voorkom je dat je vooral enthousiasme koopt voor “autonomie”, terwijl de echte winst—snelle, evidence-based validatie—pas zichtbaar wordt wanneer je timing en scope op orde hebt.
Conclusie
Agentic pentesting is meer dan een geautomatiseerde scanner die aanvalspaden “zoekt”. In de kern gaat het om twee soorten bewijs: exploitability per kwetsbaarheid en het bevestigde ketenbereik naar impact. Tegelijkertijd kent de methode grenzen in snelheid en coverage. Precies daarom werkt de aanpak het best wanneer validatievormen worden gekozen op basis van wat er verandert—en wanneer bevindingen centraal en evidence-gedreven worden samengebracht.
Als je de evaluatie inricht rond “wat kun je bewijzen, wanneer, en hoeveel”, dan weet je sneller of je met agentic validatie daadwerkelijk het verschil maakt ten opzichte van traditionele, punt-in-tijd pentesten.
Gerelateerd lezen: CISO-data: cyberrisico in de workflow verschoven
Bron: https://thehackernews.com/2026/10/what-is-agentic-pentesting-what-it.html
