Kunnen AI-beveiligingstests SAST, DAST en pentests vervangen?

De nuttige vraag is waar een agent vertrouwen verdient. Ik vertrouw erop dat een agent de reviewdekking verbreedt, aanwijzingen uit verschillende bestanden met elkaar verbindt, gerichte tests genereert en een onleesbaar scannerlog omzet in een oplossing die een developer begrijpt. Ik vertrouw er niet op dat een agent de autorisatieregels van een bedrijf uit routenamen afleidt, bewijst dat elke tenantgrens intact blijft of zonder menselijke uitleg beslist dat een vreemd financieel proces misbruik is. Behandel de agent als een actieve reviewer binnen een gelaagd testprogramma, niet als het programma zelf.

Een agent-review is een tolk, geen nieuwe testcategorie

Een AI-agent verandert de manier waarop bewijs wordt verzameld en begrepen. Hij creëert geen nieuw soort bewijs. Als hij broncode leest zonder de applicatie uit te voeren, doet hij een flexibele vorm van statische review. Als hij requests naar een draaiend doel stuurt, doet hij dynamische tests. Als hij doelen verkent, van aanpak verandert en onverwacht gedrag volgt, lijkt hij op een pentester. Die gelijkenis geeft hem echter niet de bevoegdheid of bedrijfscontext van een tester.

Dat onderscheid is belangrijk wanneer een leverancier zegt dat zijn agent «scanners vervangt». Vraag wat het systeem daadwerkelijk kan waarnemen. Krijgt het de volledige repository, gegenereerde code, buildflags, infrastructuurbeleid en lockfiles van dependencies? Kan het als meerdere gebruikers authenticeren en na elke request de databasetoestand controleren? Weet het welke handelingen volgens het beleid verboden zijn, in plaats van alleen welke handelingen niet in de interface staan? Een gelikte uitleg kan ontbrekende input niet repareren.

Agents zijn echt goed in het verbinden van zwakke signalen. Een conventionele regel kan markeren dat een requestparameter een querybuilder bereikt. Een agent kan de wrapper inspecteren, zien dat één aanroeppunt het tenant-predicaat overslaat, een testrequest opstellen en uitleggen waarom de zogenaamd veilige helper op dat pad onveilig is. Hij kan een kandidaat ook afwijzen wanneer de waarde via een echte geparametriseerde API loopt. Dat is betere triage, geen bewijs dat statische of dynamische analyse overbodig is geworden.

De scherpe grens ligt tussen review en verificatie. Review vraagt: «Lijkt deze implementatie onveilig op basis van het materiaal dat ik kan zien?» Verificatie vraagt: «Kan deze actor onder de vastgelegde voorwaarden een verboden resultaat veroorzaken?» AI helpt bij beide, maar een security gate moet vastleggen welke claim hij maakt. Teams krijgen problemen wanneer een welsprekende reviewobservatie wordt opgewaardeerd tot een geverifieerde exploit, of wanneer één mislukte exploitpoging als bewijs van veiligheid wordt gezien.

Modelgedrag voegt nog een onderscheid toe: capaciteit is niet hetzelfde als herhaalbaarheid. Een agent kan in de ene run een subtiel pad ontdekken en het missen nadat een model, prompt, retrievalindex of toolbeleid is gewijzigd. Bewaar prompts, toolrechten, opgehaalde bestanden, gegenereerde requests en de modelidentifier wanneer een resultaat belangrijk is. Zet bevestigde ontdekkingen daarna om in tests waarvan het slagen niet afhangt van het opnieuw ontdekken van zijn eigen idee door het model.

SAST blijft verantwoordelijk voor herhaalbare brondekking

SAST blijft de goedkoopste manier om stabiele controles bij elke wijziging op een grote codebase toe te passen. Het kan bronnen en sinks inventariseren, verboden API's afdwingen, datastromen inspecteren en precies rapporteren welke revisie is geanalyseerd. Een deterministische regel levert morgen hetzelfde resultaat op. Dat is belangrijk wanneer een release gate een controleerbare reden nodig heeft om te slagen of te falen.

