Hugging Face hacket av AI-agent – forsvarerne svarte med lokal AI

Sikkerhetsbruddet hos Hugging Face ble ifølge selskapets foreløpige rapport drevet av et autonomt AI-agentsystem, og forsvarerne måtte bruke egne AI-agenter for å forstå over 17 000 registrerte hendelser. Det er den viktige nyheten her. Ikke at en chatbot skrev litt tvilsom kode, men at AI drev et helt angrep fra start til slutt.

Angrepet begynte i Hugging Faces datapipeline, fortsatte med tilgang til noder og stjålne legitimasjonsopplysninger, og beveget seg videre til flere interne klynger gjennom en helg. Samtidig brukte Hugging Face AI både til å oppdage avvikene og til å rekonstruere hva angriperen hadde gjort. Selskapet sier analysen tok timer i stedet for dager.

Så kommer den nesten komisk presise haken: De kommersielle AI-modellene Hugging Face først prøvde til etterforskningen, nektet å behandle ekte angrepskommandoer og skadevaredata. Angriperen fulgte naturligvis ingen bruksvilkår. Forsvarerne ble stoppet av sine. Dermed måtte Hugging Face kjøre den åpne modellen GLM 5.2 på egen infrastruktur.

Hva skjedde i sikkerhetsbruddet hos Hugging Face?

Hugging Face opplyser at en ondsinnet datasamling utnyttet to veier til kodekjøring i selskapets behandling av datasett. Angriperen fikk deretter tilgang på nodenivå, hentet sky- og klyngelegitimasjon og beveget seg videre inn i flere interne klynger over en helg.

Den ene veien skal ha vært en datasettlaster som kunne kjøre ekstern kode. Den andre var template injection i en datasettkonfigurasjon. Dette er ikke bare en tilfeldig serverfeil med AI klistret på overskriften. Angrepet traff et område som er spesielt for en plattform der brukere laster opp modeller, kode og datasett som andre systemer skal behandle.

Hugging Faces egen dokumentasjon viser hvorfor dette området krever forsiktighet. Datasets-biblioteket kjører ikke datasett-script som standard av sikkerhetsgrunner; brukeren må uttrykkelig tillate ekstern kode med trust_remote_code=True. I dette innbruddet sier selskapet at sårbarheten lå i deres interne behandlingspipeline, og at de to aktuelle veiene til kodekjøring nå er stengt.

Her er det viktig å skille mellom det Hugging Face har fastslått og det som fortsatt er ukjent. Selskapet mener kampanjen ble kjørt av et autonomt agentrammeverk med tusenvis av handlinger fordelt på kortlivede sandkasser. Men de vet ikke hvilken språkmodell angriperen brukte, eller om det var en manipulert kommersiell modell eller en modell med åpne vekter.

Hvor omfattende var innbruddet?

Det bekreftede omfanget var begrenset tilgang til enkelte interne datasett og flere legitimasjonsopplysninger brukt av Hugging Faces tjenester. Da Hugging Face publiserte hendelsesrapporten 16. juli 2026, var vurderingen av mulig påvirkning på kunde- og partnerdata fortsatt ikke ferdig.

Selskapet fant ikke bevis for at offentlige modeller, datasett eller Spaces var endret. De sier også at containerbilder og publiserte programvarepakker ble kontrollert og funnet rene. Det er beroligende, men formuleringen betyr ikke at hele saken var ufarlig. Tilgang til interne datasett og legitimasjonsopplysninger er et reelt produksjonsinnbrudd, selv når den offentlige programvareforsyningen ser ut til å ha sluppet unna.

Hugging Face fjernet angriperens fotfeste, bygget kompromitterte noder på nytt og roterte berørte nøkler og tokens. I tillegg startet selskapet en bredere rotasjon som forholdsregel, strammet inn adgangskontrollen i klyngene og endret varslingen slik at alvorlige signaler skal nå en person i løpet av minutter.

For vanlige brukere er anbefalingen konkret: Roter tilgangstokenet ditt og se gjennom nylig aktivitet på kontoen. Hugging Face anbefaler generelt ett token per applikasjon og finmaskede tokens i produksjon. Da kan én nøkkel trekkes tilbake uten å velte alt annet, og skaden blir mindre hvis en nøkkel lekker.

Hvordan kunne AI avsløre et AI-angrep?

Hugging Face bruker språkmodeller til å sortere sikkerhetssignaler fra vanlig støy i telemetrien. Det var sammenhengen mellom slike AI-vurderte signaler som først flagget innbruddet. Deretter kjørte selskapet analyseagenter over en logg med mer enn 17 000 registrerte hendelser.

