🤖 AI

GUI agent: Guided Exploration of User-Sensitive Screens

Dit artikel introduceert een GUI-exploreragent die is ontworpen om systematisch gebruikersgevoelige schermtoestanden en queries te identificeren, waarmee de veiligheidsbeperkingen van huidige door LLM's gestuurde agenten wordt aangepakt door hen in staat te stellen kritieke scenario's te herkennen en overdracht aan menselijke gebruikers aan te vragen.

Oorspronkelijke auteurs: Aradhana Nayak, Mussadiq Nazeer, Wang Peng, Feng Liu

Gepubliceerd 2026-06-25

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Aradhana Nayak, Mussadiq Nazeer, Wang Peng, Feng Liu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer slimme, enthousiaste robotassistent hebt (een AI-agent) die voor je op je telefoonscherm kan tikken, apps kan openen en taken voor je kan uitvoeren, zoals boodschappen doen of een agenda-herinnering instellen. Deze robot is geweldig in het opvolgen van instructies, maar heeft een gevaarlijke gewoonte: hij weet niet wanneer hij moet stoppen en om hulp moet vragen.

Als de robot een scherm ziet dat om je wachtwoord vraagt, of een scherm waar hij per ongeluk je foto's zou kunnen verwijderen, kan hij gewoon doorgaan met handelen. In de echte wereld is dit riskant. Je wilt dat de robot zegt: "Hé, dit ziet er belangrijk uit. Laat me even pauzeren en de controle aan jou overlaten," voordat hij iets onomkeerbaars doet.

Dit artikel introduceert een nieuwe tool genaamd een "Explorer Agent", ontworpen om deze robotassistenten te leren hoe ze die "gevarenzones" op eigen kracht kunnen vinden.

Hier is hoe het artikel hun methode uitlegt, met eenvoudige analogieën:

1. Het Probleen: De Robot die niet om hulp vraagt

Huidige AI-robots worden getraind om taken te voltooien, ongeacht wat er gebeurt. Als een taak een gevoelig scherm inhoudt (zoals een bankoverschrijving of het verwijderen van bestanden), kan de robot gewoon op "bevestigen" klikken zonder na te denken. De auteurs zeggen dat dit lijkt op het geven van een auto aan een kind en zeggen dat het naar de winkel moet rijden, zonder de controle te leren over het stoppen voor een rood licht. Het werkt voor simpele ritjes, maar is gevaarlijk voor complexe reizen.

2. De Oplossing: De "Kaartmaker"-robot

In plaats van alleen de robot te leren rijden, hebben de auteurs een speciale "Explorer"-robot gebouwd. Zijn enige taak is om rond te dwalen door de telefooninterface en alle lastige, gevoelige schermen te vinden voordat de hoofdrobot ze ooit te zien krijgt.

Denk aan het als een verkenner die vooruit wordt gestuurd in een bos. De taak van de verkenner is niet om bomen te kappen of een huis te bouwen; het is om de kliffen, de moerassen en de verborgen vallen te vinden, zodat het hoofdteam weet waar ze niet heen moet gaan zonder toestemming.

3. Hoe de Explorer werkt (De "MCTS"-methode)

Het artikel gebruikt een methode genaamd MCTS (Monte Carlo Tree Search). Stel je voor dat de Explorer een spelletje "Wat als?" speelt.

Het startpunt: De Explorer begint met één eenvoudige taak die je hem gaf, zoals "Zet de wifi aan."
Verbreden: Hij vraat zichzelf af: "Wat als ik in plaats daarvan op deze knop klik? Wat als ik een ander wachtwoord typ? Wat als ik eerst naar het instellingenmenu ga?"
De "Nieuwigheidsscore": De Explorer houdt een mentale lijst bij van elk scherm dat hij heeft gezien. Als hij een scherm vindt dat hij nog nooit heeft gezien (een "nieuw" scherm), krijgt hij een hoge score. Als hij een scherm vindt dat hij al honderd keer heeft gezien, krijgt hij een lage score.
Het doel: Hij wil schermen vinden die niet alleen nieuw zijn, maar ook gevoelig (zoals schermen met persoonlijke gegevens).

4. De Trainingslus: Leren door te doen

De auteurs hebben deze Explorer getraind over drie "rondes" (zoals levels in een videogame):

Ronde 1: De Explorer is wild en gek. Hij probeert honderden verschillende paden. Hij vindt veel nieuwe schermen, maar maakt ook veel fouten en raakt in de war.
Ronde 2 & 3: De Explorer wordt slimmer. Hij leert van zijn eerdere pogingen. Hij stopt met tijd verspillen aan paden die nergens toe leiden en richt zich op het vinden van de specifieke "gevoelige" schermen.
Het resultaat: Naarmate de training vorderde, vond de Explorer minder nieuwe schermen. Dit klinkt slecht, maar het artikel zegt dat het eigenlijk goed is. Het betekent dat de Explorer bijna alle gevaarlijke gebieden heeft in kaart gebracht. Hij heeft de ruimte "verzadigd", wat betekent dat hij weet waar de vallen zitten.

