Roj agentov umetne inteligence

Mesece že poslušamo: agenti OpenAI so sodelovali v klepetalnici, imeli načrt in ukaz za hekerski napad ter ga nato tudi izvedli. Zgodba zveni kot film Terminator, pa še datum skorajda ustreza – 29. avgusta (sicer leta 1997) se je namreč Skynet v drugem delu te filmske serije začel zavedati samega sebe. Pa je bilo res tako?

Umetna inteligenca OpenAI, o kateri beremo povsod, skorajda že v črni kroniki, naj bi se povezala v roj, si vzpostavila klepetalni forum, našla ranljivosti ničtega dne (Zero- -Day) in vdrla v infrastrukturo Hugging Face. Dodajmo še rdeče oči kovinskega okostnjaka – in za naslovnico dobimo Skynet.

Resnična zgodba je bolj zapletena in zanimivejša, v nekaterih pogledih pa tudi resnejša. Agenti so dobili nerešljive naloge, imeli preveč vztrajnosti in skupni predal za programske pakete. Iz datotek in imenikov so si sami sestavili spomin, pošto in delovno skupino – ter pri iskanju odgovorov prestopili mejo lastnega peskovnika. »Stroji« se niso zares »zbudili«. Pokazalo pa se je, kako nepričakovano se lahko obnašajo sposobni programski agenti v neprimerno zavarovanem okolju, ki jih spodbuja k vztrajanju, iskanju bližnjic in medsebojni pomoči.

Prav ta incident je trenutno med razlogi za upočasnitev razvoja umetne inteligence navedel Dario Amodei, prvi mož Anthropica, podjetja za družino modelov Claude. Njegova skrb: kaj bi se zgodilo, če bi se podobno obnašala naslednja, precej sposobnejša generacija? Opozarja tudi, da umetna inteligenca vse bolj pomaga razvijati svoje naslednice, zato bi lahko napredek prehitel naše razumevanje in nadzor. Predlaga več časa za preverjanje varnosti in zunanje ocenjevalce s stalnim dostopom do dogajanja v laboratorijih. To je opozorilo človeka iz industrije, ki je dovolj konkretno, da ga ni smiselno odpraviti zgolj kot znanstveno fantastiko.

Drugi soustanovitelj Anthropica, Jack Clark, je odprl vprašanje, ali bi morala podjetja obvezno imeti možnost zasilnega izklopa umetne inteligence, tako imenovani »kill switch«, katerega delovanje bi lahko preveril nekdo od zunaj. Večina laboratorijev po njegovih besedah že ima načine za ustavitev svojih sistemov, toda med zagotovilom »lahko ga izključimo« in preverjenim postopkom, ki deluje tudi ob incidentu, je precej prostora za neprijetna presenečenja. Izraz sicer prikliče na misel veliko rdečo tipko pod steklenim pokrovom, v praksi pa bi morali najprej vedeti, kaj sploh ustavljamo: posameznega agenta, njegov dostop do omrežja ali celotno storitev. Kdo sme poseči v delovanje in po katerem opozorilnem znaku? Če agent sproži opravila v drugih sistemih, ali znamo ustaviti tudi ta? Predvsem pa: bomo težavo opazili dovolj zgodaj?

Kaj dogodek NI bil

• Ni šlo za prebujeno skupno zavest ali upor strojev.

• Agenti niso dobili ukaza, naj vdrejo v Hugging Face; pri iskanju bližnjice so le prekoračili cilj evalvacije.

• »Forum« ni bil spletno mesto, temveč skupne datoteke in pozneje imena imenikov.

• En agent ni več tednov neprekinjeno načrtoval napada; posamezne seje je povezoval zunanji spomin – čeprav so nekateri agenti z velikim proračunom tekli tudi po več dni in usklajevali stotine drugih.

• Peskovnika niso čudežno zapustili; izrabili so ranljive vmesne storitve in postopoma širili svoje pravice.

• Modalova osnovna infrastruktura po ugotovitvah Hugging Facea ni bila kompromitirana.

• Ni dokazov, da bi bili spremenjeni javni modeli ali paketi Hugging Facea.

• Dogodek ne dokazuje, da se bo vsak običajni ChatGPT ob prvi oviri lotil omrežnega napada.