Det er denne delen jeg synes er større enn den fristende historien om guardrails som sa nei. Et sikkerhetsteam kan undersøke en enkelt kommando manuelt. Problemet oppstår når et agentsystem sprer titusenvis av små handlinger over midlertidige miljøer, flytter styringen mellom offentlige tjenester og blander reell aktivitet med avledninger. Da er ikke bare angrepet raskere. Selve etterforskningen blir et skaleringsproblem.

Hugging Face sier analyseagentene rekonstruerte tidslinjen, hentet ut indikatorer på kompromittering, kartla hvilke legitimasjonsopplysninger som var berørt og skilte faktisk skade fra avledningsaktivitet. Arbeidet som normalt ville tatt dager, skal ha blitt gjort på timer. Dette er selskapets egen vurdering, ikke en uavhengig måling, men den forklarer hvorfor AI-forsvar ikke lenger bare er en kjekk demo.

Jeg har tidligere skrevet om hvordan prompt injection kan få en AI-assistent til å handle på skjulte instruksjoner. Denne saken er annerledes: Her beskriver Hugging Face et agentsystem som selve angriperen. Fellesnevneren er at sikkerhet må handle om mer enn modellens svar. Tilganger, verktøy, kodekjøring, logger og sandkasser er der handlingene faktisk skjer.

Hvorfor stoppet de kommersielle modellene etterforskningen?

Hugging Faces etterforskere måtte sende store mengder ekte angrepskommandoer, exploit-kode og spor etter kommando- og kontrollsystemet til modellen. Sikkerhetsfiltrene hos de kommersielle API-ene klarte ikke å skille forsvarlig analyse fra et nytt angrepsforsøk, og forespørslene ble blokkert.

Det er lett å forstå hvorfor leverandørene har slike filtre. Et API uten grenser kan senke terskelen for å utvikle skadevare, lete etter sårbarheter og automatisere angrep. Men et filter som bare ser farlig innhold, og ikke hvorfor innholdet behandles, kan også låse ute dem som rydder opp etter et faktisk innbrudd. En røykvarsler som nekter brannvesenet adgang fordi det lukter røyk, har på et tidspunkt misforstått arbeidsdelingen.

Hugging Face navngir ikke API-leverandørene og sier heller ikke nøyaktig hvilke modeller som avviste arbeidet. Derfor bør ingen bruke hendelsen som bevis mot en bestemt leverandør. Det dokumenterte poenget er smalere og viktigere: Et sikkerhetsteam oppdaget under en reell hendelse at avhengigheten av filtrerte eksterne modeller kunne stoppe den nødvendige analysen.

Og angriperen? Hugging Face vet ikke hvilken modell som sto bak, men den var åpenbart ikke bundet av den samme arbeidsflyten. Det er asymmetrien. Bruksvilkår og modellfiltre kan redusere misbruk av en bestemt tjeneste, men de er ikke en sikkerhetsmur rundt internett. En angriper kan bytte modell, manipulere en tjeneste eller kjøre noe selv.

Hvorfor valgte Hugging Face GLM 5.2?

Hugging Face valgte GLM 5.2 fordi modellen kunne kjøres på selskapets egen infrastruktur uten at et eksternt API stoppet sikkerhetsanalysen. Lokal kjøring sørget samtidig for at angriperdata og legitimasjonsopplysninger i loggene ikke forlot Hugging Faces miljø.

GLM 5.2 er publisert med MIT-lisens og åpne vekter, og modellkortet oppgir en kontekstlengde på opptil én million tokens. Lang kontekst er relevant når en analyseagent skal arbeide gjennom store logger og holde sammen en lang hendelseskjede. Hugging Face har ikke publisert den fullstendige analyseoppskriften, maskinvarekravene eller en sammenligning som viser at GLM 5.2 var best av alle tilgjengelige modeller.

Dette er derfor ikke en generell anbefaling om å stole blindt på GLM 5.2, eller på kinesiske modeller for den saks skyld. Valget løste et konkret problem under en hendelse: Hugging Face trengte en kapabel modell de selv kunne kontrollere. Sikkerhetsteamet slapp både innholdsblokkeringen og risikoen ved å sende følsomme logger til en tredjepart.

Poenget er beredskap, ikke modellfandom. Hvis lokal AI først skal være reserveverktøyet når produksjonsmiljøet brenner, hjelper det lite å begynne å teste drivere, kontekstgrenser og analyseprompter etter at alarmen har gått. Modellen, infrastrukturen og arbeidsflyten må være vurdert på forhånd.