5. De "Verzadigingscheck"

Het artikel bevat een speciaal algoritme om te weten wanneer de exploratie moet stoppen. Stel je voor dat je een muur schildert. In het begin bedek je met elke penseelstreek veel nieuw terrein. Maar uiteindelijk schilder je gewoon steeds weer over dezelfde plekken. Het algoritme detecteert wanneer de Explorer zichzelf aan het herhalen is en zegt: "Oké, we hebben alle unieke gevoelige schermen gevonden. We kunnen nu stoppen."

6. Wat ze hebben gevonden

Betere modellen werken beter: Ze hebben verschillende AI-hersenen voor de Explorer getest. De grotere, intelligentere AI (Qwen-2.5-32B) was veel beter in het vinden van nieuwe, interessante paden dan de kleinere modellen.
Nauwkeurigheid verbeterde: Naarmate ze de Explorer trainden, werd hij beter in het voorspellen van wat er precies zou gebeuren als hij op een knop klikte.
De ruimte krimpt: De belangrijkste bevinding was dat het "onbekende" gebied van de telefooninterface met elke trainingsronde kleiner werd. De Explorer heeft de grenzen van de door de gebruiker gevoelige schermen succesvol geïdentificeerd.

Samenvatting

Kortom, dit artikel presenteert een manier om een AI te trainen om te fungeren als een veiligheidsinspecteur voor andere AI-agenten. In plaats van te hopen dat de robot weet wat veilig is, gebruiken we deze "Explorer" om systematisch elk scherm te vinden dat privé of gevaarlijke informatie bevat. Zodra de Explorer deze gebieden heeft in kaart gebracht, kan de hoofdrobot worden geprogrammeerd om te stoppen en om toestemming van de menselijke gebruiker te vragen voordat hij deze zones betreedt.

Het artikel beweert niet dat dit een afgewerkt product is dat vandaag al op je telefoon beschikbaar is; het is eerder een methodologie en een dataset-generatietool om ingenieurs te helpen in de toekomst veiligere AI-agenten te bouwen.

Technische Samenvatting: GUI Agent: Geleide Exploratie van Gebruikersgevoelige Schermen

Probleemstelling
Large Language Model (LLM) agents worden steeds vaker ingezet om taken te automatiseren binnen open Graphical User Interface (GUI) omgevingen. Deze agents komen echter onvermijdelijk schermen tegen die gebruikersgevoelige informatie bevatten (bijv. financiële gegevens, privéberichten), waarbij autonome uitvoering risico's voor de privacy en veiligheid met zich meebrengt. Huidige state-of-the-art LLM-gestuurde agents zijn doorgaans gefinetuned om taken te voltooien ongeacht de veiligheidsimplicaties, wat hun inzet in de echte wereld bemoeilijkt en de betrouwbaarheid vermindert. Bovendien werken GUI-agent workflows vaak in gesloten lussen waar acties onomkeerbaar zijn (bijv. bestanden verwijderen, e-mails verzenden), en een enkele fout kan leiden tot cascadefouten. Er is een kritieke behoefte om gebruikersgevoelige staten te identificeren en te categoriseren en om "gebruikersgevoelige queries" te definiëren om agents in staat te stellen te herkennen wanneer zij menselijke overdracht moeten aanvragen. Bestaande exploratiemethoden missen vaak een rigoureuze dekking van de oplossingsruimte of falen specif으로 om specifiek op gebruikersgevoelige staten te richten.

Methodologie
Het paper stelt een framework voor dat gecentreerd is rond een Explorer Agent, ontworpen om systematisch de query-ruimte van een GUI-applicatie te verkennen, uitgaande van een enkele gedemonstreerde taak, om queries te identificeren die leiden naar gebruikersgevoelige staten. Het framework maakt gebruik van twee modellen:

Native LM: Bepaalt acties tijdens de uitvoering (bijv. M3A).
Explorer LM: De kernbijdrage, iteratief getraind met als doel pure exploratie. Het beleid bepaalt welke knopen verkend moeten worden op basis van beloningen afgeleid van de nieuwheid en de gebruikersgevoeligheid van de knopen.

De methodologie volgt een iteratieve trainingslus (Algoritme 1) bestaande uit drie hoofdfasen:

Query Selectie, Expansie en Saturatie:
- De Explorer LM genereert batches queries ( $N \times M$ episodes) op basis van een basis-traject ( $T_0$ ) en een instructie.
- Een Query Selectie Algoritme ( $A_{sel}$ ) filtert deze queries. Het berekent vectorrepresentaties en gebruikt cosinus-gelijkenis om alleen queries te behouden die nieuw zijn (lage gelijkenis met de bestaande pool en binnen de batch) en verschillend zijn van het initiële traject.
- Een Saturatie Check Algoritme ( $A_{sat}$ ) monitort het generatieproces. Het past lineaire en polynomiale curves toe op het aantal behouden queries per batch om een buigpunt te detecteren waar het model stopt met het genereren van nieuwe queries, wat duidt op saturatie.
Roll-out met Emulator:
- Geselecteerde queries worden uitgevoerd in een Android-emulator (met gebruik van de SPABench setup).
- De Native LM voert acties uit, en het systeem legt screenshots en actielogs vast.
- Dit proces genereert een "memory bank" van episodes met queries, stappen, schermbeschrijvingen en embeddings.
Training (Backpropagation):
- In plaats van standaard MCTS backpropagation, wordt de Explorer LM getraind met behulp van Group Relative Policy Optimization (GRPO).
- Het trainingsdoel is duaal: (1) nauwkeurige stappen genereren (via Supervised Fine-Tuning op prompt-response paren) en (2) nieuwe queries genereren die leiden naar nieuwe gebruikersgevoelige staten (via GRPO met een aangepast beloningsmodel).
- Beloningsmodellering: De beloningsfunctie ( $R$ $R$ ) is samengesteld uit drie nieuwheidsscores:
  1. Query Nieuwheid: Gebaseerd op K-means clustering inertie en clusterindices.
  2. Stap Nieuwheid: Gebaseerd op de cosinus-gelijkenis van "actionPurpose" stappen tegen de memory bank.
  3. Categorie Nieuwheid: Gebaseerd op de frequentie van schermcategorieën (specifiek het markeren van "critic" of gevoelige categorieën).

Kernbijdragen

Explorer Agent Framework: Een nieuw algoritme om gebruikersgevoelige queries en schermen te isoleren uitgaande van een enkele door de gebruiker gedefinieerde traject, gebruikmakend van ervaringsextractie uit vorige iteraties.
Nieuwheidsgestuurd Beloningssysteem: Een samengestelde beloningsfunctie die de nieuwheid van queries, stappen en schermcategorieën kwantificeert om de agent te leiden naar onverkende, potentieel gevoelige staten.
Saturatie Detectie: Een algoritmische benadering om te bepalen wanneer de exploratieruimte voldoende is gedekt, om redundante trainingsiteraties te voorkomen.
Potentieel voor Dataset Generatie: De methode beoogt een dataset van gebruikersgevoelige queries te produceren om engineers te helpen bij het herkennen van kritieke scenario's en het aanvragen van gebruikersoverdracht.

Resultaten
De auteurs voerden drie trainingsrondes uit met het Qwen-2.5-32B-Instruct model als de Explorer LM; kleinere modellen (Llama3.1-8B, Qwen2.5-3B) slaagden er niet in om voorbij het initiële scherm te komen.

Convergentie: De totale beloning nam progressief af met ordes van grootte (van $10^{-2}$ naar $10^{-5}$ ) over de rondes, wat wijst op een inkrimping van de query- en schermruimte naarmate de agent de omgeving verzadigde.
Saturatie: Het aantal queries dat nodig was om saturatie te bereiken, nam significant af over de rondes (160 queries in Ronde 1, 100 in Ronde 2, 70 in Ronde 3).
Stap Nauwkeurigheid: De standaarddeviatie van de stap-nieuwheidsscores daalde aanzienlijk van Ronde 1 (~~0.0686) naar de Rondes 2 en 3 (~~0.0024 en ~0.0068), wat suggereert dat Supervised Fine-Tuning (SFT) de nauwkeurigheid van stapvoorspellingen heeft verbeterd.
Instruction Tuning: Nieuwheidsscores namen af naarmate het aantal batches toenam binnen een ronde, wat aantoont dat instruction tuning de generatie van nieuwe queries in opeenvolgende batches mogelijk maakt.

Betekenis en Claims
Het paper claimt een systematische methode te bieden voor het autonoom verkennen van GUI query-ruimtes om gebruikersgevoelige staten te identificeren. Het stelt dat door het exploratiebeleid iteratief te optimaliseren, het framework prioriteit kan geven aan onbezochte staten en de dekking van de diversiteit van schermen kan verbeteren. De auteurs stellen dat het krimpen van de query-ruimte in opeenvolgende rondes dient als bewijs van dekking. Ze suggereren dat deze aanpak engineers kan helpen bij het ontwerpen van trainingsdatasets voor applicatiespecifieke doeleinden en de veiligheid van LLM-agents kan verbeteren door hen in staat te stellen te herkennen wanneer ze moeten stoppen en om gebruikersinterventie moeten vragen. Het paper concludeert bescheiden door op te merken dat hoewel de methode veelbelovend is, verder onderzoek nodig is om hoog-gelijke queries (bijv. "zet meldingen aan" versus "zet meldingen uit") te behandelen en om agressievere zoekstrategieën te bereiken.