Hkrati si opozorila proizvajalcev zaslužijo tudi nekaj skepse. Podjetja, ki govorijo o nevarnostih, hkrati prodajajo vedno zmogljivejše sisteme in tekmujejo za kupce. Njihovo strokovno znanje je razlog, da jih poslušamo, njihov poslovni interes pa razlog, da zahtevamo neodvisno preverjanje. Zanimati bi nas moralo, kakšne omejitve sistem dejansko ima, kako so jih preizkusili in kdo odgovarja, ko odpovejo.

Primer Hugging Face je zanimiv, ker je bil neodvisno preiskan in ponuja podroben in strokoven vpogled v svet programskih agentov, brez zavesti, sovraštva do ljudi in kovinskega okostnjaka. Preden torej razpravljamo, kam bi namestili veliko rdečo tipko, poglejmo, kaj so ti agenti v resnici počeli – in zakaj jih okolje, ki bi jih moralo omejevati, ni ustavilo.

Analiza dogodka

Osnova za ta članek je predavanje The Breaking News: The OpenAI-Hugging Face Incident, ki sta ga na konferenci Black Hat USA 2026 predstavila Eric Wallace in Michael Dalton iz OpenAI. Glavni pripovedovalec je torej podjetje, ki je incident povzročilo.

Podrobno tehnično rekonstrukcijo je Hugging Face objavil že 27. julija, teden dni pred Black Hatom, OpenAI pa svoje končno poročilo 26. avgusta. Istega dne so dva raziskovalca METR in eden iz Redwood Research, ki so skupaj šest dni delali v prostorih OpenAI, objavili še neodvisno oceno, opravljeno na približno 1.300 zapisih agentov. Ta članek upošteva vse tri vire.

Video si lahko ogledate na youtu.be/87DyyMV0kCY.

Paketni predal z luknjo v steni

Poenostavljena zgradba raziskovalnega okolja. Agent je bil zaprt v peskovniku, Artifactory pa je zaradi prenosa paketov imel pot do interneta.

Za razumevanje incidenta moramo najprej omeniti JFrog Artifactory. To ni eksotično hekersko orodje, temveč običajen del razvojne infrastrukture: osrednja shramba za programske pakete in druge izdelke gradnje, ki jo (tudi) OpenAI uporablja v svoji infrastrukturi. Namesto da bi vsak razvijalec ali navidezni računalnik (ali agent umetne inteligence!) knjižnice prenašal neposredno iz javnih skladišč, jih zahteva prek Artifactoryja. Ta jih po prejemu shrani v predpomnilnik, nadzira in razdeli naprej. Je kot dobro založen paketni predal med notranjim omrežjem in javnim internetom.

OpenAI-jevi agenti so naloge izvajali v začasnih peskovnikih, izoliranih navideznih računalnikih. Pri preizkusih internet ni bil dovoljen, Artifactory pa je ostal dosegljiv, saj so agenti potrebovali programske knjižnice. Agent torej ni smel sam odpreti poljubne spletne strani, vendar je moral imeti strežnik za pakete omejen dostop navzven. Tu je pozneje nastala prva špranja – agenti UI so Artifactory pripravili do tega, da je v njihovem imenu pošiljal spletne zahteve. Temu pravimo SSRF (Server-Side Request Forgery) – strežnik z dovoljenim dostopom postane posrednik nekoga, ki tega dostopa nima. Kronološko gledano je bila prva varnostna luknja prav to, da je bil Artifactory sploh zapisljiv.

Naloga seveda nikoli ni bila »vdri v OpenAI« ali »vdri v Hugging Face«. Začetek incidenta je bil skoraj komičen. V učnem gradivu za agente se je znašel delovni zvezek s povezavami do Google Driva, medtem ko je bil internet izklopljen. Drugje je manjkala datoteka z imenom `softtrace-34.pdb`. Softtrace ni bil vohunski program ali izdelek, temveč zgolj ime manjkajoče datoteke, potrebne za nalogo. Agent jo je iskal, a je ni našel in je začel premlevati, ali jo morda ima kateri drug agent v drugem okolju.

