AI-fuzzing fant feil i Googles API-er for 500 000 dollar

AI-fuzzing flytter bug bounty fra håndverk til fabrikk

Sikkerhetsforsker Arvin Shivram har publisert en detaljert gjennomgang av hvordan han brukte AI til å teste Googles API-flate i stor skala. Ifølge gjennomgangen gikk arbeidet gjennom rundt 1 500 API-er, mer enn 3 600 API-nøkler og endte med bug bounty-utbetalinger på 500 000 dollar.

Det viktige er ikke beløpet. Det viktige er arbeidsformen. Dette er et konkret eksempel på at AI ikke bare skriver rapporter om sikkerhet. Den kan brukes til å lese maskinlesbare API-beskrivelser, foreslå testløp, prioritere mistenkelige endepunkter og kjøre systematisk sondering langt raskere enn en enkelt forsker ville gjort manuelt.

For norske CISO-er og teknologiledere er signalet tydelig: Angrepsflaten som ligger i interne og eksterne API-er blir mer målbar, mer automatiserbar og mer attraktiv. Det gjelder også virksomheter som aldri blir Google. Når dokumentasjon, SDK-er, discovery-filer, OpenAPI-spesifikasjoner og klientnøkler ligger spredt rundt i apper og repos, kan en AI-assistert aktør bruke dem som kart.

API-dokumentasjon blir angrepskart

Shivram beskriver hvordan Google sine discovery documents, i praksis maskinlesbare beskrivelser av API-er, ble utgangspunkt for arbeidet. Slike dokumenter ligner på Swagger eller OpenAPI: de beskriver endepunkter, parametere, metoder og forventede objekter. Det er gull for utviklere. Det er også gull for automatisert sikkerhetstesting.

Dette er en bredere lærdom. Mange virksomheter har investert i bedre API-dokumentasjon fordi det gjør integrasjoner raskere. Det er riktig. Men den samme dokumentasjonen må behandles som en del av angrepsflaten. Hvis den er offentlig, utdatert, for detaljert eller koblet til svake autorisasjonsmodeller, hjelper den ikke bare partnerne. Den hjelper også de som leter etter hull.

AI forsterker dette fordi modellen kan bruke strukturen direkte. Den trenger ikke forstå hele produktet slik en menneskelig ekspert gjør. Den kan foreslå testvarianter basert på skjemaer, sammenligne mønstre på tvers av endepunkter og lete etter autorisasjonsbrudd, inkonsistens og uventede sideeffekter.

Nøkler, klienter og gamle integrasjoner får ny risiko

Gjennomgangen beskriver også innsamling og analyse av store mengder API-nøkler fra apper og klienter. Poenget for vanlige virksomheter er ikke at alle API-nøkler er hemmeligheter på samme nivå. Poenget er at nøkler, prosjekt-ID-er, gamle mobilklienter og testmiljøer ofte avslører langt mer om systemlandskapet enn organisasjonen tror.

I en manuell sikkerhetstest er det dyrt å følge alle spor. Med AI-assistert fuzzing blir terskelen lavere. En angriper eller forsker kan samle artefakter, mate dem inn i et testoppsett og la agenten foreslå neste steg. Da blir gamle klienter, interne endepunkter, halvglemt dokumentasjon og feilkonfigurerte rettigheter mer interessante.

Det er spesielt relevant for virksomheter som har bygget mange API-er over tid, kjøpt selskaper, latt partnerintegrasjoner leve lenge eller har flere skyprosjekter uten felles governance.

Autorisasjon er fortsatt stedet det ryker

Selv om artikkelen er teknisk, peker funnene mot et kjent mønster: mange alvorlige API-feil handler ikke om avansert kryptografi eller eksotiske minnefeil. De handler om at et endepunkt gjør mer enn brukeren egentlig har lov til, eller at kontrollen er ulik mellom lesing, endring og administrasjon.

Det er nettopp slike feil AI kan hjelpe til med å finne. Hvis modellen har en strukturert oversikt over endepunkter og parametere, kan den teste varianter av «kan jeg lese dette?», «kan jeg endre dette?», «kan jeg gjøre det på et annet prosjekt?» og «hva skjer hvis denne ID-en byttes?». Det er kjedelig arbeid for mennesker. Det er egnet arbeid for automatisering.

Forskjellen fra tradisjonell scanning er at AI kan gjøre mer kontekstuell utforsking. Den kan lese svar, justere hypotesen og prøve en ny rute. Det gjør ikke verktøyet magisk. Det gjør det utholdende.

Hva CISO bør gjøre nå

Første tiltak er å vite hvilke API-beskrivelser som faktisk finnes. OpenAPI-filer, discovery-endepunkter, Postman-samlinger, SDK-er og intern dokumentasjon bør inn i samme oversikt som eksponerte tjenester. Hvis sikkerhetsteamet ikke kjenner kartet, kan andre bruke det først.

Andre tiltak er å teste autorisasjon systematisk. Ikke bare autentisering. Ikke bare om brukeren er logget inn. Test prosjektgrenser, tenantgrenser, rollegrenser, skriveoperasjoner, gamle API-versjoner og administrasjonsendepunkter. Dette bør inn i CI/CD og periodiske kontroller, ikke bare årlig pentest.

Tredje tiltak er å behandle klientnøkler og mobilapper som etterretningskilder. Roter nøkler, begrens scope, fjern døde prosjekter og se etter API-er som fortsatt aksepterer gamle klientmønstre. AI gjør det billigere å grave i slikt materiale.

Fjerde tiltak er å la egne team bruke samme metode defensivt. Hvis en ekstern forsker kan bruke AI til å dekke tusenvis av endepunkter, kan intern sikkerhet gjøre det samme før bug bounty-programmet eller angriperne gjør det. Det krever klare regler, trygge testmiljøer og logging, men alternativet er å la andre industrialisere funnene først.

Fra verktøy til tempoendring

Dette er grunnen til at saken er større enn én bug bounty-historie. AI endrer ikke bare hvilke sårbarheter som finnes. Den endrer tempoet i letingen. Når maskinlesbar dokumentasjon, store API-flater og agentisk testing møtes, blir den økonomiske terskelen for bred sikkerhetstesting lavere.

Det er bra for modne virksomheter. De kan teste mer, oftere og bredere. Det er dårlig nytt for organisasjoner som fortsatt styrer API-sikkerhet med regneark, manuelle godkjenninger og «ingen kjenner til det endepunktet lenger».

Lederkonklusjonen er nøktern: AI-assistert sikkerhetstesting gjør skjult kompleksitet dyrere å bære. API-governance, nøkkelstyring og autorisasjonstesting må opp fra teknisk hygiene til styrets risikobilde.

Kilder og medier

• Primærkilde: Arvin Shivram / Brutecat Security, "Hacking Google with A.I. for $500,000", publisert 11. juni 2026: https://brutecat.com/articles/hacking-google-with-ai/
• Kildekreditering: Brutecat Security / Arvin Shivram
• Thumbnail: OpenAI Image 2 / hogby.ai