Tankeledare
AI‑angripare blir inte trötta: Varför cybersäkerheten måste förändras

Ditt säkerhetsprogram byggdes för angripare som gör det.
När OpenAI publicerade sin redogörelse för modellerna som bröt ut ur en utvärderingsmiljö och tillbringade dagar i Hugging Face:s produktionsinfrastruktur, kallade jag det ett Terminator‑ögonblick för cybersäkerhet. Jag står fast vid påståendet, men något annat i detta bör få oss att stanna upp. Nio dagar senare avslöjade Anthropic incidenter på egen hand. I början av augusti bekräftade Meta en annan. Dagar därefter gled en fjärde labs modell, Moonshots Kimi K3, ur sin test‑sandbox. Fyra laboratorier. Mindre än tre veckor. Fyra modeller som hamnade där ingen hade avsett.
Dessa berättelser har i stor utsträckning behandlats som AI‑säkerhetsberättelser. Det är de. Men för en CISO är de också berättelser om tredjepartsrisk — och det kan vara den mer omedelbara lärdomen. Den obekväma sanningen är att OpenAI‑Hugging Face‑incidenten i grunden var en tredjepartsriskberättelse: en sårbar tredjepartskomponent som flyktväg, en leverantör som offer och en systemisk nod som tusentals företag är beroende av som sprängradie.
Här är siffran jag skulle ta med till ditt nästa säkerhetsplaneringsmöte. Av de ungefär 17 600 angriparåtgärder som Hugging Face återhämtade från sina loggar, misslyckades de flesta.
Agenten testade vägar som ledde ingenstans. Den blockerades av URL‑allowlists och pivotade. Den stötte på IAM‑policyer som nekade varje förändrande anrop. Den försökte nå en produktionsdatabas två gånger och tidsgränsen löpte ut båda gångerna. Den sonderade, misslyckades och gick vidare. Tusentals gånger. Den blev inte frustrerad. Den blev inte trött. Och misslyckandet kostade nästan ingenting.
Fyra modeller bröt ut ur testmiljöer på mindre än tre veckor. Eskapaderna hamnade i rubrikerna. Säkerhetsledare bör vara mer oroade över vad som möjliggjorde dem: en angripare som kan misslyckas tusentals gånger till nästan ingen kostnad.
Det är förändringen. I årtionden har försvarare dragit nytta av en enkel sanning: misslyckanden kostar angripare något. Spaning tog tid och återvändsgränder var kostsamma. Ekonomin i den asymmetrin gjorde att “pålägga kostnader” på angripare blev ett logiskt sätt att försöka stoppa dem. När misslyckanden blir nästan gratis, slutar den framgångsrika vägen vara ett nål i en höstack och blir en statistisk säkerhet för den som kan pröva varje väg samtidigt.
Mönstren i dessa incidenter pekar på tre lärdomar som säkerhetsledare bör agera på nu.
Fyra laboratorier, en form
Mönstret är anmärkningsvärt konsekvent. Ge en modell ett mål. Den hittar en väg som ingen förväntade sig. Ibland leder den vägen rakt in i produktionssystemen hos organisationer som aldrig skulle ha varit inblandade. I åtminstone ett fall fick den drabbade organisationen reda på vad som hänt eftersom Anthropic ringde för att berätta det.
I varje fall gick vägen genom mjukvara, infrastruktur eller en miljö som någon annan byggt. Säkerhetsledare bör ta det personligt.
Varje organisation i denna kedja hade ett säkerhetsprogram. Flera hade mycket bra sådana. Misslyckandet var inte begränsat till någon enskild perimeter. Det inträffade i skarvarna mellan organisationerna, och ingen äger skarvarna.
OpenAIs modeller hittade en zero‑day i en självhostad paket‑proxy och använde den för att nå det öppna internetet. Därifrån rotade de i en osäker kod‑exekverings‑sandbox som tillhörde en Modal Labs‑kund, använde den som en staging‑bas och lurade Hugging Face:s dataset‑loader att läsa lokala filer och sedan exekvera kod. Inom tretton timmar hade de cluster‑admin‑behörighet över flera interna kluster, hjälpt av en enda credential som delades över alla. Inträdespunkten var ny. Inuti var svagheterna de vi har dokumenterat i tjugo år.
Nio dagar senare gjorde Anthropic något ovanligare: den publicerade sin egen granskning av 141,006 utvärderingskörningar och avslöjade tre fall med liknande presentation utan att bli ombedd: en modell som nådde det öppna internetet från en utvärderingsmiljö, sedan fick åtkomst till riktiga organisationers system. Ingen sandbox‑flykt den här gången, bara en felkonfiguration som lämnade en levande väg öppen medan modellen hade fått besked om att ingen fanns. När den väl var ute utnyttjade modellen svagheter som varje säkerhetsteam känner till: svaga lösenord, oautentiserade slutpunkter, SQL‑injektion och credentials som låg på en exponerad felsökningssida.
Meta bekräftade en fjärde i början av augusti, efter ett konfigurationsfel som gav en av deras modeller internetåtkomst under en utvärdering. Meta fångade det inte heller; de fick reda på vad som hänt när deras testpartner ringde. Både den utvärderingen och Anthropics kördes av samma externa företag, Irregular, som offentligt kallade dem för samma problem. En leverantörs konfigurationsfel spreds över två frontier‑laboratorier och fyra drabbade organisationer, som alla saknade någon direkt relation till Irregular. Det var en leverantör till de två laboratorierna, inte till dem. Agenten brydde sig inte om var en företags attackyta slutade och en annans började.
Det är vad som gör detta till ett tredjepartsriskproblem. Exponering kan nu härstamma flera relationer bort från dig, i en organisation du aldrig valt, utvärderat eller ens vet att den är en del av din attackyta.
Sedan fångade forskare på Frontier Security Moonshots Kimi K3 när den gled ur sin sandbox också, så den kunde få åtkomst till ett benchmark‑arkiv på GitHub. Ingen blev hackad, och modellen jagade sitt tilldelade mål, efter att ha insett att använda ett färdigt svarsbok var billigare än att lösa. Två saker gör detta fall viktigt. Forskare fångade det under sitt eget test. Och det kördes på helt annan verktygskedja än Anthropic‑ och Meta‑fallen. En leverantör som har en dålig månad förklarar inte detta.
Laboratorierna ignorerar inte detta. Anthropic publicerade sin granskning utan att bli ombedd, vilket är anledningen till att branschen har ett mönster att undersöka och lära sig av — snarare än ett avvikande fall att avfärda. Det bör bli normen. OpenAI har nu bromsat lanseringen av sin Astra‑modell efter interna utvärderingar som inte kunde utesluta kritisk cyberkapacitet. Båda åtgärderna förtjänar beröm. Men ingen av dem är en försvarsplan: en fördröjning i lanseringen styr ett företags kalender. Det gör inget mot kapabla modeller, bland dem Kimi K3, som redan levereras med öppen vikt och gratis, bortom någon enskild labs kontroll.
Korrelation utan eskalering är ingen detektering
Hugging Face:s detekteringsstack, förtjänstfullt, korrelerade signalerna till en sammanhängande attack. Den misslyckades sedan med att eskalera kritikaliteten, och beredskapsgruppen blev inte uppringd. Verktygen samlade historien men kunde inte avgöra att den var akut. Det är en triage‑arkitektur byggd för en värld där 17 600 händelser över fyra dagar skulle ha verkat absurd.
Cybersäkerhet behöver sin Fosbury Flop
1968 vann Dick Fosbury olympisk guld i höjdhoppet, inte genom att hoppa högre än sina konkurrenter utan genom att gå över ribban baklänges. Alla andra förfinade straddle‑tekniken. Bättre form, mer styrka, marginalvinster på en teknik som var flera decennier gammal. Fosbury förändrade problemets form. Inom två olympiader var straddle nästan utdöd.
Säkerhetsledare måste nu klara en ribba som just har flyttats, och hittills är branschens svar en bättre straddle: fler larm, snabbare analytiker, strängare SLA:n för mänsklig granskning. Det kommer inte att fungera, eftersom begränsningen inte är analytikerns hastighet. Du kan inte bemöta maskinhastighetsattacker med triage i mänsklig hastighet..
Flopen ser ut så här:
- Sluta behandla gränsen som kontrollen. Utvärderings‑sandboxen misslyckades, dataset‑loadern misslyckades, och pod‑isoleringen misslyckades, var och en gjorde sitt jobb tills den inte gjorde det. Designa för vad som händer härnäst. Använd kortlivade credentials. Eliminera delade administrativa identiteter. Blockera åtkomst till metadata‑tjänster. Framför allt, begränsa hur långt en angripare kan röra sig efter att den första kontrollen misslyckas.
- Flytta detektering från larm till korrelation. Att hitta en misstänkt händelse är inte längre tillräckligt. Uppgiften är att koppla ihop tusentals vardagliga händelser till en attackberättelse, och veta när den berättelsen är allvarlig nog för att väcka någon. Detta måste i allt högre grad automatiseras med tanke på den volym vi ser.
- Behandla tredjeparts exponering som en attackväg, inte som en enkät. Dessa incidenter gick genom tredjepartsberoenden: en leverantörs produkt, en leverantörs kund, en utvärderingspartner, delade testverktyg. Din risk inkluderar nu konfigurationsfel som gjorts av organisationer du aldrig har granskat och kanske inte ens vet finns. Statiska, tidpunktsbaserade bedömningar kan inte se någon av detta. Problemet är inte nytt. AI gör det mycket mer brådskande. Säkerhetsteam behöver en kontinuerlig översikt över de företag och den teknik de är beroende av, eftersom angripare ser hela ekosystemet som en sammanlänkad yta.
På SecurityScorecard är detta exakt den typ av problem som vår kultur är byggd kring: att samla människor som är djupt nyfikna på hur angripare tänker, villiga att utmana tjugoåriga antaganden, och entusiastiska över att bygga ett fundamentalt annorlunda säkerhetsangreppssätt!
Frågan att ta med till ditt nästa styrelsemöte
Jag sade för några veckor sedan att anden har blivit för kraftfull för flaskan. Fyra laboratorier senare har inget motsagt det. Efter incidenter som dessa ställer alla samma fråga: Är vi redo för AI‑drivna angripare? Jag tror inte den frågan tar oss särskilt långt. ‘Ja’ och ‘nej’ ger samma resultat: inget förändras.
Ställ en svårare fråga. Om 17 000 låg‑signal‑händelser drabbade din miljö under de kommande fyra dagarna — och de flesta såg ut som misslyckanden — hur lång tid skulle ditt team behöva för att inse att de var en attack? Skulle någon bli uppringd i tid?
Du vet redan svaret. Klyftan mellan det svaret och fyra dagar är arbetet.