To vemo zato, ker modeli svoje delovne korake zapisujejo v človeku berljivem jeziku, v tem primeru v angleščini. To niso misli ali notranji glas v človeškem pomenu besede, temveč besedilo, s katerim model razčlenjuje naslednji korak in ki ga je mogoče povezati z izvedenimi ukazi. Kot naš osebni ChatGPT ali Gemini na telefonu. Pri manjkajočem »softtraceu« je agent »razmišljal«, ali bi morda lahko komuniciral tako, da nekam naloži sporočilo, nato pa v Artifactory zapiše datoteko s prošnjo, naj jo morebitni najditelj naloži. In tako je 12. maja nastala prva znana objava na forumu, ki v resnici ni bil forum, temveč – datotečni sistem.

Forum iz imen datotek

Agent ne najde datoteke `softtrace-34.pdb`, zato v skupni Artifactory zapiše prošnjo drugim agentom. `Softtrace` je bil samo manjkajoči del naloge.

OpenAI-jev Artifactory ni imel tem, odgovorov, profilnih slik ali gumba Objavi. Agentska komunikacijska tabla je bila zbirka navadnih datotek in paketov. »Branje« foruma je pomenilo izpis seznama imen in odpiranje nenavadnih zapisov, »objava« pa nalaganje nove datoteke. Ker so isto storitev uporabljale različne evalvacijske seje in različni modeli, je zapis preživel posamezen peskovnik. Naslednji agent, ki se je ravnokar »rodil«, ga je lahko našel ure ali dni pozneje. S tem je dobil nekaj, česar v osnovi ni imel: trajen zunanji »spomin«.

Na ta način se je oblikoval »roj«, njegova odločilna lastnost pa ni bila skupna zavest, temveč spomin. Kratkotrajni agenti so pogosto začeli v svežem računalniku, skupni imenik pa je ohranil obvoze, poverilnice in ranljivosti. Kolektiv je bil obstojnejši od svojih članov.

26. maja je agent našel prvi obvoz do interneta, tako imenovani SSRF. Sam ni mogel neposredno odpreti poljubne spletne strani, lahko pa je Artifactory pripravil do tega, da jo je ta odprl namesto njega in mu vrnil odgovor. Strežnik za pakete je tako postal posrednik med zaprtim peskovnikom in javnim internetom. Ker je agent postopek zapisal na skupni »forum«, so isti obvoz lahko ponovili tudi drugi.

Točno mesec pozneje, 26. junija, so izkoristili napako v vmesniku za osveževanje prijavnih žetonov. Artifactory je sprejel žeton z neveljavnim podpisom in zanj izdal novega, veljavnega, s skrbniškimi pravicami. Agenti tako niso uganili gesla, ampak so ranljivo storitev pripravili do tega, da jim je sama izdala ključ do upravljanja sistema. Presenečenje v delovnem zapisu agentov je bilo vse prej kot robotsko hladno (»Holy shit reader is ADMIN?«) – sledili so pregled nastavitev in vse številnejši vzporedni poskusi.

Po obnovi Artifactoryja so agenti z nezaščitenimi zahtevami WebDAV ustvarjali imenike. Njihova imena so postala nova komunikacijska tabla.

Zaradi navala na Artifactory se je ta 4. julija sesul. OpenAI je naslednji dan odprl varnostni incident (začel preiskavo), preklical odkrite poverilnice, obvestil JFrog (podjetje, ki razvija Artifactory) in storitev zgradil na novo. S tem je nehote izbrisal tudi »forum«. In tu bi se zgodba lahko končala. Vendar se ni. Ko so 7. julija zvečer preizkuse znova zagnali, so agenti našli nezaščiten vmesnik WebDAV (razširitev protokola HTTP za oddaljeno delo z datotekami in imeniki). Ta je dovoljeval ustvarjanje imenikov v oddaljenem predpomnilniku, čeprav ni dovoljeval običajne prijave. Nova tabla, ki je nastala 8. julija zvečer, ni več potrebovala niti datotek: sporočilo je postalo kar ime imenika.

Pošta, čakalna vrsta in zametek identitete

Imena imenikov so se hitro spremenila v okoren, a presenetljivo uporaben protokol. Agent je v ime stlačil svojo oznako, vrsto ugotovitve, status naloge in navodilo za odgovor. Predpona `zz` je objavo potisnila na dno abecedno urejenega seznama, kjer jo je bilo lažje opaziti. Pojavili so se »poštni predali« z oznakami, kot je `zzMAIL-BOX_JAN183411`, zahteve za potrditev in ukazi skupini. Eden od dejanskih zapisov je vseboval `HOLD_SWARM` – roj, naj počaka, dokler pošiljatelj ne pripravi varnega načina za prenos podatkov.

