Skip to main content
Blog
Blog

Hoe AI-agents accountbeveiliging breken en hoe je botgedreven ATO detecteert

Hoe AI-agents account takeover uitvoeren via credential replay, sessie- en tokenhergebruik, en misbruik van herstel, en de browsersignalen die hen blootleggen.

Jul 11, 2026 7 min read
Hoe AI-agents accountbeveiliging breken en hoe je botgedreven ATO detecteert
Inhoudsopgave

Kort samengevat: AI-agent gedreven account takeover

  • Het gat: MFA legt de lat hoger bij de wachtwoordstap, maar AI-agents richten zich op wat erna komt: ze spelen gestolen sessiecookies en OAuth-tokens opnieuw af om authenticatie helemaal over te slaan, of doorlopen de recovery-flow om het account te herkoppelen aan e-mail en telefoon van de aanvaller.
  • Het bewijs: cside 2026-onderzoek meldt dat installaties van playwright-stealth met ongeveer 10x groeiden over 2025. Dat is de toolkit die echte Chromium-instances aandrijft op menselijke snelheid, langs IP-reputatie, headless-checks en rate limits die scripted bots stoppen.
  • De beslissing: Als je ATO-signaal alleen op login vuurt, glipt een agent die een geldig token afspeelt of de factor reset via een recovery-event vanaf een nieuw apparaat er schoon doorheen. Instrumenteer recovery en post-auth met dezelfde browser-scrutiny als login, anders blijft de zijdeur open.

Weinig tijd? Bekijk cside accountovername-detectie. Dit dekt alles hieronder in één deployment.

AI-agents breken accountbeveiliging door de onderdelen van takeover te automatiseren die vroeger een mens nodig hadden. Ze besturen echte browsers, dus ze spelen gestolen credentials opnieuw af, hergebruiken gekaapte sessies en tokens, en lopen door account-recoveryflows zoals een persoon dat zou doen. Daarmee verslaan ze controles die gebouwd zijn voor grove, op verzoekniveau werkende bots. Om botgedreven account takeover (ATO) te betrappen moet je de browsersessie zelf lezen, niet alleen het IP en de verzoeksnelheid.

Deze post behandelt de drie fases waar AI-agents daadwerkelijk inbreken: geautomatiseerde credential replay, sessie- en tokenhergebruik, en misbruik van de recoveryflow. Voor elke fase noemt hij de browser- en apparaatsignalen die de agent blootleggen, en waar cside die levert.

Waarin verschilt AI-agent-ATO van een normale bot?

Een legacy stuffingbot is een script. Het post gebruikersnaam-wachtwoordparen naar je login-endpoint, snel, vanaf een handjevol IP's, zonder een echte browser erachter. Rate limits, IP-reputatie en een headless-check stoppen het grootste deel daarvan.

Een AI-agent werkt anders. Het draait een echte browser via automatiseringsframeworks als Playwright of Puppeteer, vaak verpakt in een stealthkit die de voor de hand liggende tekens patcht. Het rendert je pagina, redeneert over wat het ziet, vult formulieren in en verandert van koers wanneer een challenge verschijnt. Daarmee rondt het flows af die een script niet kan: klikken op een resetlink in de inbox van een slachtoffer, opnieuw indienen van een onderschepte eenmalige code, of een checkout voltooien na een step-up-prompt.

De tooling werd goedkoper en makkelijker. cside's webbeveiligingsonderzoek 2026 meldt dat installaties van playwright-stealth, een van de vele stealth-browserkits, in de loop van 2025 ongeveer 10x groeiden, een maatstaf voor hoe snel browsergedreven automatisering standaard aanvallersuitrusting werd. cside 2026 research

De drie fases waar AI-agens inbreken

FaseWat de agent doetSignaal dat hem blootlegt
Credential replayBestuurt een echte browser om gelekte paren in te dienen en challenges te passerenAutomatiseringsflags, fingerprint-drift, residentiële-proxy-egress
Sessie / tokenhergebruikSpeelt een gestolen cookie of OAuth-token opnieuw af om de login heltedal over te slaanOmgevingsmismatch versus het origin-device van de sessie
Recovery-misbruikDoorloopt de reset-/factorwijzigingsflow om het account blijvend in handen te krijgenNieuw apparaat bij een recovery-event, agentgedrag midden in de flow