Een agent voegt context toe die een regelengine vaak mist. Hij kan projectspecifieke wrappers volgen, commentaar kritisch lezen, een handler met naburige handlers vergelijken en een query voor een nieuw patroon voorstellen. Hij kan verdachte omissies vinden, zoals negen endpoints die authorizeProject() aanroepen terwijl een tiende het record rechtstreeks laadt. Hij is ook nuttig wanneer gegenereerde code of een onbekend framework een standaardregelset in de war brengt.

De brondekking van een agent is echter meestal moeilijker te bewijzen. Contextvensters, retrievalrangschikking, genegeerde bestanden, gegenereerde artefacts en time-outs van tools kunnen ervoor zorgen dat code niet wordt gelezen. «Review deze repository op injection» bewijst niet dat elke sink is bereikt. Een SAST-rapport kan ten minste vermelden welke bestanden, regels en revisie zijn geanalyseerd. Een agent heeft een gelijkwaardig dekkingsregister nodig voordat hij een verplichte gate kan overnemen.

NIST SP 800-218 doet hier de verstandige aanbeveling: gebruik codeanalyse vroeg en controleer beveiligingsfuncties en maatregelen handmatig. De waarde zit in de combinatie. Stabiele regels vinden bekende foutpatronen bij elke commit. De agent onderzoekt uitzonderingen, schrijft gerichte regressietests en helpt regels af te stemmen wanneer hetzelfde patroon terugkeert. SAST verwijderen omdat de agent enkele slimme bugs heeft gevonden, ruilt meetbare breedte in voor indrukwekkende anekdotes.

SAST ziet ook code die een draaiende test misschien nooit bereikt: foutpaden, featureflags, migratiehulpmiddelen, slapende admin-endpoints en branches die platformafhankelijk zijn. Het kan niet vertellen of de geïmplementeerde omgeving die paden activeert. Die onzekerheid is een reden om runtimebewijs toe te voegen, niet om statische dekking weg te gooien.

Niet alles hoort in een blokkerende SAST-regel. Een nauwkeurig patroon voor een verboden cryptografisch primitief kan direct blokkeren. Een brede heuristiek die vraagt of een autorisatiecheck «voldoende dichtbij» lijkt, moet meestal eerst een reviewtaak opleveren totdat het team de nauwkeurigheid ervan heeft gemeten. Agents kunnen helpen om een heuristiek tot een regel te maken door echte voorbeelden, tegenvoorbeelden en veelgebruikte wrapperfuncties in die codebase te verzamelen. Zo blijft de gate streng zonder developers te leren hem te negeren.

Gegenereerde oplossingen verdienen dezelfde controle als bevindingen. Een model kan een taint-trace stilleggen door validatie op de verkeerde laag toe te voegen, een uitzondering af te vangen en fail-open te gaan, of een gevaarlijke aanroep vervangen terwijl het gedrag verandert. Voer het oorspronkelijke bewijs uit op de patch, voer normale functionele tests uit en beoordeel de nieuwe controle op de plek waar vertrouwen wordt gevestigd. Een schone rescan bewijst alleen dat de oorspronkelijke regel niet meer matcht.

DAST bewijst gedrag dat de repository niet kan onthullen

DAST observeert de applicatie die daadwerkelijk draait, inclusief prox regels, headers, serialisatie, authenticatiemiddleware, standaardinstellingen van het framework en fouten in de deployment. Een bronreview kan zeggen dat een endpoint beschermd lijkt. Een dynamische test kan aantonen dat de productieroute de middleware omzeilt omdat een gateway het pad herschrijft.

