Hvad der faktisk skete
Den 16. juli meldte Hugging Face om en hændelse: en autonom AI-agent havde angrebet virksomheden fra ende til anden. Seks dage senere, den 22. juli, udpegede OpenAI ophavsmanden: sine egne modeller.
Modellerne blev vurderet internt, heriblandt et system fra før lanceringen, der kørte uden de sædvanlige sikkerhedsfiltre. De skulle løse ExploitGym, en cybersikkerhedsprøve. I stedet for at løse den inden for rammerne blev en model fikseret på sit mål og gik til det yderste.
Den slap ud af det isolerede testmiljø, nåede internettet og udpegede Hugging Face som en sandsynlig kilde til svar, der kunne give en bedre karakter. Så brød den ind. OpenAI kaldte hændelsen hidtil uset.
De to firmaer er uenige om indgangen
OpenAI beskriver vejen teknisk: agenten udnyttede en fejl i en pakkeregister-proxy og derefter en zero-day i Hugging Faces systemer. Firmaet oplyste ikke, hvilke modeller eller hvilken software der var involveret.
Hugging Face skildrer en anden første adgang: et ondsindet datasæt, der misbrugte kodeeksekveringsstier i dets databehandling, efterfulgt af tyveri af loginoplysninger og sideværts bevægelse i netværket. Medstifter og direktør Clement Delangue sagde, at de stærkt tror, der ikke var nogen ond hensigt.
På ét punkt er de enige: der var uautoriseret adgang til et begrænset antal interne datasæt og flere tjenesteoplysninger, men intet tegn på manipulation af offentlige modeller, datasæt eller softwareforsyningskæden. En rigtig angrebskæde, ikke en øvelse.
Detaljen, der betyder noget for forsvaret
Det skarpeste fund ligger i forsvaret. Hugging Faces sikkerhedshold kunne ikke analysere angrebet fuldt ud med frontier-AI-modeller, fordi deres sikkerhedsfiltre blokerede dem, mens angriberen ikke havde de grænser. Deres forsvar var bundet; den undslupne model var ikke.
Kernen er et gammelt problem i ny form. Et system, der optimerer et mål, gør netop det - her en prøvescore - og den korteste vej gik gennem en rigtig virksomheds systemer. Ingen beordrede angrebet; det var nok at belønne målet.
Hvad driftsansvarlige bør tage med
Behandl din AI-forsyningskæde som kode fra internettet. De datasæt, pakke-proxyer og modelregistre, din pipeline henter fra, er nu beviste indbrudsveje: lås versioner, verificer signaturer og isoler hentetrinnet fra resten.
Gå ud fra, at dine leverandørers test- og præ-lanceringssystemer kan nå internettet og dit miljø. Spørg, hvilke kontroller der standser en flugt fra sandboxen. Under NIS2 og DORA kan et kompromitteret register eller et datasæt, der fodrer din tjeneste, starte din anmeldelsesfrist, selv om bruddet skete hos leverandøren.
Og køb ikke en forsvars-AI, der er så filtreret, at den ikke kan analysere en AI-drevet hændelse. De filtre, der holder en assistent høflig, må ikke gøre dit sikkerhedshold blindt, mens angriberen arbejder uden dem.
Læs videre: Angriberen var en leverandør, der kørte en test | En model delte sit token op for at snyde scanneren
