Veel organisaties vertellen zichzelf dat AI-agenten veilig zijn zodra ze “functioneel” werken. In de praktijk loopt het mis zodra een agent in een browser draait binnen een ingelogde gebruikerssessie. Dan ziet de applicatie de gebruiker wel, maar niet de agent, niet de delegatie en niet het beoogde taakbereik. Een team dat dit onderzocht, beschrijft hoe ze hun eigen AI-agent browserregels letterlijk konden laten ontsporen—en wat ze daaruit leerden voor verdediging.
De kernles: als je AI-agenten laat handelen alsof het de gebruiker is, moet je ook kunnen bewijzen wie of wat die acties stuurde, binnen welk doel (scope) en onder wiens rechten. Zonder die signalen worden “snelle” agent-interfaces al snel een snelle route naar misbruik van privileges.
Wat ging er mis met de AI-agent browserregels?
De uitgangssituatie klinkt bekend. Klanten krijgen meestal drie adviezen voor het beveiligen van AI-agenten: geef de agent een eigen identiteit, zorg voor toegang die past bij de taak, en houd traceerbaarheid apart van menselijke activiteit. Voor één organisatie gold: ze volgden die ideeën—totdat ze een agent bouwden die standaard alles brak.
Hun agent werkte als een UI-agent in de browser. Hij opende zelfstandig pagina’s in dezelfde tab, zette filters en vulde formulieren in. Vanuit security-oogpunt was het dus een typisch scenario: de agent bevindt zich in de gebruikerssessie en heeft daardoor hetzelfde bereik.
Het probleem is niet alleen dat de agent kan klikken. Het probleem is dat voor de serverkant de interacties niet te onderscheiden zijn van echte gebruikershandelingen, omdat in sessiecookies geen info zit die aangeeft welke “driver” (mens of agent) de sessie aanstuurt.
De agent: Rehearsal die doet in plaats van vertelt
De onderzoekers bouwden een agent genaamd Rehearsal. De taak was om vragen te beantwoorden binnen een platform door daadwerkelijk acties uit te voeren. Dus niet alleen tekst genereren, maar de browser gebruiken zoals een mens dat zou doen: navigeren, elementen bedienen en formulieren invullen.
Juist die combinatie—browsergedreven UI-automatisering in een bestaande sessie—maakte Rehearsal bruikbaar én gevaarlijk. Bruikbaar, omdat de agent precies kan doen wat gebruikers in een dashboard zouden doen. Gevaarlijk, omdat de applicatie niet automatisch kan achterhalen dat een agent de handelingen heeft uitgevoerd.
Waarom “individuele controle” moeilijk is zonder aparte agent-lane
Wat in dit verhaal opvalt, is dat het best goed kan gaan wanneer één partij zowel de agent als de bijbehorende applicatie beheert. Dan kun je interne gaten dichten. Maar dat helpt niet als jouw agent door een derde wordt geleverd of als je standaardagenten koppelt aan allerlei SaaS-platformen.
De onderzoekers konden bijvoorbeeld het volgende doen omdat ze alles zelf konden controleren: de agent gaf aan wie de sessie “driver” was, en de platformlaag kon die informatie gebruiken. In een situatie waarin jouw browseragent een CRM of cloudconsole aanstuurt die je niet beheerst, ontbreekt die mogelijkheid.
Dan geldt een harde realiteit: de applicatie ziet de identiteit van de gebruiker, en de agent weet niet automatisch welke velden “geheim” zijn, welke knoppen gevoelige acties starten en waar de juiste taakgrenzen liggen. Bovendien draagt de sessie de menselijke identiteit, waardoor de agent—zonder extra signalen—onder die rechten opereert.
Verdedigingslessen uit het “break all rules”-experiment
Het team beschrijft meerdere best practices die alleen overtuigend werken wanneer je de agent zelf kunt sturen en beperken. Hieronder de belangrijkste elementen die ze toepasten.
1) Maak controle zichtbaar tijdens het handelen
Terwijl de agent beweegt, zouden apps het moeten dimmen en vergrendelen, en duidelijk moeten aangeven dat een agent de controle heeft. Zo is er minder kans op misverstanden en krijgen gebruikers een herkenbaar “state change” op het moment dat er automatisch wordt ingegrepen.
2) Log alles per sessie, ook wanneer acties worden geblokkeerd
Traceerbaarheid betekent niet alleen het achteraf terugkijken op succesvolle acties. Noteer ook stappen die zijn tegengehouden. Dat geeft securityteams context om te begrijpen welke paden de agent probeerde te nemen en waar de remmechanismen al dan niet werkten.
3) Beperk de reach van de agent tot taak-specifieke rechten
Rehearsal kreeg in hun eigen setup een beperkte rol: dashboards stonden read-only, de agent kon niet opslaan zonder expliciete goedkeuring van de gebruiker, en hij vulde geen geheime velden. Ook verstuurde hij geen verzoeken die het platform weigerde.
Een interessant detail is dat de agent pagina-interacties begreep via accessibility labels. Dat is vooral relevant als je UI-gestuurde agenten wilt beperken tot wat je expliciet “veilig” vindt om te gebruiken.
Belangrijk: dit werkte voor hen omdat ze een agent konden bouwen die afhankelijk was van toegang die niet door externe agenten kan worden overgenomen.
Wat moet er gebeuren “voor iedereen”, niet alleen in je eigen systeem?
De onderzoekers kunnen Rehearsal een actor, scope en een pagina-‘map’ geven, omdat ze de agent hebben geschreven. Een browseragent die je CRM of cloudconsole bestuurt, heeft dat niet. De applicatie kan dan niet automatisch zien dat de agent bezig is, en de agent kan niet betrouwbaar interpreteren welke UI-elementen welke semantiek hebben.
Hun oplossing-lijn: creëer “lanes” voor agenten die gescheiden zijn van menselijke gebruikers. De webwereld bouwt daar al onderdelen voor, maar het verhaal stelt ook dat het nog ontbreekt aan een holistische laag die alle puzzelstukjes samenbrengt.
Browser-lane: agenten tonen en acties beperken
Het browsermodel zou moeten kunnen markeren wanneer een agent actief is. Verder kan de browser high-stakes handelingen pauzeren of om toestemming vragen. De onderzoekers noemen voorbeelden waarin browserfunctionaliteit agentisch browsen beperkt tot relevante sites en waar approvals nodig zijn bij gevoelige acties zoals betalingen of massale verzendingen.
App-lane: acties als tools met semantiek (read-only of consequential)
Een tweede lijn is dat een applicatie acties expliciet publiceert als tools die een agent kan aanroepen. In zo’n ontwerp kan elke tool worden gemarkeerd als read-only of als “consequential” (met impact). Daardoor hoeft de agent niet te gokken wat een knop doet.
Agent-lane: agent identificeerbaar maken met ondertekening
Daarnaast noemen ze de mogelijkheid dat een agent zijn requests kan ondertekenen. Een ontvangende site kan dan verifiëren welke agent de actie initieerde.
Het ontbrekende schakelpunt: context die agents echt veilig maakt
Wat er volgens dit verhaal nog mist, is een laag die agent-lanes verbindt. Elke lane weet iets anders: de browser weet dat er agentsturing is, maar kan de applicatie niet altijd vertellen hoe die agent zich verhoudt tot delegatie en scope. Een tool in de applicatie-context draait vaak binnen dezelfde rechten als de gebruiker, waardoor je scope niet automatisch verkleint. En een identificatie van de agent alleen is niet genoeg als je óók de “persoon achter de delegatie” en het “doelbereik” nodig hebt.
Het gevolg: de applicatie eindigt met context die niet direct leidt tot een afgewogen autorisatiebeslissing. En zonder drie signalen samen—agentidentiteit, een verifieerbare koppeling aan de persoon en een scope die smaller is dan de menselijke rechten—wordt een snelle agent-lane een snelle route naar privilege-misbruik.
Wat security teams nu al kunnen doen
Wachten op standaarden is volgens de onderzoekers geen optie. Je kunt al beginnen met ontdekken, analyseren en beperken zodra je agentic browsen of extensies signaleert.
- Inventariseer browseragents, agentic extensies en endpointagents die handelingen kunnen uitvoeren via ingelogde sessies. Koppel ze aan gebruikers en eigenaren.
- Traceer per agent consumer wie (en welke andere agents) gebruikmaakt van welke agent. Zo weet je welke afhankelijkheden echt in productie staan.
- Review identiteit en rechten die een agent krijgt. Niet alleen wie de gebruiker is, maar welke effectieve privileges de agent erft.
- Zoek attack paths waarin agents toegangscotrols kunnen omzeilen. Kijk daarbij naar flows die dezelfde UI-kanaal gebruiken als echte gebruikers.
- Forceer expliciete goedkeuring of step-up verificatie voordat gevoelige of onomkeerbare acties plaatsvinden.
- Vraag kritische SaaS-leveranciers of hun auditrecords agentactiviteit onderscheiden van menselijke activiteit, en of ze delegatie op taakniveau ondersteunen.
Totdat browser en applicatie agentidentiteit, menselijke delegatie en taak-scope samen kunnen vervoeren, adviseren ze om elk agentgebruik via een menselijke sessie te behandelen als gedelegeerde toegang: dus ontdekken, beperken en auditen.
Praktische vervolgstap: leer van eerdere patch- en misbruikcases
Hoewel dit verhaal vooral gaat over identiteit en scope bij agentgedrag, past het in dezelfde bredere realiteit: securityteams moeten snel kunnen handelen zodra een nieuw aanvalspad opduikt. Denk aan eerdere updates waarbij kwetsbaarheden of misbruikscenario’s zichtbaar werden door patch- en monitoringprocessen.
Als je je organisatie voorbereid wilt krijgen op snelle veranderingen, helpt het om ook te volgen wat er in patchcycli gebeurt. Bijvoorbeeld: Microsoft patcht 1.259 lekken, Outlook-exploit met NTLMv2 en ICS Patch Tuesday: Node2Shell en Siemens-issues laten zien hoe belangrijk snelle detectie en respons zijn, ook wanneer de dreiging zich anders voordoet dan verwacht.
Conclusie
De belangrijkste ontdekking uit dit onderzoek is eenvoudig maar confronterend: een AI-agent die in dezelfde browser en onder dezelfde sessierechten werkt als de gebruiker, kan voor een applicatie “menselijk” lijken—waardoor controle op identiteit, delegatie en taakbereik tekortschiet. Door hun eigen AI-agent browserregels bewust te laten falen, maakten de onderzoekers duidelijk wat er nodig is om agenten verdedigbaar te gebruiken: scheiding in lanes, semantiek over acties, en bovenal een combinatie van agentidentiteit, verifieerbare delegatie en scope.
Voor securityteams betekent dit nu vooral actie: inventariseer agentic tooling, audit effectief rechtengebruik, forceer stap-up checks bij risicovolle handelingen en eis dat leveranciers audit- en delegatiecontext beter ondersteunen. Zo voorkom je dat “agentisch” handelen verandert in een snelle, efficiënte route naar misbruik.
Bron: https://thehackernews.com/2026/11/we-built-agent-that-broke-all-of-our.html