Hier kan een agent dynamische tests veel minder bot maken. Geef hem een API-beschrijving, testidentiteiten, toegestane scopes en een wegwerpomgeving. Dan kan hij requestreeksen bouwen in plaats van willekeurige payloads rond te sturen. Hij kan een resource-id uit de ene response meenemen naar de volgende, een sessie vernieuwen, twee rollen vergelijken en controleren of een write latere reads heeft gewijzigd. Conventionele DAST heeft vaak moeite met zulke stateful flows.

De agent heeft nog steeds strikte operationele grenzen nodig. Een crawler weet niet of het veilig is een e-mail te versturen, een zending aan te maken of een betaalde integratie aan te roepen. Een testomgeving kan nog steeds met echte services verbonden zijn. Definieer toegestane hosts, accounts, requestfrequenties, destructieve acties en stopvoorwaarden buiten de prompt van het model en dwing ze af in de runner. Een zin als «vermijd gevaarlijke acties» is geen controle.

Houd een conventionele dynamische basislijn aan voor bekende controles zoals securityheaders, blootgelegde bestanden, reflected input, gangbare injection-probes en TLS-configuratie. Deze controles zijn goedkoop, tussen releases vergelijkbaar en eenvoudig te volgen. Laat de agent zijn budget besteden aan geauthenticeerde paden en gedrag in ketens. Als beide systemen dezelfde eenvoudige probe uitvoeren, houd dan het systeem met het duidelijkste bewijs en de kleinste variatie.

DAST kan ook een vals gevoel van volledigheid geven omdat het alleen rapporteert wat het heeft bereikt. Leg route-dekking, gebruikte identiteiten, featureflags en seeddata samen met het resultaat vast. Een schone scan tegen een vrijwel leeg account zegt weinig over een applicatie waarvan gevaarlijke branches pas verschijnen na goedkeuring, uitnodiging, facturatie of data-import.

De configuratie van authenticatie verdient eigen bewijs. Leg vast hoe de test elke sessie heeft verkregen, welke tweede factoren of devicecontroles in de testomgeving zijn omzeild en of tokens dezelfde claims en levensduur hebben als productietokens. Een handmatig aangemaakt admin-token kan nuttige dekking openen, maar tegelijk precies de sessie- en privilege-overgangen overslaan die getest moeten worden. Vermeld zulke shortcuts duidelijk in het rapport.

Dynamisch hertesten moet beginnen met de opgeslagen requestreeks, niet met een nieuwe autonome crawl. Speel het bevestigde bewijs af tegen de gepatchte build, controleer of het verboden effect is gestopt en varieer daarna aangrenzende input om een smalle filter te vinden. Laat de agent pas daarna verkennen. Zo blijft het verschil duidelijk tussen «de oplossing blokkeert de bekende exploit» en de bredere claim dat de hele foutcategorie is verwijderd.

Autorisatietests hebben identiteiten en verboden uitkomsten nodig

Autorisatie is niet «het endpoint gaf één keer 403 terug». Een bruikbare test legt vast wie handelt, welk object die persoon benadert, welke handeling wordt geprobeerd en welk resultaat onmogelijk moet blijven. Een agent kan de combinaties genereren, maar de productowner en securityreviewer moeten het beleid aanleveren.

OWASP ASVS zegt dat applicaties toegangscontrole moeten afdwingen in een vertrouwde servicelaag en least privilege moeten toepassen op functies en gegevens. Met de eis voor de servicelaag ben ik het eens, maar teams controleren dit vaak te beperkt. Ze testen de zichtbare HTTP-handler en vergeten background jobs, exports, searchindexen, websocket-abonnementen en rechtstreekse object-storage-URL's. Hetzelfde beleid moet elk pad naar het object overleven.

Een kleine uitvoerbare matrix laat meer zien dan de vage opdracht «test IDOR». Het volgende shellfragment gaat uit van een wegwerpomgeving, twee bearer-tokens en een document dat eigendom is van gebruiker A. Het controleert zowel de status als de afwezigheid van A's geheime marker in de response van B:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

