Googles Gemini-agent har funnet over 500 XSS-feil i produksjon siden januar
Google har publisert et paper om PageBreak, en autonom sikkerhetsagent drevet av Gemini som har funnet mer enn 500 XSS-sårbarheter i selskapets produksjonsapplikasjoner siden januar 2026. Det som skiller agenten fra klassiske skannerboter, er ikke hva den finner, men hva den ikke rapporterer: ingen hypotese blir en sårbarhetsrapport før en determinisk validator har gjenskapt selve utnyttelsen mot et system som faktisk kjører. Denne saken bygger på iMasters' dekning av paperet, som selv viser til InfoQ — ingen primærkilde foreligger.
Hva som er nytt
Ifølge iMasters, som siterer InfoQ — som har hatt tilgang til materialet — publiserte Google denne uken et paper som beskriver PageBreak, en sikkerhetsagent basert på Gemini-modeller som undersøker sårbarheter autonomt i selskapets webapplikasjoner. Systemet har vært i full drift siden januar 2026, og har i den perioden funnet over 500 feil av typen XSS (cross-site scripting) i produksjon, ifølge InfoQ. Det er altså ikke et konsept eller en pilot: agenten jobber mot Googles faktiske produksjonsmiljø, og funnene påstås å være reelle, bekreftede sårbarheter i kode som er i bruk.
Slik fungerer hypotese-og-bevis-pipelinen
Arkitekturen beskrives som en logikk av hypotese og verifisering. Gemini-modellen analyserer kode og foreslår hypoteser om potensielle feil. Men hver hypotese blir bare til en rapport hvis den består en konkret test mot et kjørende miljø — en determinisk validator, skrevet av mennesker, må reprodusere utnyttelsen.
Paperet gir eksempler på hva «bevis» betyr per feilklasse:
- XSS: kjøre faktisk JavaScript for å bekrefte at skriptet faktisk kjører.
- Path traversal: skrive til en offentlig lesbar lokasjon for å vise at banen faktisk kan forlate den tiltenkte katalogstrukturen.
- RCE (remote code execution): utløse et utgående DNS-oppslag for å bekrefte at vilkårlig kode faktisk kan kjøres.
Poenget med disse testene er at de er enten/eller: enten skjedde noe observerbart og deterministisk, eller så gjorde det ikke. LLM-en kan ta feil, ha dårlig strukturert resonnering eller hallusinere — men den kan ikke få en hypotese gjennom en kodeport som fysisk må lykkes med å utnytte et kjørende system.
Hvorfor designet er viktig: tillitsproblemet
Sikkerhetsskanneres store kostnad for teamene som skal motta funnene, er falske positiver. En skanner som flagger tusen potensielle problemer, hvor hundre av dem er reelle, tar produktteamets tid og — verre — ødelegger tilliten til skanneren. Hvis folk slutter å tro på rapportene, slutter de å fikse tingene.
Michał Bentkowski, informasjonssikkerhetsingeniør hos Google, sier at teamet bevisst prioriterte determinisk validering fra starten av utviklingen:
«Fra begynnelsen av PageBreak-utviklingen tok vi den bevisste beslutningen å prioritere determinisk validering. I stedet for bare å foreslå feilhypoteser basert på kodemønstre, lukker systemet loopen ved å verifisere potensielle feil mot kjørende miljøer. Denne tilnærmingen gir en falsk-positiv-rate nær null, slik at vi ikke overbelaster produktteamene med uverifiserte sårbarhetsrapporter.» (gjengitt via iMasters)
Merk at Bentkowski ikke oppgir et eksakt tall for falsk-positiv-raten — bare at den er «nær null». Det er en påstand fra Google-teamet, gjengitt av iMasters; uavhengig verifisering foreligger ikke.
Hva AppSec-team kan gjøre uten Googles skala
iMasters gir redaksjonelle råd om hva team som ikke har Googles infrastruktur kan låne fra designet. Dette er iMasters' analyse, ikke Googles anbefalinger:
- Skill hypotesegenerering fra validering. La en LLM foreslå, men krev bevis gjennom faktisk kjøring før noe sendes videre.
- Skriv validatorene som vanlig, determinisk kode, utenfor agent-loopen. Validatoren skal ikke «resonnere» — den skal kjøre en test og si ja eller nei.
- Behold uverifiserte funn. Hypoteser som ikke lot seg bekrefte kan bidra til å utvide validatordekningen over tid.
- Integrer med eksisterende verktøy som OWASP ZAP eller Burp Suite. Man trenger ikke bygge hele infrastrukturen fra bunnen av for å få nytte av en hypotese-og-verifisering-loop.
Disse punktene krever ikke Gemini eller Googles skala — de krever en vilje til å bygge testverktøy som kan bevise en utnyttelse fremfor å gjette.
Åpne spørsmål
Enkelte ting som ellers ville vært interessante å vite, er ikke dokumentert i det tilgjengelige materialet, som per nå kun foreligger gjennom iMasters' sekundære dekning av InfoQ:
- Hvordan telles de 500+ funnene? Er det unike sårbarheter, eller ulike forekomster av samme type feil? Hva er alvorlighetsgraden?
- Er feilene rettet og/eller offentliggjort? Det er uklart om XSS-funnene har ført til rettelser, og om noen av dem er blitt eksternt publisert eller kun håndtert internt i Google.
- Hvordan fungerer agenten i detalj? Full arkitekturbeskrivelse, planlegging, iterasjon og samspillet mellom LLM-en og validatoren i valideringssteget er ikke tilgjengelig i dette materialet.
- Når og hvor ble paperet publisert? iMasters skriver at Google publiserte det «denne uken» (i praksis, i løpet av uken 31. oktober 2026), men eksakt dato og publiseringssted er ikke bekreftet.
Inntil et primærdokument fra Google eller InfoQ foreligger, bør det 500-tallet og januar-datoen forstås som påstander gjengitt gjennom to ledd av sekundærkilder — ikke som dokumenterte tall fra Google selv.