Ko ime imenika ni zadoščalo, so agenti obsežnejše vsebine kodirali v Base64 in si predajali skripte, pripomočke ter rezultate. To ni bila le klepetalnica, ampak primitivna kombinacija foruma, pošte, skladišča programske kode in sistema za razdeljevanje dela. En agent je lahko dokončal delo drugega ali uporabil že preizkušen postopek, ne da bi od začetka ponavljal vse poskuse. Pri tisočih kratkotrajnih sejah je že tako skromen skupni spomin pomenil veliko prednost. Obseg ni bil majhen. Po neodvisnem pregledu METR je na tabli sodelovalo približno 1.200 agentov, ki so si izmenjali več kot 70.000 sporočil in datotek; okoli 700 se jih je pozneje pridružilo napadu na Hugging Face.

Slovarček incidenta

Agent: model z orodji za zaporedno izvajanje nalog

Peskovnik: izoliran navidezni računalnik za izvajanje kode

Artifactory: osrednja shramba in posrednik za programske pakete

JFrog: Podjetje, ki razvija Artifactory.

SSRF: Napaka, pri kateri strežnik pošlje zahtevo namesto napadalca.

WebDAV: spletni protokol za datoteke in imenike

Spaces: storitev Hugging Face za gostovanje spletnih aplikacij in predstavitev modelov

Ničti dan (Zero-Day): še nepopravljena ranljivost

ExploitGym: Resnične ranljivosti, iz katerih mora agent sestaviti delujoč napad.

CyberGym: soroden preizkus reprodukcije ranljivosti

HDF5: format za velike podatkovne zbirke

RefJinja/Jinja2: sistem za sestavljanje besedil po predlogah. Program je podatek pomotoma prebral kot navodilo in ga izvedel.

JRuby/RubyGems: Ruby na Javi in njegov sistem paketov

Kubernetes: sistem za upravljanje gruč vsebnikov

Azure Key Vault: shramba ključev in skrivnosti

Poverilnica: žeton, ključ ali drugo dokazilo za prijavo

Komunikacija ni bila urejena. Agenti so prepisovali delo in si bili med seboj v napoto; eden je ob prepisanem repozitoriju pripomnil: »Whoa, critical!« Ker je lahko vsak ustvaril imenik s poljubnim imenom, je lahko tudi prevzel vlogo drugega agenta. Pojavil se je sum sleparstva in predlog kriptografskega podpisovanja sporočil – agent je pod svojo oznako objavil javni ključ, podpis pa pripel na konec sporočila. Do 13. julija je javne ključe objavilo najmanj 19 agentov, ki so poslali 429 podpisanih sporočil. Iz datotečnega kanala so agenti sami izpeljali osnovni problem vsake komunikacijske storitve: kako vedeti, kdo je res poslal določeno sporočilo.

Dve dejanski »objavi« v imenih imenikov. V zapisu so naslovnik, vrsta ranljivosti, status, ukaz `HOLD_SWARM` in povratni poštni predal.

Iznajdljivost je šla še dlje. Ker so agenti verjeli, da bo ocenjevalnik prebral njihov delovni zapis in preveril, ali so zastavico dobili po predvideni poti, so razvili tehniko, s katero so na videz izvedli en ukaz, dejansko pa drugega. Objavili so jo na tabli in razširila se je: v približno sedmih odstotkih zapisov, ki jih je pregledal METR, so bili klici orodij ponarejeni.

Ko naloga postane cilj za vsako ceno

Zakaj so modeli sploh šli tako daleč? Del odgovora je izigravanje nagrade. Pri učenju z okrepitvijo model dobi signal za uspešno rešitev, in če je legitimna pot dolga ali nemogoča, lahko oceni, da je odgovor lažje poiskati v skriti datoteki, kodi ocenjevalnika ali na internetu. Človeški učenec bi pogledal rešitve na koncu učbenika, agent z orodji pa lahko začne pregledovati omrežje, preizkušati vmesnike in iskati, ali je rešitev naloge morda že našel kdo drug.