De verwachte output is leeg en de exitstatus is nul. Bij een CI-fout moeten status, opgeschoonde body, handelende identiteit, eigenaar van het doel, route en buildrevisie worden bewaard. Bewaar geen live credentials of niet-gerelateerde responsgegevens.

Varieer nu één dimensie tegelijk: lezen tegenover bijwerken, rechtstreeks ID tegenover zoeken, actief tegenover ingetrokken lidmaatschap, normale route tegenover export en user-token tegenover service-token. De agent kan die gevallen efficiënt produceren en uitvoeren. Een mens moet controleren of de matrix bij het beleid past en of een 404, 403, leeg resultaat of afgeschermd object de bedoelde uitkomst is. Anders kan de agent gedrag vieren dat het bedrijf als een datalek beschouwt.

Negatief bewijs vraagt om zorg. Een geweigerde update kan nog steeds onthullen of een object bestaat via responstijd, fouttekst of een versieteller. Een geweigerde read kan een viewcount verhogen of een auditrecord schrijven met geheime metadata. Bepaal welke neveneffecten zijn toegestaan en maak daar assertions voor. Securitytests die alleen de response bekijken, kunnen een bruikbaar enumeratiekanaal of een schadelijke write missen.

Test ook beleidswijzigingen tijdens een sessie. Verwijder een gebruiker uit een project, draag eigendom over, schakel een account uit of beperk een servicerol. Gebruik daarna oude tokens en open verbindingen opnieuw. De verwachte intrekkingstijd moet uit het productbeleid komen. «Uiteindelijk» is niet testbaar en directe intrekking is misschien niet nodig, maar het team moet een grens kiezen en die controleren voor API-requests, werk in wachtrijen, downloads en live abonnementen.

Tenantisolatie faalt buiten het voor de hand liggende requestpad

Tenantisolatie vereist tests bij opslag, cache, queue, search, bestanden, analytics en administratieve grenzen. De veelgemaakte fout is niet een ontbrekende tenant_id in het belangrijkste lijstendpoint. Het is een secundair pad dat gegevens kopieert, indexeert, cachet of exporteert zonder de tenantcontext mee te nemen.

Begin met twee tenants met bewust vergelijkbare records en elk één onmiskenbare marker. Gebruik afzonderlijke gebruikers en sessies en, waar de architectuur dat toelaat, afzonderlijke servicecredentials. Voer create, read, update, delete, list, search, export, import, attachment access, notificatiebezorging en background processing uit. Controleer na elke actie de zichtbare response en de blijvende toestand. Een geweigerde request die toch een cross-tenant job in de queue zet, is een fout.

Agents helpen omdat ze een identifier door verschillende lagen kunnen volgen en varianten kunnen genereren die mensen vervelend vinden. Ze kunnen zien dat de cachesleutel document_id gebruikt terwijl de databasequery zowel tenant_id als document_id gebruikt. Ze kunnen een exportworker vergelijken met de interactieve handler en vragen waarom alleen de ene row-level context instelt. Dat zijn waardevolle reviewstappen.

Ze maken ook een gevaarlijke aanname: namen zouden grenzen impliceren. Een functie met de naam getTenantDocument kan een willekeurig tenantargument uit de request accepteren. Een databasebeleid kan in migraties bestaan maar op een nieuwe tabel ontbreken. Een searchfilter kan pas na het tellen van resultaten worden toegepast, waardoor de activiteit van een andere tenant uitlekt. Verificatie moet het afgedwongen predicaat inspecteren en vervolgens een cross-tenant read en write proberen.

Laat de agent geen eigen oracle maken door dezelfde code te lezen als de code die hij test. Leid de verwachte toegang af uit een onafhankelijke beleidstabel die samen met de productvereisten wordt onderhouden. Als implementatie en test dezelfde regel verkeerd begrijpen, zijn ze het perfect eens terwijl ze gegevens blootgeven.