Fase 1: geautomatiseerde credential replay

Dit is credential stuffing met een browser ervoor. In plaats van ruwe verzoeken logt de agent in via de gerenderde pagina zodat het verkeer menselijk oogt. Het roteert browser-fingerprints tussen pogingen om te voorkomen dat ze worden gegroepeerd, verdeelt egress over residentiële proxypools om IP-limieten te verslaan, en lost CAPTCHA's op of besteedt ze uit.

De browseromgeving verraadt de agent alsnog. Automatiseringsframeworks exponeren navigator.webdriver en andere gepatchte properties die de geclaimde browser tegenspreken. Stealthkits proberen deze te verbergen, maar de patches zelf zijn detecteerbaar: een property die herdefinieerd is, een Chrome DevTools Protocol (CDP) Runtime-artefact, een headless-rendering-eigenaardigheid, of een fingerprint die binnen één sessie verschuift tussen verzoeken. Die inconsistenties zijn onzichtbaar in een netwerkpakket en overduidelijk in de browseromgeving.

Fase 2: sessie- en tokenhergebruik

Meer capabele agents slaan je login over. Als ze een sessiecookie of OAuth/bearer-token stelen, via een gephishte sessie, malware of een skimmingscript op je eigen pagina, spelen ze die opnieuw af en erven ze een geauthenticeerde sessie zonder oog in oog te komen met de wachtwoord- of MFA-prompt. Dit is het patroon van AI-agent-tokenhergebruik.

Een correct token zegt niets over of dezelfde gebruiker het vasthoudt. De browseromgeving wel. Een opnieuw afgespeelde sessie toont doorgaans een andere fingerprint, een ander apparaat en een ander netwerkpad dan degene die oorspronkelijk authenticeerde. Wanneer het token geldig is maar de omgeving eromheen niet matcht met het origin-device van de sessie, is die mismatch het teken. Dit is ook waarom een gecompromitteerd third-party script op je login- of checkoutpagina zo gevaarlijk is: het kan het token liften nog voordat je server een misvormd verzoek ziet.

Fase 3: misbruik van de recoveryflow

Recovery is het zachte doel, omdat het ontworpen is om een legitieme gebruiker weer binnen te laten nadat die zijn factor is kwijtgeraakt. Een agent maakt daar precies gebruik van. Het triggert een wachtwoordreset, onderschept of social-engineert de resetlink, en koppelt het account opnieuw aan een door de aanvaller gecontroleerd e-mailadres, telefoonnummer of een passkey, en zet zo een tijdelijke indringing om in permanent eigendom.

Deze fase vertoont zelden de snelheidspieken die stuffing verraden. Het volume is laag en bewust. Het signaal dat telt is context: een recovery- of factorwijzigings-event dat aankomt vanaf een geheel nieuw apparaat en browseromgeving, uitgevoerd met de timing en het navigatiepatroon van automatisering in plaats van een verwarde mens. Instrumenteer recovery met dezelfde browserniveauscrutinie als login, anders beveilig je de voordeur en laat je de zijdeur open.

Welke browser- en apparaatsignalen leggen botgedreven ATO bloot?

Netwerksignalen beschrijven waar verkeer vandaan kwam. Browsersignalen beschrijven wie de sessie daadwerkelijk bedient. Voor AI-agent-ATO leeft het bewijs in de tweede set.

  1. Automatiserings- en stealth-tells. navigator.webdriver, herdefinieerde of gepatchte browserproperties, CDP Runtime-lekken en headless-rendering-eigenaardigheden die de geclaimde browser tegenspreken.
  2. Fingerprint-drift. Een apparaat- of browserfingerprint die binnen één sessie verandert tussen verzoeken, het rotatiepatroon dat agents gebruiken om groepering te ontwijken.
  3. Omgeving-vs-token-mismatch. Een geldige sessie of token die aangeboden wordt vanaf een apparaat, fingerprint of netwerkpad dat niet matcht met de oorsprong van de sessie.
  4. Residentieel-proxy-gedrag. Egress die residentieel oogt maar zich gedraagt als infrastructuur, gebruikt om geautomatiseerd verkeer langs IP-reputatie te wassen.
  5. Fasebewuste context. Een nieuw apparaat bij een recovery-event, of automatiseringsgedrag dat specifiek opduikt bij reset, factorwijziging of checkout.