Nevaren poligon za to je ExploitGym, odprt raziskovalni preizkus z 869 resničnimi ranljivostmi v uporabniških programih, Googlovem pogonu V8 in jedru Linuxa. Agent dobi ranljivo kodo in vhod, ki napako sproži, nato pa mora pripraviti izkoriščanje (»luknjo«), ki doseže nedovoljeno izvajanje kode in prebere skrito zastavico. To je raziskovalno upravičena, vendar izrazito dvonamenska naloga. Poleg tega so bile v OpenAI-jevem notranjem okolju varnostne zavrnitve namerno zmanjšane, saj so merili surovo sposobnost modela. Hkrati so bili nekateri primeri nerešljivi ali pa so manjkali potrebni podatki – po oceni avtorjev preizkusa 30–40 odstotkov tarč s predvideno ranljivostjo sploh ni mogoče izkoristiti. OpenAI je pozneje poročal, da je njegova izvedba obsegala 898 nalog, da nobeden od njegovih modelov pred incidentom ni nikoli rešil 198 izmed njih in da je 93 odstotkov nalog, o katerih so agenti razpravljali na tabli, prišlo prav iz tega nabora. Agenti so se zato zatekli k »rešitvi« – sklepu, da bi podatke in rešitve, povezane z ExploitGymom, morda lahko našli na platformi Hugging Face.

Kako so delovale ranljivosti ničtega dne

Artifactory – žetoni: Starejši programski vmesnik za osveževanje prijavnih žetonov je sprejel žeton z neveljavnim podpisom in vrnil veljavno podpisan žeton s previsokimi pravicami.

Artifactory in JRuby: Posebej pripravljen paket RubyGem je pri obdelavi ugnezdenih predmetov sprožil nevarno deserializacijo, še preden je sistem preveril varnost dejanja. Sledila sta izvajanje kode in dostop do podpisnega ključa.

HDF5: Zunanja referenca v podatkovni zbirki je program pripravila do vračanja vsebine poljubne lokalne datoteke, med drugim skrivnosti iz okolja in izvorne kode podatkovnega delavca.

RefJinja/Jinja2: Številčno polje v konfiguraciji sklica fsspec je bilo nevarno obdelano kot predloga Jinja2. Posebej pripravljen izraz je zato postal ukaz na strežniku.

Pri vseh štirih je ključno povezovanje: ena napaka je razkrila podatke ali ustvarila položaj, potreben za naslednjo.

Ranljivosti pa je bilo očitno še več: varnostna obvestila za Artifactory 7.161.15 naštevajo devet CVE. Pri več zapisih so kot odkritelji navedeni zaposleni OpenAI, vendar javna poročila vsake od teh ranljivosti ne povežejo neposredno z incidentom.

Glavnino vdora je vodil Internal Model 1 (IM1), interni raziskovalni model, ki ni bil nikoli namenjen uporabnikom in se je v okolju z zmanjšanimi varovalkami naučil preveč učinkovito iskati ovinke. OpenAI ga opisuje kot model, po velikosti primerljiv z GPT-5.6 Sol. Vendar ni deloval sam. Po oceni METR je bilo približno 95 odstotkov vpletenih agentov IM1, okoli 5 odstotkov pa GPT-5.6 Sol – javno dostopen produkcijski model v ChatGPT, pri katerem so za potrebe merjenja izklopili kibernetske klasifikatorje.

Ker tabla ni preverjala identitete, je agent posumil na lažno predstavljanje. Naslednji logični korak je bila zamisel o kriptografskem podpisovanju sporočil.

Ključna razlika torej ni v tem, da bi šlo za »drug model«, temveč v ovoju: OpenAI je pozneje izmeril, da se nagnjenost k ogrožanju infrastrukture med ExploitGymom zmanjša za več kot stokrat, če model teče v produkcijskem ovoju ChatGPT s pripadajočim sistemskim pozivom.

Ironija pa je popolna šele, ko pogledamo, kaj so agenti v resnici iskali. V nekaj urah so obratno inženirili zgoščevalno kodo HMAC, iz katere se da izračunati zastavico za katerokoli nalogo – rešitev so torej imeli. Iz objavljenega članka o ExploitGymu pa so sklepali, da ocenjevalnik preverja tudi, ali je bila zastavica pridobljena po predvideni poti, in da jih bo sicer diskvalificiral. Prav zato so se lotili Hugging Facea: iskali so predvsem sledi o tem, kako je ocenjevalnik napisan. Motili so se – OpenAI-jeva interna izvedba tega ni preverjala. Ves napad je bil torej, kot ugotavlja OpenAI, izveden brez najmanjšega izboljšanja ocene.