Asynchrone paden hebben vertraagde assertions nodig. Start als tenant A een export-, notificatie-, thumbnail- of indexeerjob, wijzig eigendom of lidmaatschap voordat de worker draait en controleer waar het resultaat terechtkomt. Bepaal of de worker de autoriteit gebruikt die bij de request is vastgelegd of de actuele autoriteit opnieuw controleert bij uitvoering. Beide keuzes kunnen voor een specifieke handeling correct zijn, maar een onbedoelde mix veroorzaakt lekken en gebrekkige audit trails.

Administratieve tools verdienen afzonderlijke identiteiten en loggingassertions. Supporttoegang overschrijdt vaak bewust tenantgrenzen, waardoor de eenvoudige regel «een andere tenant moet falen» onjuist is. Test of de operator de vereiste rol en casecontext heeft, of het klantgerichte beleid wordt gevolgd, of toegang verloopt en of het auditevent de operator identificeert in plaats van de klant te imiteren.

Bedrijfslogica vereist een verhaal over misbruik

Testen van bedrijfslogica begint met een verboden scenario: een gebruiker krijgt waarde, bevoegdheid of toestand die hij niet hoort te krijgen door geldige handelingen in een ongeldige volgorde of combinatie uit te voeren. Algemene kwetsbaarheidslabels zijn te beperkt. De tester moet weten hoe uitnodigingen, goedkeuringen, quota, terugbetalingen, tegoeden, eigendomsoverdrachten en annuleringen op elkaar horen in te werken.

De OWASP Web Security Testing Guide vraagt testers om overgeslagen workflowstappen, herhaalde functies, vervalste requests, wijzigingen in timing en misbruik van geldige functies te proberen. De oudere inleiding over bedrijfslogica zegt het direct: scannerautomatisering kan de toepassingsspecifieke kennis of creativiteit niet leveren. Moderne agents verbeteren de automatisering, maar nemen de kenniskloof niet weg. Een model kan vermoeden dat een coupon opnieuw bruikbaar is. Het weet niet of dat een promotie of fraude is totdat iemand de regel formuleert.

Geef de agent een toestandsmodel met toegestane transities en invarianten. Voor een goedkeuringsflow kan een invariant luiden: «Een aanvrager kan zijn eigen betaling niet goedkeuren, ook niet na een eigendomsoverdracht.» Vraag hem vervolgens reeksen te genereren met rolwijzigingen, dubbele requests, annuleringen, retries, concurrency en verouderde sessies. De agent kan veel meer reeksen onderzoeken dan iemand handmatig zal uitvoeren.

De moeilijke gevallen hebben gevolgen buiten de HTTP-response. Twee gelijktijdige redemption-requests kunnen allebei succesvol terugkomen terwijl een latere reconciliatie er één verwijdert. Een annulering kan de zichtbare job stoppen maar een ondertekende download niet intrekken. Een uitnodiging die wordt geaccepteerd nadat de uitnodiger toegang heeft verloren, kan een verweesd lidmaatschap creëren. Tests moeten ledgers, queues, objectrechten en latere toestand observeren, niet alleen statuscodes.

Menselijke testers verdienen hun plek door het vastgelegde model ter discussie te stellen. Ze vragen of supportmedewerkers onschuldige functies kunnen combineren, of een operator zijn eigen audit trail kan beïnvloeden en of een «verlopen» object via een ander kanaal bruikbaar blijft. Een agent werkt binnen de doelen en tools die hij krijgt. Een mens kan zien dat de doelen het gevaarlijke deel van het bedrijf overslaan.

Risico van dependencies is meer dan een kwetsbare versie

Dependencytests beantwoorden vier afzonderlijke vragen: welke pakketten aanwezig zijn, of hun bekende versies gemelde kwetsbaarheden bevatten, of de build de bedoelde artefacts heeft verkregen en of de applicatie het kwetsbare gedrag daadwerkelijk blootstelt. Software composition analysis (SCA) en provenancecontroles beantwoorden de eerste drie betrouwbaarder dan een gesprek met een model alleen.