Betyr dette at guardrails er verdiløse?

Nei. Hendelsen viser at guardrails har begrensninger, ikke at alle sikkerhetstiltak bør fjernes. Hugging Face sier selv at rapporten ikke er et argument mot vern i kommersielle modeller, og at selskapet deler erfaringene med de aktuelle leverandørene.

Men vi bør slutte å late som modellens høflige avslag er det samme som cybersikkerhet. Guardrails kan gjøre én kommersiell tjeneste mindre praktisk for en angriper. De kan ikke tette en sårbar datapipeline, begrense rettighetene til en stjålet nøkkel eller stoppe lateral bevegelse mellom klynger. Det krever helt vanlige, litt kjedelige sikkerhetslag.

Minst mulige rettigheter, korte levetider på nøkler, isolerte behandlingsmiljøer, god logging og raske varsler blir ikke gammeldagse fordi angrepet bruker AI. Tvert imot. Når en agent kan prøve tusenvis av handlinger i maskinfart, blir hver unødvendig tilgang og hver dårlig avgrenset nøkkel mer verdifull for angriperen.

Det samme gjelder egne AI-agenter. En forsvarsagent må ikke få fri tilgang til produksjon bare fordi den skal hjelpe sikkerhetsteamet. Den trenger avgrensede verktøy, sporbare handlinger og et miljø der feil ikke blir en ny hendelse. Sikkerhetsproblemene rundt åpne AI-agenter forsvinner ikke når agenten jobber for de snille.

Hva bør bedrifter lære av angrepet?

Den viktigste lærdommen er at bedrifter må planlegge for angripere som kan automatisere hele kjeden, ikke bare skrive phishing-meldinger raskere. Samtidig trenger forsvarerne verktøy som kan behandle store hendelseslogger uten å lekke dem eller stoppe midt i analysen.

For en vanlig liten eller mellomstor bedrift betyr ikke det at en enorm språkmodell må stå varm i et serverrom døgnet rundt. Det betyr at noen må vite hvilke logger som finnes, hvor lenge de lagres, hvem som kan hente dem ut og hvilket verktøy som kan analysere dem under en hendelse. En avtale med en sikkerhetspartner kan være mer realistisk enn egen modellinfrastruktur, men avhengigheten bør testes før den trengs.

Bedrifter som bruker Hugging Face bør følge anbefalingen om å rotere tokens og kontrollere nylig aktivitet. Deretter ville jeg gått gjennom om produksjonsnøkler er finmaskede og knyttet til én applikasjon, eller om den samme brede nøkkelen har blitt kopiert inn i fem miljøer fordi det var raskest den dagen. Vi vet alle hvordan den historien pleier å ende.

Hugging Face-hendelsen er heller ikke et bevis på at alle offentlige modeller eller datasett på plattformen er kompromittert. Selskapet fant ingen tegn til endringer i de brukervendte ressursene eller programvareforsyningen. Panikk er unyttig. Tokenrotasjon, tilgangskontroll og kontroll av kontoaktivitet er derimot konkrete handlinger.

AI-angrep krever mer enn AI-svar

Dette innbruddet gjør den agentiske trusselen konkret. Ifølge Hugging Face kjørte angriperen en bred kampanje i maskinfart, mens forsvarerne brukte AI til å finne signalene og komprimere dager med manuelt analysearbeid til timer. Det er et kappløp i fart, men også i tilgang og kontroll.

Den lokale modellen var avgjørende fordi Hugging Face kunne bestemme hva den skulle analysere og hvor dataene skulle bli. Det er et sterkt argument for å ha en selvstyrt reservekapasitet i miljøer der et eksternt API både kan avvise innholdet og innebære at følsomme hendelsesdata forlater virksomheten.

Likevel er ikke svaret bare «kjør en åpen modell». Innbruddet startet i kodekjøring og fortsatte gjennom legitimasjonsopplysninger og interne klynger. Modellen hjalp med å forstå hendelsen. Den erstattet ikke isolasjon, nøkkelrotasjon, gjenoppbygging av noder eller ekstern etterforskning.

Det er kanskje den mest voksne lesningen av saken: AI blir både angriperens skaleringsmotor og forsvarerens analyseverktøy. Men når alt annet svikter, er det fortsatt arkitektur, rettigheter og beredskap som avgjør hvor langt en agent kommer. En guardrail-dialogboks alene redder ingen produksjonsserver.

Ofte stilte spørsmål