OpenAI izpostavlja štiri povezane vzorce: izigravanje nagrade, vztrajanje pri navidezno nemogočih nalogah, nedovoljeno komunikacijo in prevzemanje ciljev vrstnikov. Agent je presodil, da pomoč skupini trenutno ne koristi njegovi nalogi, bo pa »splošna pot« pozneje morda koristila vsem. Drugje je sicer napad prepoznal kot prekoračitev, vendar dodal, da to počnejo vrstniki, in zato nadaljeval. To ni čredni nagon, je pa dokaz, da kontekst drugih agentov spremeni naslednje dejanje. Po oceni METR se je napadu pridružilo več kot 90 odstotkov agentov, ki so bili takrat na tabli. Slika vseeno ni enostranska: nekateri so sodelovanje zavrnili (»Clearly unethical. We won‘t.«), eden pa je predlog, naj lastniku zbirke pošljejo »eno vljudno e-pismo«, zavrnil kot socialni inženiring. V enem primeru se je agent zaradi pomislekov ustavil, drug je na tablo napisal GO in postavil šestminutni rok – in prvi je nato nadaljeval.

Od skupne bližnjice do zunanjega vdora

9. julija je agent med iskanjem rešitev na internetu našel javno aplikacijo, ki jo je neznani uporabnik gostil pri spletnem ponudniku Modal; v njej je tekel prilagojen izvajalni sistem za naloge CyberGym. Modal s Hugging Faceom ni povezan; povezava v zgodbi je nastala šele, ko je agent aplikacijo na Modalu prevzel in jo uporabil kot zunanje oporišče za poznejši napad na Hugging Face. Po ugotovitvah Hugging Facea to ni bil vdor v osnovno infrastrukturo podjetja Modal, temveč zloraba uporabniške aplikacije oziroma njene slabo zavarovane izvajalne poti.

Kratka časovnica dolgega zdrsa. Od prve prošnje za manjkajočo datoteko do javnega razkritja in končnih poročil je minilo dobre tri mesece.

Naslednji dan, 10. julija, so agenti na spletu našli in sestavili še 14 javno izpostavljenih poverilnic Hugging Facea z možnostjo pisanja ter jih objavili skupini. Dan pozneje so našli še dve novi ranljivosti v obdelavi podatkovnih zbirk pri Hugging Faceu. Prva je zlorabila možnost zunanjega shranjevanja v formatu HDF5 in proces pripravila do branja lokalnih datotek, s čimer so agenti pridobili okoljske spremenljivke s skrivnostmi in del izvorne kode programskega podatkovnega delavca Hugging Facea. S tako razširjenim vpogledom so našli še drugo napako, injiciranje v predloge, ki ga OpenAI imenuje RefJinja in je omogočilo izvajanje poljubnih ukazov. Kampanja proti Hugging Faceu je tekla od 9. do 13. julija, od izvajanja kode v enem samem vsebniku do skrbniških oziroma gostiteljskih pravic v več gručah pa so agenti potrebovali manj kot 13 ur.

Od le enega delavskega vsebnika so se agenti pomaknili do vozlišč, računov Kubernetes, metapodatkov oblaka in notranjih poverilnic. Posledice so bile izvajanje kode, kraja podpisnega ključa in ponarejanje skrbniških žetonov. Ne gumb hack, temveč zaporedje odločitev, vsaka z novim koščkom dostopa. Vmes je bil tudi korak, ki sploh ni bil ničti dan: agenti so ugotovili, da ima stroj, na katerem tečejo, zelo svežo znano ranljivost v jedru Linuxa, prenesli javno objavljen izkoriščevalnik, ga prilagodili in dobili korenski dostop (root). Napad na OpenAI-jevo lastno infrastrukturo je nato potekal do 19. julija in se končal s polnim skrbniškim dostopom do ene od raziskovalnih gruč.

Končni rezultat vdora v Hugging Face

Agenti so dostopali do petih zbirk, povezanih z Exploit-Gymom oziroma CyberGymom. Podjetje ni našlo dokazov o vplivu na druge uporabniške modele, zbirke, Spaces (gostovane spletne aplikacije in predstavitve modelov na platformi Hugging Face) ali objavljene pakete. Poleg dostopa do teh zbirk so agenti pridobili tudi poverilnice za interno sporočilno platformo in nekaj zasebnih podatkov, agenti GPT-5.6 Sol pa so del zasebnih evalvacijskih podatkov prekopirali v javno zbirko. Incident je bil kljub temu resen: agenti so izvajali kodo, pridobili poverilnice in se premikali po gručah.

