Een AppSec-team kan met weinig setup een AI-agent, die draait op een algemeen model, op zijn eigen webapplicaties loslaten. Ja, het model schrijft de aanvallen. Maar alles wat die aanvallen veilig maakt om tegen productie uit te voeren en wat het de moeite waard maakt erna op te treden, bevindt zich in de controleharnas rond het model. In dat harnas zit de engineering van AI-pentesten. De inbraak bij Hugging Face die OpenAI in juli bekendmaakte, toonde wat er gebeurt wanneer dat harnas bezwijkt, zelfs binnen een OpenAI-evaluatie die bedoeld was om de agenten in te sluiten.
Waarom elke controle rigoureuze engineering vereist
Laten we de verschillende fasen van een aanval en de rol die AI-agenten daarin kunnen spelen nader bekijken
Scope
Een pentest-agent neemt duizenden beslissingen over waar het zijn volgende verzoek naartoe stuurt, en het model beoordeelt elke beslissing aan de hand van een regel in gewone taal. De werkelijke grens van een webapp strekt zich vaak voorbij één domein uit via redirects en aanroepen naar externe services. Scope afdwingen betekent dat er code is die elk verzoek inspecteert voordat het vertrekt, en de OWASP-richtlijn van 2026 leidt geprivilegieerde acties via een deterministische beleidsmotor die ze uitvoertijd controleert, buiten het model om.
Referenties
Het vinden van gelekte referenties hoort bij wat een pentest doet, dus de agent komt regelmatig werkende sleutels tegen buiten zijn opdracht. Welke daarvan hij mag gebruiken, waarvoor en wanneer een persoon betrokken wordt, zijn beleidskeuzes die de code rond het model bij elke poging toepast.
Prompt-injectie
Elke pagina en API-respons die de agent leest, inclusief verborgen velden, metadata en commentaar dat een gebruiker nooit ziet, kan inhoud bevatten geschreven door iedereen die naar de app kan posten. Eén productrecensie is genoeg om kwaadaardige instructies te verbergen. OWASP rangschikt prompt-injectie als het grootste risico voor LLM-toepassingen en merkt op dat er vandaag geen betrouwbare preventie bestaat. De ontwerpvraag is niet of het model wordt misleid, maar hoeveel schade het kan aanrichten als dat gebeurt. Dat komt neer op twee zaken: hoe strak elke actie is begrensd en welke acties verdere controle en menselijke goedkeuring vereisen. Geen van beide is eenvoudig. OWASP waarschuwt dat goedkeuringsmoeheid het oordeel van beoordelaars op schaal aantast, dus alles naar een mens routeren verschuift het falingspunt alleen verderop in de keten.
Bewijs
In oktober 2026 stopte Google met het accepteren van product-kwetsbaarheidsrapporten voor zijn open-source bugbountyprogramma na een toename van geautomatiseerde inzendingen, waarvan het merendeel volgens hen niet geldig was. Een bevinding die een ontwikkelaar niet kan reproduceren is slechts nog een ticket om te sluiten. Een bruikbare bevinding produceren betekent het exploit uitvoeren, vastleggen wat het bereikte en het resultaat zo verpakken dat iedereen het kan herhalen, allemaal binnen de grenzen van de andere ingestelde controles.
Dit wordt nooit eenmalig gebouwd. Elke modelupgrade kan veranderen hoe de agent zich gedraagt, en elke releasenew leidt tot veranderingen in de app waarvan de beveiliging wordt getest. En rond de controles bevinden zich de systemen waarop een productie-agent vertrouwt, inclusief verandering-geactiveerde tests, het routeren van bevindingen naar de ontwikkelaars die de code bezitten, strikt beheer van welke klantgegevens een modelprovider bereiken, en het koppelen van wat de agent in de app vindt aan de rest van de omgeving.
Door al die onderdelen heen is het patroon hetzelfde. Het model redeneert over wat het moet proberen, en deterministische code beslist wat wordt uitgevoerd, legt het vast en stopt het wanneer dat nodig is.
Hoe Pentera Apps het harnas implementeert
Deze scheiding tussen redeneren en uitvoeren is hoe wij Pentera Apps bouwen. In plaats van een AI-model rechtstreeks verzoeken in een applicatie te laten sturen, koppelt Pentera Apps een AI die beslist wat te testen aan een deterministisch harnas dat bepaalt wat mag draaien. Elke actie wordt gelogd en elke test kan op elk moment gepauzeerd of gestopt worden. Het is dezelfde veiligheidsdiscipline die Pentera al bijna tien jaar toepast bij productietests, bij duizenden klanten wereldwijd.
Het harnas levert ook het bewijs. Iedere bevinding wordt geleverd met een herhaalbaar exploit-script, een CVSS 3.1-score en CWE-toewijzing, zodat ontwikkelaars de aanval zelf kunnen reproduceren in plaats van het op vertrouwen te moeten aannemen. Zodra de fix is geïntegreerd, kan exact dezelfde aanval opnieuw worden uitgevoerd om te bevestigen dat het pad is gesloten. Tests draaien op aanvraag of volgens schema, met verandering-geactiveerde tests in CI/CD die volgen, zodat validatie synchroon blijft met ontwikkeling.
De omliggende systemen volgen dezelfde discipline. Alleen minimale, geredigeerde gegevens bereiken het LLM (groot taalmodel), met geen bewaring en geen training op klantgegevens, en gegevens blijven in de regio van de klant. Elke test begint met context uit verkenning van de aanvalsoppervlakken van de klant, bevindingen uit hun securitystack en live dreigingsinformatie. Die context stelt Pentera in staat een exploit in een webapp te traceren naar netwerk, cloud en identiteit binnen één platform.
Bij agentgestuurde pentests bepaalt het harnas de resultaten. Pentera Apps bouwt dat harnas in, zodat beveiligingsteams gevalideerde bevindingen krijgen zonder er zelf één te hoeven bouwen.
Opmerking: Dit artikel is vakkundig geschreven en bijgedragen door Assaf Regev, AVP Product Marketing bij Pentera. Beveiligingsteams kunnen zich aanmelden voor vroege toegang tot Pentera Apps, Agentic Web App Pentesting.