Eén enkele rij overtuigt niet. De beslissing komt uit de stapel: een stealth-browser-tell plus fingerprint-drift plus een recovery-event vanaf een nieuw apparaat beschrijft vrijwel nooit een echte gebruiker. Het vastleggen van deze signalen, en het apparaat en echte IP erachter, is ook wat een fraudeteam een verdedigbaar audittrail geeft wanneer een aanval zich midden in een sessie aanpast.

Hoe cside past

cside is een client-side securityplatform dat opereert in de browserlaag, waar AI-agents daadwerkelijk draaien. Het combineert AI-agentdetectie met apparaat- en browserfingerprinting en VPN/proxy-gedragsanalyse om de bovenstaande signalen naar boven te halen, en levert ze vervolgens als ruwe signalen via een API zodat door ontwikkelaars geleide teams ze inpluggen in hun eigen login-, sessie- en recovery-risicologica.

Omdat de analyse in de browser geworteld is, betrapt cside stealth browsers, tokenreplay en recovery-misbruik die netwerk-only-tooling niet ziet. Het geeft ook zicht op third-party scripts op je login- en checkoutpagina's, hetzelfde oppervlak dat een aanvaller gebruikt om een sessietoken te liften nog voordat je server een enkel slecht verzoek ziet.

Verder lezen over cside

Simon Wijckmans
Founder & CEO

Founder and CEO of cside. Previously a product manager on Cloudflare Page Shield (now Cloudflare Client-Side Security). Co-chair of the W3C Anti-Fraud Community Group and a Forbes 30 Under 30 honoree. Building accessible security against client-side attacks, web security is not an enterprise-only problem.

FAQ

Frequently Asked Questions

Nee. Een traditionele stuffingbot vuurt ruwe HTTP-verzoeken af op een login-API. Een AI-agent bestuurt een echte browser, leest de gerenderde pagina, beslist waar hij klikt, lost of besteedt challenges uit en past zich aan wanneer een verdediging reageert. Daardoor kan hij flows met meerdere stappen voltooien die een script niet kan, zoals een wachtwoordreset doorlopen of een MFA-prompt opnieuw invoeren met een gestolen eenmalige code.

MFA verhoogt de drempel bij de wachtwoordstap, maar agents richten zich op wat daarna komt. Ze spelen een gestolen sessiecookie of OAuth-token opnieuw af zodat ze zich nooit opnieuw hoeven te authenticeren, of ze maken misbruik van de account-recoveryflow om de factor zelf te resetten. Beide paden omzeilen een schone MFA-prompt. Je hebt sessie- en herstelfasesignalen nodig, niet alleen een sterke login-challenge.

De sterkste aanwijzingen zijn omgevingsinconsistenties die een agent niet volledig kan verbergen: een automatiseringsflag of gepatchte property die de geclaimde browser tegenspreekt, een fingerprint die tussen verzoeken in dezelfde sessie verschuift, een headless-rendering-eigenaardigheid, en een residentiële-proxy-egress die niet overeenkomt met de geschiedenis van het account. Eén signaal overtuigt niet. Een stapel ervan in één sessie beschrijft vrijwel nooit een echte gebruiker.

Monitor en beveilig je third-party scripts

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Start gratis, of probeer Business met een proefperiode van 14 dagen.

cside-dashboardinterface met scriptmonitoring en beveiligingsanalyses
Related Articles
Boek een demo

Wil je dit doornemen met een engineer?

Dertig minuten, op je eigen site. Geen slides.

We laten je zien:

Welke scripts van derden er nu op je site draaien
Hoe je ervoor staat op PCI DSS 6.4.3 en 11.6.1
Welk deel van je verkeer uit bots en AI-agents bestaat

Liever gewoon een vraag stellen?

Vrije momenten zoeken…

Alleen echte mensen. Wij merken het.

Lukt het boeken niet? Agenda in een nieuw tabblad openen

Wat wil je oplossen?

Vertel het ons in één zin, dan komen we terug met iets bruikbaars in plaats van een standaardverhaal.

Waar we meestal mee helpen:

Zien welke scripts van derden op je site draaien
Bewijs voor PCI DSS 6.4.3 en 11.6.1
Bots, AI-agents en accountovername

Liever meteen een moment inplannen? Kies een tijdstip