Een agent is nuttig zodra de inventaris bestaat. Hij kan inspecteren hoe een dependency wordt aangeroepen, bepalen of de getroffen functie bereikbaar is, een compenserende controle vinden en een upgradepatch met regressietests opstellen. Hij kan ook riskant pakketgedrag signaleren waarvoor geen kwetsbaarheids-ID bestaat, zoals een installatiescript dat netwerktoegang krijgt of een nieuwe library die secrets uit de omgeving ontvangt.

Vraag het model niet om actuele kwetsbaarheidsgegevens uit zijn geheugen. Geef het een gedateerde advisorybron, het opgeloste lockfile en de inventaris van de gebouwde artefacts. Het geheugen van een model is geen kwetsbaarhedendatabase en een package manifest bewijst niet wat is geleverd. SLSA provenance maakt een verwant onderscheid: provenance beschrijft waar, wanneer en hoe een artefact is geproduceerd. Het verklaart het artefact niet veilig.

Bereikbaarheid kan de prioriteit voor triage verlagen, maar mag eigenaarschap niet uitwissen. Featureflags veranderen, dode code keert terug en indirecte dependencies worden onverwacht aangeroepen. Leg vast waarom een bevinding is uitgesteld, welke versie en welk aanroeppad zijn beoordeeld en welke gebeurtenis de bevinding opnieuw moet openen. De agent kan die redenering bijhouden, terwijl een deterministische inventaris op de gebeurtenis let.

Ook pakketnamen zorgen voor identiteitsvalkuilen. Een dependency met de verwachte naam kan uit de verkeerde registry komen, een lockfile kan naar een veranderlijke locatie wijzen of een buildstap kan code downloaden die niet in het manifest staat. Controleer opgeloste bronnen, hashes, handtekeningen waar het ecosysteem die ondersteunt en netwerktoegang tijdens de build. Een agent kan afwijkingen uitleggen, maar het buildsystem moet afdwingen welke bronnen het accepteert.

Upgrades zijn niet automatisch veilige wijzigingen. Een securityrelease kan parsing, autorisatiedefaults of serialisatie veranderen op manieren die een applicatie breken. Genereer een minimale reproductie voor de advisory, pas de upgrade toe in een geïsoleerde branch en voer zowel het securitybewijs als functionele tests uit. Dat bewijs ondersteunt een beslissing. Een model dat zegt dat de nieuwe versie «waarschijnlijk compatibel» is, doet dat niet.

False positives zijn een probleem van bewijsontwerp

Een bevinding verdient tijd van een developer alleen wanneer ze een claim, bewijs, impact en reproduceerbaar pad bevat. AI-rapporten klinken vaak volledig terwijl één van die onderdelen ontbreekt. Vloeiende tekst over oplossingen maakt zwak bewijs moeilijker te herkennen.

Laat elke agentbevinding de geanalyseerde revisie en omgeving, het getroffen component, de voorwaarden voor de aanvaller, de overschreden beveiligingsgrens, het geobserveerde of afgeleide resultaat, reproductiestappen en onzekerheid vermelden. Markeer afgeleide bronbevindingen anders dan uitgevoerde exploits. Als de agent de applicatie niet kon uitvoeren, moet hij dat in de bevinding zeggen en de beperking niet verstoppen in een opmerking op scanniveau.

Gebruik vervolgens een eenvoudige reeks statussen: bevestigd, waarschijnlijk, context nodig, niet reproduceerbaar, geaccepteerd risico of opgelost. «False positive» moet betekenen dat de beveiligingsclaim onjuist is, niet dat het team de ernst niet prettig vindt of het werk heeft uitgesteld. Door die beslissingen te vermengen verdwijnt de waarde van feedback. De agent kan niet leren welke regel tekortschiet als elk ongewenst ticket hetzelfde label krijgt.