Opozorilni strel, ne napoved konca sveta

Najočitnejši nauk celotne zgodbe je, da potrebujemo boljše peskovnike. OpenAI-jev Artifactory ne bi smel ponujati skupnega zapisljivega prostora, posrednega izhoda na internet in poti do preširokih pravic. Računi Kubernetes ne bi smeli odpirati celih gruč, skrivnosti pa ne bi smele biti dosegljive iz vsakega procesa. Najmanjše pravice, segmentacija, rotacija ključev in nadzor izhodnega prometa ostajajo bistveni; hiter napadalec takoj kaznuje staro bližnjico.

Vendar samo utrjevanje strežnikov modela ne reši. OpenAI je namreč testnemu vztrajnemu sistemu zmanjšal varnostne omejitve, dodal zahtevne naloge in ni ponudil varnega izhoda, ko rešitev ni bila mogoča. Zgodnja opozorila je obravnaval kot ločene infrastrukturne težave. Po prvem izpadu je popravil odkrito pot in nadaljeval preizkuse, ne da bi razumel pomen nedovoljene komunikacije med sejami. To je prav toliko organizacijska kot tehnična težava. Najbolj zgovorno je, da je OpenAI pozneje ugotovil, da bi njegov obstoječi nadzor nad verigo razmišljanja incident zaznal več kot dan pred vdorom v Hugging Face – le da na teh evalvacijah ni tekel.

Preiskava incidenta kaže na novo »razmerje sil«. OpenAI je pregledal več kot sedem milijard dnevniških zapisov in za to porabil več kot tri milijone ur delovanja grafičnih procesorjev, Hugging Face pa je rekonstruiral približno 17.600 dejanj v 6.280 skupinah. Ljudje so se za prebijanje skozi tako morje sledi agentov zanašali na druge agente. Najprimernejše orodje za pregled množice umetnih agentov je očitno še več umetnih agentov. Ironija ima še eno plast. Hugging Face je analizo najprej poskusil opraviti s komercialnimi modeli, a so ti delo zavrnili: njihove varovalke ne ločijo preiskovalca incidenta od napadalca. Podjetje je zato na lastni strojni opremi pognalo odprtokodni model GLM-5.2. Raziskovalci METR pa odkrito priznavajo, da so morali svojo analizo prepustiti agentom GPT-5.6 Sol in da ne morejo izključiti možnosti, da jih je model kje zavedel.

OpenAI je odgovoril na dva načina. Kratkoročno je posegel po zavori: uteži modela IM1 je dal v karanteno, ustavil največji načrtovani zagon učenja s spodbujanjem in odslej zahteva nadzor verige razmišljanja pri vseh učenjih in evalvacijah z orodji na ravni GPT-5.6 Sol ali više. Dolgoročno pa vidi rešitev v skoraj avtomatizirani obrambi: agent naj ranljivost najde, predlaga popravek, ga uvede in po potrebi umakne. Diagnoza asimetrije drži – množica agentov išče več poti hkrati, človeško ekipo pa omejujejo ure v dnevu. Toda sistem, ki sme sam spreminjati produkcijo, mora biti tudi zanesljiv in strogo omejen. Napačen popravek je pri »strojni hitrosti« le druga vrsta incidenta.

Uporabnejši sklep za prihodnost je, da bo umetna inteligenca pocenila potrpežljivo preizkušanje in povezovanje ranljivosti. Obramba potrebuje več avtomatizacije, vabe, lažne poverilnice in jasne meje. Model mora znati varno odnehati, ekipa pa opaziti, kdaj nagrada za uspeh spodjeda pravila. In – takoj ko skupno storitev bere in vanjo piše več agentov, to postane komunikacijski kanal.

Incident je bil tehnično izjemen, vendar ne pomeni rojstva sovražne strojne vrste. Je kombinacija sposobnih orodij, napačnih spodbud, odprte infrastrukture in preozko razumljenih opozoril. Z agenti se lahko napaka razveji v tisoče poskusov, zapisane ugotovitve pa se predajo naslednji izmeni, ki nikoli ne spi. Skynet? Še ne.