Wat zijn de beveiligingsrisico's van AI-browsers voor je bedrijf?

Wat is een AI-browser, en waarin verschilt hij van een gewone browser?

Een AI-browser is een webbrowser met een ingebouwde AI-agent die pagina's kan lezen, content kan samenvatten, formulieren kan invullen en namens jou acties kan uitvoeren in andere webapps. Die autonomie is de functie, en ook het aanvalsoppervlak.

Neem een marketingteam dat een AI-browser gaat gebruiken om rapporten samen te vatten. Het werkt, dus collega's volgen. Weken later leest de assistent een pagina met verborgen instructies en stuurt hij de inhoud van een geopend SharePoint-document naar een extern adres. Niemand klikte op iets verdachts en er draaide geen malware.

Daarom is een AI-browser geen "browser met een chatbot". Het is een agent die met jouw sessies en rechten werkt. Endpointtools, waaronder een EDR-platform, zien een gewoon browserproces. Het risico zit in wat de agent wordt opgedragen.

Hoe werkt prompt injection in een AI-browser?

Prompt injection laat de AI tekst van een aanvaller behandelen als instructies. OWASP noemt het LLM01, het grootste risico in zijn lijst voor toepassingen met grote taalmodellen. OWASP maakt onderscheid tussen directe injectie (getypt door de gebruiker) en indirecte injectie, die binnenkomt via externe content zoals websites of bestanden.

De vier fasen van een indirecte prompt injection

1. De val. Een aanvaller verbergt instructies in webcontent: witte tekst op een witte achtergrond, een HTML-commentaar, een verborgen reactie op een forum of een gehackte pagina die je normaal vertrouwt.
2. Het lezen. Jij vraagt de agent de pagina samen te vatten, of hij surft er zelf naartoe. De verborgen tekst komt in de context van het model.
3. De actie. Het model kan jouw instructies niet betrouwbaar onderscheiden van die van de aanvaller en volgt ze dus: zichtbare data kopiëren, een URL openen, een e-mail opstellen en versturen.
4. De stilte. Er draaide geen exploitcode en er is geen bestand gedownload, dus traditionele beveiligingstools zien een gewone browsesessie.

Dit is al in de praktijk gebeurd. Onderzoekers van Brave lieten in augustus 2025 zien dat de Comet-browser van Perplexity instructies kon opvolgen die verborgen zaten achter een spoiler-tag op een Reddit-pagina en een eenmalig wachtwoord voor het account van de gebruiker kon lekken, meldde The Register. Brave zei later dat het probleem nog niet volledig was verholpen.

Waarom is prompt injection zo moeilijk te stoppen?

Omdat een taalmodel geen harde grens heeft tussen instructies en data. Klassieke verdedigingen zoals inputvalidatie, die SQL-injectie oplosten, werken hier niet.

In "Prompt injection is not SQL injection (it may be worse)", gepubliceerd op 8 december 2025, legt het Britse National Cyber Security Centre uit dat een LLM "geen onderscheid maakt tussen 'data' en 'instructies'; er is alleen 'het volgende token'". Het NCSC waarschuwde dat prompt injection "misschien nooit helemaal te verhelpen is, zoals dat bij SQL-injectie wel kan" en dat de inspanningen gericht moeten zijn op het verkleinen van risico en impact.

Leveranciers zijn het ermee eens. In Continuously hardening ChatGPT Atlas against prompt injection (december 2025) schreef OpenAI dat prompt injection, "net als oplichting en social engineering op het web, waarschijnlijk nooit helemaal 'opgelost' wordt".

Zijn AI-browsers veilig op het werk?

Niet standaard. Een AI-browser erft alle rechten van de ingelogde gebruiker, van mailbox tot fileshares en beheerconsoles, en geeft ze aan een agent die door paginacontent te sturen is.

Analisten reageerden fel. Op 9 december 2025 adviseerde Gartner dat "CISO's in de nabije toekomst alle AI-browsers moeten blokkeren om risicoblootstelling te beperken", meldde TechNewsWorld. Gartner noemde onder meer zijbalken die actieve webcontent, open tabbladen en browsegeschiedenis naar een cloud-backend sturen, en agents die zonder uitdrukkelijke toestemming namens een gebruiker handelen.

Voor EU-organisaties zijn er drie specifieke aandachtspunten:

• Doorgifte van data. Stuurt de agent paginacontent of persoonsgegevens naar verwerking buiten de EER, dan geldt hoofdstuk V van de AVG (vanaf artikel 44) voor die doorgifte.
• Melden van datalekken. Een lek van persoonsgegevens via een gemanipuleerde agent kan een datalek zijn. AVG-artikel 33 verplicht je dat binnen 72 uur te melden bij de toezichthouder, als het waarschijnlijk een risico voor mensen oplevert.
• Risicobeheer. Voor entiteiten die onder NIS2 vallen, gaat NIS2-artikel 21(2)(d), (g) en (i) over ketenbeveiliging, cyberhygiëne en training en toegangsbeheer. Dat geldt allemaal voor AI-tools die op bedrijfsdata handelen. Zie ons overzicht van artikel 21.

Een algeheel verbod duwt het gebruik vaak ondergronds. Blokkeer je AI-browsers niet helemaal, behandel ze dan als elke software die op bedrijfsdata kan handelen: alleen goedgekeurde versies, beperkte accounts, gemonitord gebruik.

Hoe beperk je het risico van AI-browsers? Een plan in vijf stappen

Geen enkele maatregel haalt het risico van prompt injection weg, dus combineer ze. De eerste vier stappen verkleinen de kans op schade. De vijfde beperkt de schade als er toch iets doorheen komt.

1. Inventariseer en besluit. Zoek uit welke AI-browsers en extensies al in gebruik zijn. Blokkeer ze dan, zoals Gartner adviseert, of publiceer een lijst met goedgekeurde tools en blokkeer al het andere via apparaatbeheer.
2. Beperk waar de agent bij kan. Geen AI-browsen vanaf beheeraccounts. Houd agents weg bij financiële systemen, HR-systemen en systemen met patiënt- of klantgegevens. OpenAI zelf adviseert de uitgelogde modus als de taak je accounts niet nodig heeft, en agents smalle, specifieke instructies te geven.
3. Houd een mens in de lus. Eis bevestiging voordat de agent berichten verstuurt, formulieren indient of betalingen doet, volgens het advies van OWASP over menselijke goedkeuring voor acties met een hoog risico.
4. Train voor de nieuwe phishing. Medewerkers weten dat ze links niet moeten vertrouwen. Leer ze dat een webpagina hun assistent kan aanvallen, en voeg scenario's met prompt injection toe aan de awarenesstraining.
5. Ga uit van falen en bescherm de data. Bewaar geïsoleerde, onveranderbare back-ups van Microsoft 365, Google Workspace en endpoints, met aparte inloggegevens. Zo kan een agent die data verwijdert of beschadigt de back-ups niet meenemen.

Preventie of herstel: waar past welke maatregel?

Preventie verkleint hoe vaak een gemanipuleerde agent kan handelen. Herstel maakt ongedaan wat hij deed. Omdat injectie niet is uit te bannen, heb je beide nodig.

Onthoud dat ook de ingebouwde tools beperkingen hebben: de prullenbak van Microsoft 365 bewaart verwijderde items maximaal 93 dagen. Wat een agent daaruit verwijdert, of wat verloopt, is weg. Lees meer in maakt Microsoft 365 een back-up van je data? en als MFA (meervoudige authenticatie) wordt omzeild.

Wat je nu kunt doen

AI-browsers brengen echte productiviteitswinst, maar ook een aanval die de huidige tools niet betrouwbaar kunnen blokkeren en die leveranciers zeggen niet volledig te kunnen patchen. Behandel de agent als een bekwame maar feilbare gebruiker: besluit of je hem toestaat, beperk waar hij bij kan, laat risicovolle acties bevestigen en houd een geteste manier om zijn fouten terug te draaien.

Mindtime maakt back-ups van Microsoft 365, Google Workspace en endpoints in onze eigen Tier III-datacenters in Nederland en Duitsland, als onveranderbare kopieën (Object Lock) plus een air-gapped kopie. Je kunt losse items granulair terugzetten en beheeracties zijn beschermd met MFA. Voor MSP's helpt het Mindtime EDR Platform om endpoints van klanten gepatcht en volgens CIS-benchmarks geconfigureerd te houden, terwijl de MSP de dienst zelf draait.

Wil je weten hoe goed je SaaS-data te herstellen is na een incident door AI? Plan een gratis demo van 15 minuten.

Dit artikel is algemene informatie, geen juridisch advies.