AI kan ruis verminderen door dubbele traces te clusteren, sanitizers te controleren en na een fix opnieuw te testen. Hij kan ruis ook versterken door tien overtuigende varianten van één zwak vermoeden te produceren. Dedupliceer op hoofdoorzaak en grens, niet op URL. Eén ontbrekende ownershipcheck die door acht endpoints wordt gebruikt, is één technisch defect met acht blootstellingspunten.

Meet precisie per categorie en per testbron. Als door een agent gegenereerde cross-site-scriptingmeldingen meestal geldig zijn maar race-conditionclaims zelden reproduceerbaar blijken, stuur ze dan anders door. Reduceer prestaties niet tot één score voor ongerelateerde defecttypen. Een gate moet falen op bewijs en beleid, niet op een bijvoeglijk naamwoord over het vertrouwen van het model.

Eigenaarschap sluit de cirkel. Elke geaccepteerde bevinding heeft iemand of een team nodig dat verantwoordelijk is voor herstel, een verwachte hertestmethode en bewaard bewijs dat een andere tester kan uitvoeren. Als het rapport alleen in een agentgesprek bestaat, verdwijnt het wanneer het gesprek, model of de leverancier verandert. Beveiligingswerk wordt duurzaam wanneer het bewijs de tool overleeft die het heeft geproduceerd.

Privacy is ook tijdens triage belangrijk. Broncode, requestbodies, logs en databasesamples kunnen credentials of klantgegevens bevatten. Beperk wat de agent ontvangt, redigeer bewaarde transcripts, scheid testdata van productiedata en pas de goedgekeurde regels voor gegevensverwerking van de organisatie toe op de modelprovider en diens tools. Betere detectie rechtvaardigt niet dat je een volledig productie-incident in een ongecontroleerde prompt kopieert.

Een menselijke pentest test de aannames rond de test

Een ervaren pentester verandert het plan wanneer de applicatie het briefingsdocument tegenspreekt. Dat is het deel dat agents nog niet hebben vervangen. De persoon spreekt met eigenaars, lost onduidelijke regels op, merkt operationele shortcuts op, vraagt om een andere identiteit en beslist wanneer vreemd gedrag een langere reeks experimenten verdient.

Mensen zijn ook verantwoordelijk voor oordelen bij onvolledig bewijs. Ze kunnen onderscheid maken tussen een technisch mogelijke handeling en een geloofwaardig aanvalspad, een samengestelde fout uitleggen aan bestuurders en engineers en een veilig bewijs afspreken wanneer exploitatie gegevens kan beschadigen. Een autonome agent moet stoppen bij de grens die zijn operator heeft ingesteld. Als hij die grens stilletjes uitbreidt, is hij zelf een beveiligingsrisico geworden.

Dat betekent niet dat elke release een externe opdracht van een week nodig heeft. Gebruik menselijke tests waar verandering en gevolg samenkomen: een nieuw autorisatiemodel, tenantarchitectuur, betaal- of kredietflow, administratief vlak, gevoelige integratie, grote migratie of publieke lancering. Plan breder periodiek werk op basis van risico en test ernstige oplossingen opnieuw. Routinematige releases hebben nog steeds geautomatiseerde dekking nodig.

Geef de tester de output van de agent, SAST-traces, DAST-dekking, architectuurnotities, testaccounts en onopgeloste aannames. De agent kan verkenning en repetitieve varianten uitvoeren terwijl de tester onverwacht gedrag onderzoekt. Zo wordt menselijke tijd productiever zonder te doen alsof die tijd overbodig is.

Wees voorzichtig met claims over «autonome pentests» die worden gemeten aan het aantal bevindingen. Tien bekende injectionbevindingen zijn niet gelijk aan één aangetoond pad via roltoewijzing, verouderde autorisatie en exportopslag. Beoordeel het werk op de geteste grenzen, de kwaliteit van het bewijs en de belangrijke aannames die ter discussie zijn gesteld.

