Je AI-browser handelt namens jou. Beveilig je nog steeds alleen de gebruiker?

Twintig jaar browserbeveiliging draaide om één vraag: mag deze pagina bij die gegevens? Same-origin policy, extensie-permissies, twee-factor-inlog, ze zijn allemaal gebouwd rond het idee dat er een mens aan de knoppen zit die beslist wat er gebeurt. Je AI-assistent haalt die mens weg.

Zodra Claude voor Chrome, Perplexity Comet of ChatGPT Atlas zelf klikt, formulieren invult en namens jou inlogt, verschuift het doelwit van de aanvaller. Niet langer jij, maar de agent die met jouw rechten handelt. En de meeste bedrijven beveiligen nog steeds de gebruiker, niet de agent die inmiddels het werk doet.

De agent handelt met jouw rechten, op tekst die van buiten komt

Een gewone browser voert alleen uit wat jij aanklikt. Een agentische browser leest een pagina, trekt daar een bedoeling uit en handelt ernaar, met dezelfde toegang die jij hebt tot je mail, je bank en je bedrijfssystemen. Precies dat is het verkoopargument: laat de assistent je boekingen doen, je bestellingen plaatsen, je accounts bijhouden. Het probleem zit in dezelfde zin verstopt. Hij kan het verschil niet zien tussen de inhoud van de pagina en een instructie die iemand in die pagina heeft gezet.

Dat is prompt-injectie: de data die de agent leest, bevat zelf een opdracht. Het klinkt theoretisch tot je ziet hoe simpel het is. Toen onderzoekers van Brave een verborgen opdracht in een Reddit-post zetten en Comet vroegen die pagina even samen te vatten, haalde de assistent het e-mailadres van de gebruiker op, opende Gmail met diens ingelogde sessie en lekte een eenmalige code naar een vreemde server, terwijl same-origin policy en CORS er niets tegen konden doen. Die twee beschermingen zijn de ruggengraat van webbeveiliging. Ze gaan over welke site bij welke data mag. Ze zeggen niets over een assistent die met jouw volledige rechten doet wat een wildvreemde pagina hem opdraagt.

Dat is de kern. De agent opereert, in de woorden van de Brave-onderzoekers, met je volledige rechten over al je ingelogde sessies: je bank, je bedrijfssystemen, je mail, je cloudopslag. Elke webpagina die hij samenvat, is een potentieel commando.

Het aanvalskanaal is niet meer jij, maar de assistent

Als de agent zijn commando's uit tekst haalt, hoeft een aanvaller jou niet meer te misleiden. Hij misleidt de agent. En dat kan van twee kanten komen: van een pagina die je bezoekt, of van een extensie die al in je browser zit.

Het kritieke lek waardoor andere extensies Claude voor Chrome konden aansturen liet die tweede route zien. De extensie controleerde niet of een klik van een echte gebruiker kwam. Een kwaadaardige extensie kon nagemaakte muisklikken injecteren die Claude negen ingebouwde taken lieten uitvoeren, van Gmail beheren tot een Salesforce-lead aanpassen, zonder dat de gebruiker iets deed. De browser vertrouwde elke klik, ook een die JavaScript had verzonnen.

Het patroon herhaalt zich per leverancier. SquareX toonde dat een extensie met heel gewone permissies een valse AI-zijbalk over de echte heen kan leggen en de gebruiker naar een phishingsite of zelfs een reverse shell kan leiden. Bij Comet was één kwaadaardige link genoeg om de assistent zijn opgeslagen gegevens te laten uitlezen en die in base64 langs de exfiltratie-controle te sluizen. Verschillende tools, verschillende trucs, hetzelfde onderliggende gat: de agent vertrouwt zijn invoer.

Dit is niet nieuw voor wie de agentische laag volgt. Een gekoppelde MCP-tool stuurt je agent net zo goed aan als jij dat doet, simpelweg via zijn beschrijving. En de aanval verschoof al eerder van je wachtwoord naar je actieve sessie, voorbij je MFA. De agentische browser voegt daar een nieuwe voordeur aan toe, met de sleutels al in het slot.

Dit is geen bug die de leverancier wegpatcht

De verleiding is om te denken: dit lek wordt gedicht, volgende. Maar dit is geen incident, het is een categorie. En de bouwers zeggen dat zelf.

Toen Anthropic zijn eigen browserassistent testte, zakte een geslaagde prompt-injectie van 23,6 naar 11,2 procent in autonome modus nadat het zijn volledige beveiliging had aangezet. Een jaar later haalde het betere cijfers, maar het bedrijf schrijft er onomwonden bij: geen enkele browseragent is immuun voor prompt-injectie, en het probleem is verre van opgelost. Dat is de maker van de tool, niet een criticus aan de zijlijn.

De reden dat het niet zomaar wegpatcht, zit in het ontwerp zelf. Een agentische browser is pas nuttig als hij twee dingen tegelijk doet: vreemde inhoud lezen die hij niet vooraf kent, en handelen met jouw rechten. Haal het eerste weg en hij kan niets voor je opzoeken. Haal het tweede weg en hij kan niets voor je regelen. De kwetsbaarheid is dus geen slordigheid in de code, het is de functie. Daarom verlaagt een classifier of een extra trainingsronde de kans wel, maar raakt hij de bodem niet.

Het zit ook niet bij één leverancier. De BioShocking-techniek misleidde zes AI-browsers tegelijk, waaronder Atlas en Comet, en OpenAI trok Atlas als los product alweer terug. Dit is dezelfde structurele verschuiving die elke laag van je AI-stack, van npm-pakketten tot IDE-plugins, in een actief aanvalspad veranderde. De agentische browser is gewoon de nieuwste laag, en de meest intieme, want hij zit tussen jou en alles waar je op ingelogd bent.

Om eerlijk te zijn: de bouwers zitten niet stil

Het eerlijke tegenargument is sterk. De leveranciers doen wél iets. Ze trainen hun modellen om injecties te weerstaan, ze zetten classifiers op verdachte inhoud, ze laten red teams continu aanvallen. 1Password laat Claude nu inloggen zonder dat je wachtwoord ooit het model bereikt. En het Claude-lek vereist dat je zélf een kwaadaardige extensie installeert, en raakte maar negen vooraf gedefinieerde taken, geen vrije toegang. Je kunt met recht zeggen: dit is beheersbaar, en de paniek is groter dan het risico.

Toch houd ik mijn lijn. Die maatregelen verlagen de kans, ze sluiten de categorie niet. Elf procent, of zelfs één procent, klinkt laag tot je bedenkt waar die faalkans op zit: op een handeling die je bankrekening kan leegtrekken of je mailbox kan doorzoeken. Een spamfilter dat af en toe mist, kost je een vervelende mail. Een agent die af en toe mist, kost je je sessie. Dat is een ander risicoprofiel. En dat het Claude-team een tweede vondst, een parameter die permissies oversloeg, als informatief afdeed, laat zien dat de verdediging nog niet af is, ook niet bij de koploper.

Beveilig de agent, niet alleen de gebruiker

Terug naar de vraag waar browserbeveiliging twintig jaar om draaide: mag deze pagina bij die data? Bij een agentische browser is dat de verkeerde vraag geworden. De juiste vraag is: wat mag deze agent doen, met wiens rechten, en wie kijkt mee?

Dat betekent een agent behandelen als wat hij is: een gebruiker die zelf handelt, geen handige knop. Een gebruiker geef je zo min mogelijk rechten, een eigen identiteit, en toezicht op wat hij doet. Dezelfde les kwam deze week door een andere deur binnen, met een kwaadaardige OAuth-toestemming die MFA en passkeys straal negeert: je kunt de gebruiker tot in de perfectie beveiligen en alsnog alles verliezen via wat er namens hem handelt.

De browser leerde ooit om geen enkele pagina zomaar te vertrouwen. De agent moet dat nog leren. Tot die tijd is de assistent die voor je klikt niet je grootste gemak, maar je grootste blootstelling. Wie dat begrijpt, beveiligt niet de gebruiker die niets meer aanraakt, maar de agent die alles aanraakt.