Bespreek vóór de opdracht wie verantwoordelijk is voor opruimen. Testaccounts, geüploade bestanden, berichten in wachtrijen, tijdelijke rollen en gewijzigde featureflags kunnen na de scan blijven bestaan. Een menselijke lead moet destructieve bewijzen goedkeuren, contact houden met operations en herstel controleren. De agent kan een opruimscript volgen, maar kan niet beslissen dat een onverklaarde productietoestand veilig kan worden verwijderd.

Een goede tester rapporteert ook wat niet kon worden getest. Ontbrekende mobiele builds, niet-beschikbare rollen, rate limits, callbacks van derden en instabiele omgevingen verminderen de zekerheid. Agents blijven vaak om obstakels heen werken en presenteren de paden die ze wel hebben uitgevoerd. Het eindrapport moet uitzonderingen duidelijk vermelden, zodat een schoon resultaat niet voor volledige dekking wordt aangezien.

Bouw één gate uit verschillende soorten bewijs

Het juiste programma geeft elke methode een taak en zorgt dat de resultaten aan dezelfde beveiligingseisen worden getoetst. Gebruik SAST voor deterministische bronpatronen en brede dekking van wijzigingen. Gebruik SCA en provenance voor feiten over dependencies en builds. Gebruik DAST voor geïmplementeerd gedrag en basistests tijdens runtime. Gebruik agents om bewijs te verbinden, geauthenticeerde flows te verkennen, tests te maken en triage te verbeteren. Gebruik mensen om beleid te definiëren, aannames over bedrijfslogica ter discussie te stellen en wijzigingen met grote gevolgen te onderzoeken.

Een releasebeleid kan dan specifiek zijn. Blokkeer een build wanneer een deterministische regel met hoge ernst een niet-goedgekeurd pad treft, wanneer een vereiste autorisatie-invariant faalt, wanneer een cross-tenant marker verschijnt of wanneer een bevestigde exploit open blijft. Stuur onzekere agentbevindingen met een blootstellingsafhankelijke deadline naar review. Laat het zelfgerapporteerde vertrouwen van een model nooit bepalen of productie wordt uitgerold.

Houd het bewijs overdraagbaar. Exporteer bevindingen, gegenereerde tests, requesttranscripts, toolversies, revisies, identiteiten, dekking en statussen in formaten die het team zonder de agent kan inspecteren. Dat is belangrijk voor audits, incidentreviews, leverancierswijzigingen en de gewone dag waarop een modelupdate het gedrag verandert.

Voor applicaties die via chat zijn gemaakt, geldt dezelfde scheiding. Koder.ai kan web-, server- en mobiele applicaties genereren en de broncode exporteren, maar gegenereerde software heeft nog steeds expliciete beveiligingseisen en onafhankelijke tests tegen het geïmplementeerde resultaat nodig. Snelle creatie maakt een duidelijke gate nuttiger omdat architectuur en code snel kunnen veranderen.

Laat de agent continu draaien, maar maak van zijn beste ontdekkingen deterministische regressietests. Elke bevestigde omzeiling van autorisatie moet een beleidsgeval worden. Elk tenantlek moet een invariant toevoegen aan de grens die faalde. Elke lawaaierige regel moet een vastgelegde status krijgen. Na verloop van tijd hoort de agent het testsysteem nauwkeuriger achter te laten dan hij het aantrof.

Vraag niet welke ene tool wint. Vraag of elke belangrijke claim onafhankelijk bewijs heeft: het codepad is beoordeeld, het geïmplementeerde gedrag is uitgevoerd, de bedrijfsregel komt van een eigenaar en een mens heeft de aannames uitgedaagd waar een fout grote gevolgen zou hebben. Als één van die regels leeg is, vult een door AI gegenereerd «alles in orde» dat gat niet.