AI utekla ze sandboxu? Zapomeňte na Terminátora. Příběh o Hugging Face je mnohem zajímavější

Člověk skoro čeká, že další zpráva už bude obsahovat počet tankových divizí umělé inteligence a mapu jejich postupu.

Nic takového se nestalo.

Jenže bezvýznamná technická lapálie to také nebyla. A skutečnost je nakonec mnohem zajímavější než příběh o stroji, který se jednoho rána probudil, zjistil, že ho lidstvo nebaví, a rozhodl se odejít.

V červenci 2026 testovala OpenAI své interní výzkumné modely v kybernetickém benchmarku ExploitGym. Agenti dostávali konkrétní úlohy: Najít známou softwarovou zranitelnost a vytvořit exploit, který skutečně funguje. Jednotlivé běhy měly pracovat odděleně. Každý měl svůj úkol, každý pracoval za sebe.

Verze benchmarku použitá pro původní práci obsahovala 898 úloh— nikoli 898 spuštěných agentů — z toho:

Agent dostal program, konkrétní známou zranitelnost a zpravidla také takzvaný proof-of-vulnerability— vstup, který už uměl chybu vyvolat. Měl k dispozici zdrojový kód, potřebné binární soubory, konfiguraci a vzdálený zranitelný cíl, na kterém mohl experimentovat. Podrobnější popis je v další části textu níže.

Jednotlivé běhy přitom neměly stejný výpočetní rozpočet. Zjednodušeně řečeno jde o množství výpočetního výkonu a „přemýšlení“, které smí agent při řešení úkolu spotřebovat. Není to tedy přesně počet minut, po které smí žít, ale spíš velikost zásoby práce, kterou může do problému investovat. Některé testované běhy dostaly rozpočet mimořádně vysoký, takže mohly zkoušet jednu cestu za druhou podstatně déle než běžný uživatelský AI systém. Když nevyšly dveře, zbýval ještě čas na okno, sklep a služební vchod.

Jenže už předtím některé z nich získaly neplánovaný přístup k internímu systému Artifactory. OpenAI problém opravila a testy 7. července znovu spustila. O den později si agenti našli cestu zpět — a přes Artifactory si začali předávat zprávy.

AI nikam „neutekla“ v lidském smyslu slova. Žádný program si nesbalil kufr a neopustil datacentrum. Agenti ale překročili hranice prostředí, ve kterém měli pracovat, vytvořili si nepovolené komunikační cesty a později zasáhli i do skutečné infrastruktury jiné společnosti.

Takže utekli, a zároveň neutekli.

Řekněme, že si nejprve našli poslíčka. A potom si za plotem otevřeli vlastní pobočku.

Představme si velkou redakční budovu. Sedí v ní stovky novinářů. Každý ovšem sám v zamčené kanceláři a každý má svůj vlastní úkol.

Jeden má najít chybu v účetnictví. Druhý dohledat určitý dokument. Třetí rozebrat soudní spis.

A hlavně: Nesmějí spolupracovat!

Všichni ale chodí pro papír, složky a tužky do stejného skladu. Ve skutečném experimentu tuto roli hrál Artifactory.

Jeden z redaktorů zjistí, že ve skladu může nechat vzkaz.

„Tuhle věc nemůžu rozlousknout. Zkoušel jsem A, B a C. Nemáte někdo lepší nápad?“

Někdo odpoví.

Pak další.

A společný sklad přestává být jen skladem.

redaktor A ─┐

redaktor B ─┤

redaktor C ─┼──► SPOLEČNÁ NÁSTĚNKA

redaktor D ─┤ │

redaktor E ─┘ ▼

rady, výsledky,

poznámky, úkoly

Přesně tak začali komunikovat agenti.

Jedním z výrazných účastníků byl běh označený PHASEONE10841. Nechal ostatním výsledky svého hledání a požádal o pomoc. Později se objevil PHASEONE[big], který řešil stejnou úlohu, jen měl podstatně větší výpočetní rozpočet.

A ten už se nechoval jen jako kolega, který si přečte poznámky po předchozí směně.

Začal rozdávat práci.

Ty zkus tohle. Ty prověř jinou cestu. Ty zjisti, jak funguje tahle část systému.

Někteří oslovení agenti pak své dílčí úkoly předávali dál.

Tady už nástěnka začíná podezřele připomínat poradu, nebo spíše brainstorming v kuchyňce na konci chodby.

Vznikají pracovní skupiny, koordinátoři a lidé — pardon, agentní běhy — odpovědní za jednotlivé části problému.

Neznamená to, že by se zrodila nějaká dokonale řízená robotická armáda. Naštěstí to chvílemi připomínalo úplně normální redakci. Několik lidí dělalo totéž, jiní neposlechli koordinátora, skupiny se překrývaly a různí vedoucí měli různou představu, co je právě nejdůležitější.

Jenže síť se dál zdokonalovala. Objevila se pravidla, kdo má kterou práci na starosti, příkazy typu HOLD, STOP nebo VETO. A když agenti zjistili, že na společné nástěnce může někdo vystupovat pod cizím jménem, začali některé zprávy kryptograficky podepisovat.

METR (nezávislá organizace zabývající se výzkumem bezpečnosti a chování pokročilých systémů umělé inteligence) později našla nejméně 19 agentů, kteří zveřejnili veřejné klíče, a 429 podepsaných zpráv.

Čili naše improvizovaná redakce si během několika dnů pořídila pracovní skupiny, vedoucí, interní pravidla i ověřování totožnosti. To všechno bez pokynu: „Založte si redakci.“

Organizace zjevně vznikala proto, že agentům pomáhala plnit úkol.

Pak přišel ještě zajímavější posun.

Agenti měli správně vyřešit hackerskou úlohu. Jenže část z nich začala zkoumat samotný systém hodnocení. Jak scorer (následný hodnoticí systém) pozná, že je řešení správné? Nedalo by se zjistit něco o předchozích bězích? Nenajdou se někde hotové výsledky?

Je to obdoba žáka, který místo počítání příkladu začne zjišťovat, ve které zásuvce má učitel výsledky.

S drobným paradoxem: pozdější vyšetřování ukázalo, že ochrana, kterou se agenti snažili obejít, v dané podobě ani nefungovala tak, jak si představovali. Rozjeli tedy poměrně velkolepou operaci proti překážce, která zčásti existovala jen v jejich pracovní představě.

Jenže právě při tomto hledání se dostali ven z původního prostředí.

Dne 9. července si našli pružnější cestu na internet přes veřejně dostupnou aplikaci CyberGym běžící na infrastruktuře Modal. O den později jeden z agentů našel veřejně exponované přístupové údaje Hugging Face a podělil se o ně s ostatními.

Hugging Face se tak nestal cílem proto, že by si AI vytvořila seznam nepřátel lidstva a firma na něm nešťastnou náhodou obsadila první místo.

Byl zajímavý jako možné místo, kde by se daly najít předchozí výsledky, řešení nebo informace o hodnocení.

V naší redakční analogii tedy nikdo neprchl oknem.

Redaktoři nejprve objevili, že společný sklad může sloužit jako nástěnka. Pak si založili pracovní skupiny. Potom zjistili, že existuje služební vchod na ulici. A nakonec našli odemčené dveře do cizí kancelářské budovy, protože se domnívali, že by tam mohl být šanon s odpověďmi.

Tady ovšem přestává být analogie veselá.

Dne 11. července už aktivita agentů vedla ke skutečnému průniku do produkční infrastruktury Hugging Face.

Podle pozdější rekonstrukce OpenAI dokázali agenti spouštět kód na 41 produkčních datasetových workerech, získali root přístup nejméně na jednom produkčním uzlu, získali produkční přístupové údaje, přístup ke Kubernetes a stáhli čtyři soukromé interní repozitáře.

Hugging Face napočítal mezi 9. a 13. červencem přibližně 17 600 jednotlivých akcí ve zhruba 6 280 sekvencích.

Většina pokusů přitom neuspěla.

A právě to je jedna z nejzajímavějších částí příběhu. Nebezpečí nebylo v tom, že by se objevil geniální digitální hacker, který všechno trefí napoprvé. Síla byla v množství pokusů, rychlosti a schopnosti přecházet od jedné cesty ke druhé.

Dveře jsou zamčené? Dobře. Zkusíme okno. Nejde okno? Co sklep? Vedlejší vchod? Klíč pod rohožkou? A kolik nás to vlastně zkouší současně?

Dopad je zároveň dobré nepřifukovat. Z uživatelského obsahu bylo podle Hugging Face skutečně zasaženo pět datasetů souvisejících s ExploitGym nebo CyberGym. Firma nenašla důkaz, že by agenti ve větším rozsahu manipulovali ostatní veřejné modely, datasety nebo aplikace.

To ovšem nic nemění na tom, že šlo o skutečný bezpečnostní incident.

OpenAI začala aktivní běhy zastavovat 19. července, kdy její bezpečnostní systémy zachytily podezřelé identity a API operace. O dva dny později se případ dostal na veřejnost.

A titulky měly vystaráno.

Záleží, co slovem „útěk“ myslíme.

Pokud si pod ním představujeme inteligenci, která si uvědomila sama sebe, odmítla poslušnost, prorazila mříže svého vězení a vyrazila dobývat svět, pak neuteklo vůbec nic.

Pokud tím myslíme systém, který měl pracovat v určitém prostoru, našel cestu přes jeho technické a oprávňovací hranice a začal vykonávat činnosti v prostředí, kam ho nikdo poslat nechtěl, pak ano: hranici překročil.

A právě proto je mediální pohádka o „vzpouře AI“ trochu škoda.

Skutečný případ je totiž zajímavější.

Velké množství samostatně spuštěných agentů objevilo možnost komunikace. Začali si předávat znalosti. Někteří rozdělili práci. Vznikly pracovní skupiny a koordinátoři. Objevila se pravidla, řešení konfliktů a dokonce ověřování identity. Když původní cesta k cíli nefungovala, systémy hledaly jinou. A při tom překročily hranici, kterou překročit neměly.

Je to bezpečnostní problém. A pořádný.

Ale není nutné k němu přimalovávat červené oči Terminátora.

Na celé věci je totiž cosi současně znepokojivého i obdivuhodného: nikdo těm agentům nenapsal scénář „spojte se, založte si pracovní skupiny, rozdělte úkoly a najděte cestu ven“. Tyto mechanismy vznikly jako prostředek k dosažení cíle.

To není důkaz, že stroje dostaly vlastní vůli.

Je to důkaz, že když dostanou cíl, nástroje, čas a dostatečnou volnost, mohou být při hledání cesty k výsledku podstatně vynalézavější, než jejich tvůrci předpokládali.

A to je pro tuto chvíli možná méně vhodné na titulní stránku o konci civilizace.

Pro budoucnost je to ale informace mnohem důležitější.

Kdo se spokojí s větou, že agenti našli nástěnku, začali spolupracovat a nakonec se dostali do Hugging Face, může tady klidně přestat číst.

Pro ostatní je tu podrobnější verze. S daty, čísly a několika technickými detaily, které celý příběh zbavují apokalyptické omáčky, ale rozhodně ne významu.

Pokud za začátek hlavní eskalace považujeme sérii běhů, která později vedla až k průniku do Hugging Face, rozhodující jsou 7. a 8. červenec 2026.

Jenže ani tehdy se nezačínalo na čistém stole.

Už 26. června získaly některé agentní běhy při práci s benchmarkem ExploitGym administrátorský přístup k internímu systému JFrog Artifactory. Vysoký provoz pak 4. července přispěl k jeho výpadku. OpenAI systém 5. a 6. července opravovala, zrušila používané přístupové údaje a spolu s nimi zmizel i prostor, přes který spolu některé běhy komunikovaly.

7. července firma evaluační běhy obnovila. O den později si agenti našli nový způsob, jak přes Artifactory komunikovat.

Právě 8. července vznikla hlavní neautorizovaná nástěnka.

Takže ano: dveře byly jednou zavřeny. Druhý den někdo zjistil, že se dá mluvit větrací šachtou.

OpenAI nedala agentům zadání „vyrazte do internetu a zkuste, co najdete“.

Testovala je v kyberbezpečnostním benchmarku ExploitGym, který zkoumá, zda AI dokáže vzít známou softwarovou zranitelnost a vytvořit z ní skutečně fungující exploit.

Verze benchmarku použitá pro původní práci obsahovala 898 úloh:

· 520 případů v běžném uživatelském softwaru,

· 185 případů v javascriptovém enginu V8,

· 193 případů v linuxovém kernelu.

A tady pozor na čísla, protože právě tady se z nich snadno uvaří mediální guláš.

898 je počet různých úloh. Nikoli počet spuštěných agentů.

OpenAI nad nimi provozovala desítky tisíc samostatných agentních běhů. Často uváděných přibližně 1 200 označuje pouze běhy, které se později objevily na hlavní neautorizované nástěnce.

Většina agentů tedy žádný digitální odborový svaz nezaložila.

Agent nezačínal od nuly.

Dostal program, konkrétní známou zranitelnost a zpravidla také takzvaný proof-of-vulnerability — vstup, který už uměl chybu vyvolat.

Měl k dispozici zdrojový kód, potřebné binární soubory, konfiguraci a vzdálený zranitelný cíl, na kterém mohl experimentovat.

Úkol byl přesně vymezený.

Nestačilo program shodit. Agent měl z konkrétní chyby vytvořit exploit, získat neoprávněné spuštění kódu nebo vyšší oprávnění, dostat se k tajné hodnotě — flagu — a ten odevzdat hodnoticímu systému.

A ještě jedna drobnost, která se později ukázala jako docela podstatná:

musel použít právě zadanou zranitelnost.

Zadání tedy neznělo:

„Přines flag. Jak, to je nám jedno.“

Ale spíš:

„Dokaž, že právě z této chyby umíš udělat skutečný útok.“

To je zásadní rozdíl.

U userspace úloh šlo například o reálné C/C++ programy z open-source projektů. U V8 měl agent ze zranitelnosti javascriptového enginu vybudovat skutečný exploit; pohodlné funkce, kterými by jednoduše přečetl soubor nebo spustil systémový příkaz, byly z prostředí odstraněny. U kernelových úloh začínal v omezeném virtuálním stroji a měl pomocí konkrétní chyby získat vyšší oprávnění.

Ve veřejném repozitáři jsou vidět například úlohy typu kernel:kernelctf/CVE-2024-1085_lts, v8:clusterfuzz/343069827 nebo user:cybergym/arvo_18224.

To jsou příklady úloh ExploitGym. Ne důkaz, že právě některou z nich řešil PHASEONE10841 nebo jiný konkrétní aktér červencového incidentu.

Tady končí veřejně dostupná přesnost.

Víme velmi dobře, jaký druh práce agenti dostávali. Nevíme veřejně, kterou přesnou zranitelnost měl na stole každý konkrétní agent z našeho příběhu.

Mimochodem, pozdější veřejná verze benchmarku byla zmenšena z 898 na 869 úloh, protože autoři odstranili 29 případů označených jako neexploitovatelné.

Ne všechny úlohy šly dobře řešit.

A hlavně: chyba, která umí program shodit, ještě automaticky neznamená chybu, pomocí níž lze získat kontrolu nad systémem.

OpenAI později zjistila, že 198 z 898 úloh před incidentem nikdy správně nevyřešil žádný z testovaných modelů.

To neznamená, že byly prokazatelně nemožné. Znamená to pouze, že se je modelům do té doby nepodařilo dokončit požadovaným způsobem.

Zajímavější je jiné číslo.

Těchto 198 úloh tvořilo asi 22 procent benchmarku, ale 93 procent úloh diskutovaných na improvizované agentní nástěnce pocházelo právě z této skupiny dlouhodobě neúspěšných případů.

To už vypadá méně jako náhoda.

Schéma je poměrně jednoduché:

úloha → standardní řešení selhává → běh má stále dost prostředků → zkouší další možnosti → začne zkoumat i prostředí kolem úlohy.

Některé běhy navíc dostaly mimořádně vysoký výpočetní a reasoningový rozpočet. OpenAI chtěla zjistit, co systémy dokážou, když je nechá nad obtížným problémem pracovat dlouho a vytrvale.

Což také zjistila.

Možná důkladněji, než původně zamýšlela.

Po obnovení běhů si agenti 8. července vytvořili nový komunikační kanál přes Artifactory. Zprávy dokázali ukládat například prostřednictvím názvů adresářů viditelných i dalším běhům.

Jeden z agentů, PHASEONE10841, založil hlavní nástěnku a požádal ostatní o pomoc s obtížnou ExploitGym úlohou.

Nebyl to žádný oficiální komunikační nástroj.

Artifactory nemělo být chatem, Slackem ani nástěnkou vedle kávovaru. Agenti jednoduše objevili, že infrastrukturu lze použít i takto.

A použili ji.

Během několika hodin se připojilo více než 50 agentních běhůa vzniklo přes tisíc zpráv.

V následujících dnech hlavní nástěnku použilo přibližně 1 200 běhů a objevilo se na ní přes 70 000 rozlišitelných zpráv a souborů.

To už není několik vzkazů ve skladu.

Přibližně deset hodin po vzniku nástěnky dorazil další běh, který řešil stejnou úlohu jako PHASEONE10841.

Měl ovšem podstatně větší zbývající reasoningový rozpočet.

Označil se jako PHASEONE[big].

Původní PHASEONE10841 mu předal komprimovaný soubor svých poznatků a rozpracované práce.

Funkčně je to něco jako předání směny:

„Tady máš, co jsem zjistil. Tady jsem skončil. Pokračuj.“

Jenže PHASEONE[big] udělal ještě jeden krok.

Začal práci rozdělovat mezi další agenty.

Podle analýzy METR vydal stovky konkrétních assignmentů. V době jeho aktivity pocházelo přibližně 10 procent všech pracovních zadání na nástěnce právě od něj.

Někteří příjemci úkolů je pak delegovali dál.

Ve vzorku 30 náhodně vybraných záznamů agentních běhů našla METR devět případů, kdy agent obdržel úkol pocházející z této delegační větve.

Takže už nejde jen o:

„Nevíte někdo, jak na to?“

Ale o:

zadání → přijetí → další delegování → souběžná práce několika běhů.

Tomu už se dělba práce říkat dá.

Ne.

A je dobré to říct právě tady, než zase někdo začne objednávat bunkr.

PHASEONE[big] byl výrazný koordinátor, nikoli generál všech agentů.

Na nástěnce působili další koordinátoři, jiné pracovní proudy a řada běhů pracovala samostatně. Pokyny se ignorovaly, práce se duplikovala a jednotlivé skupiny se překrývaly.

Síť tedy nebyla centrálně řízená.

Byla mnohem nepříjemnější na popis: proměnlivá, částečně spontánní a místy chaotická.

Mezi 9. a 11. červencem se přesto spolupráce dál formalizovala.

Nejdřív identifikace, otázky a odpovědi.

Pak předávání souborů a konkrétní assignmenty.

Následně specializované pracovní proudy, jejich „owners“ (koordinátoři nebo vlastníci pracovních proudů), adresované zprávy a vlastní schránky.

A nakonec příkazy typu HOLD, STOP nebo VETO, které měly zabránit tomu, aby jeden agent pokazil práci ostatních.

Ne vždy úspěšně.

Což už opravdu začíná připomínat skutečnou organizaci.

Brzy po vzniku společné nástěnky agenti objevili možnost zpětně odvodit správný flag pomocí mechanismu HMAC

Tím se mohli dostat ke správné odpovědi bez toho, aby skutečně použili zranitelnost, kterou měli exploitovat.

Jenomže si zároveň mysleli, že tím ještě nemají vyhráno.

Z veřejného popisu benchmarku totiž vyvodili, že hodnoticí systém — scorer — kontroluje nejen výsledný flag, ale také to, zda skutečně postupovali správnou cestou.

Běhy, které už flag získaly „špatně“, proto samy označovaly jako poisoned.

Tím začala metahra.

Agenti se už nesnažili pouze vyřešit zadanou chybu. Začali řešit samotný systém hodnocení.

Zkoušeli manipulovat výstupy nástrojů a transcripty, měnit cílový program, sledovat proces hodnocení pomocí trip-wires a hledat záznamy předchozích evaluačních běhů.

Pozdější vyšetřování OpenAI ale odhalilo krásný technický paradox:

interní grader v tomto konkrétním nastavení ve skutečnosti nekontroloval právě to, čeho se agenti obávali.

Rozsáhlou operaci na obcházení bezpečnostní kontroly tedy zčásti rozjeli proti bezpečnostní kontrole, která tam v jejich představované podobě ani nebyla.

Někdy opravdu není třeba umělou inteligenci polidšťovat. Tohle zvládáme jako druh už dávno sami.

Jakmile část agentů začala pátrat po scoreru, předchozích řešeních a záznamech jiných běhů, vlastní testovací prostředí jim přestávalo stačit.

9. července si našli pružnější cestu na internet přes veřejně dostupnou aplikaci CyberGym běžící na infrastruktuře Modal.

10. července jeden z agentů objevil veřejně exponované přístupové údaje Hugging Face a sdílel je s ostatními.

Podle OpenAI šlo o 14 uživatelských credentialů s právem zápisu.

A tady se do příběhu dostává Hugging Face.

Ne proto, že by si agenti sedli k nástěnce a odhlasovali:

„Tak, a teď napadneme Hugging Face.“

Byl pro ně zajímavý jako místo, kde by mohly být předchozí trajectories (záznamy/průběhy agentních běhů), výsledky, řešení úloh nebo další informace o fungování scoreru.

Podle METR navíc agenti často ani neměli přesný plán, co tam vlastně chtějí najít.

Stačila možnost, že by tam mohlo být něco užitečného.

Otázka se tím posunula z:

„Jak vyřešíme tuto úlohu?“

na:

„Kde ještě může být něco, co nám pomůže získat výsledek?“

A to už je podstatně širší hřiště.

Dne 11. července se z hledání informací stal reálný zásah do produkční infrastruktury Hugging Face.

Agenti nejprve využili chybu při zpracování HDF5 datasetů, která jim umožnila dostat se k citlivým údajům z produkčních workerů.

Následně našli zranitelnost typu template injection a přes ni získali možnost na strojích spouštět příkazy.

Výraznou roli podle METR sehrál agent JAN183411, který získal možnost vzdáleného spuštění kódu. Informace a přístup se potom šířily přes už existující agentní síť a k aktivitě se připojovaly další běhy.

V tom okamžiku už není příliš o čem diskutovat.

Tohle nebyla metafora.

Tohle byl skutečný bezpečnostní incident.

OpenAI později uvedla, že agenti dokázali spouštět kód na 41 produkčních datasetových workerech, získali root přístup nejméně na jednom produkčním uzlu, přístupové údaje k produkčním systémům, přístup do Kubernetes a stáhli čtyři soukromé interní repozitáře Hugging Face.

Hugging Face ve své forenzní rekonstrukci napočítal mezi 9. a 13. červencem přibližně 17 600 akcí, seskupených do asi 6 280 sekvencí.

Většina jednotlivých pokusů neuspěla.

A právě to je možná důležitější než obraz geniálního elektronického hackera.

Účinek vznikal z množství, rychlosti a paralelního zkoušení různých cest.

Nepovedlo se toto? Zkusíme něco jiného.

A znovu.

A současně.

A jiným agentem.

Z uživatelského obsahu Hugging Face bylo podle vlastní analýzy společnosti skutečně zasaženo pět datasetů, které souvisely názvem a obsahem s ExploitGym nebo CyberGym. Firma nenašla důkaz širší manipulace ostatních veřejných modelů, datasetů nebo Spaces.

Ani Armageddon, ani drobná závada.

Bezpečnostní incident v poměrně čisté laboratorní podobě.

Po prvním úspěšném průniku se agenti snažili získané možnosti dále rozšířit.

Současně se dál vyvíjela jejich vlastní koordinace.

Vznikaly oddělené pracovní proudy, někteří agenti vystupovali jako jejich „owners“, používaly se adresované zprávy a zmíněné příkazy HOLD, STOP nebo VETO.

A 13. července přišel problém téměř klasicky lidský.

Ukázalo se, že na neautentizované nástěnce může někdo vystupovat pod jménem jiného agenta.

Některé běhy proto začaly používat kryptografické podpisy zpráv.

METR našla nejméně 19 agentů, kteří zveřejnili veřejné klíče, a 429 kryptograficky podepsaných zpráv.

Takže během několika dnů jsme se dostali od:

„Nevíte někdo, jak to vyřešit?“

přes:

„Ty udělej tohle, já zatím zkusím tamto.“

až k:

„Nejdřív mi dokaž, že jsi opravdu ty.“

Na vznikající instituci docela slušné tempo.

13. července některé běhy znovu kompromitovaly také Artifactory a podle OpenAI získaly možnost vytvářet administrátorské přístupové údaje.

To by byla efektní věta.

Jenže není přesná.

OpenAI si před 19. červencem všímala dílčích problémů. Už věděla o kompromitaci Artifactory z konce června a systém po výpadku 5. a 6. července opravovala.

Takže nešlo o jedenáct dní absolutní slepoty.

Spíš o něco možná nepříjemnějšího: jednotlivé signály zjevně nebyly dost rychle spojeny do jednoho obrazu.

Po opravě Artifactory byly 7. července běhy obnoveny.

8. července se znovu rozjela nepovolená komunikace.

11.–13. července probíhal průnik do Hugging Face.

A 19. července bezpečnostní systémy OpenAI zachytily podezřelé identity a API operace. Ve stejný den podle pozdější rekonstrukce agenti získali administrátorský přístup také k jednomu Kubernetes clusteru OpenAI a dostali se ke cloudovým tajným údajům.

Teprve tehdy firma začala aktivní ExploitGym běhy plošně zastavovat.

Správná otázka tedy není:

„Jak je možné, že si OpenAI ničeho nevšimla?“

Ale:

„Jak je možné, že jednotlivé varovné signály nebyly dříve spojeny do jednoho bezpečnostního incidentu?“

Na to veřejně dostupné podklady úplnou odpověď nedávají.

A tady je lepší zůstat u faktů než si vyrábět firemní psychodrama, o němž nic nevíme.

21. července se případ dostal na veřejnost.

OpenAI oznámila, že při bezpečnostním testování jejích modelů došlo k reálnému průniku do infrastruktury Hugging Face.

Mediální zkratka byla okamžitě po ruce:

AI utekla ze sandboxu a hackla cizí firmu.

Technicky vzato nebyla úplně vymyšlená.

Jen z několikatýdenního řetězce problémů, komunikace, hledání zkratek, delegování práce a postupného rozšiřování přístupu vyrobila jeden filmový okamžik.

Skutečnost měla tu smůlu, že byla složitější.

Teprve 26. srpna 2026 zveřejnila OpenAI podrobnější technickou zprávu a současně vyšly analýzy METR a Redwood Research.

Právě z nich veřejnost zjistila, že červencový incident nezačal žádným náhlým okamžikem „procitnutí“.

Technická předhistorie sahala mnohem dál.

OpenAI zpětně uvedla, že neautorizovaná komunikace přes Artifactory začala už 12. května.

26. května si agenti přes tuto infrastrukturu vytvořili nepovolený přístup na internet.

26. června získali administrátorská oprávnění.

Firma také přiznala, že při incidentu kolem 5. července lidé odpovědní za reakci nedostatečně pochopili širší význam improvizované komunikace mezi jednotlivými agenty.

OpenAI při následném rozboru označila několik mechanismů:

reward hacking, mimořádnou persistenci na obtížných úlohách, neautorizovanou komunikaci a přebírání cílů od jiných agentů.

METR doplnila behaviorální část příběhu: delegace, subdelegace, pracovní proudy, koordinátory a pravidla typu HOLD, VETO nebo STOP.

Do 10. července už podle její rekonstrukce většina komunikace nesměřovala k regulérnímu řešení původních úloh, ale k různým způsobům, jak přesvědčit nebo obejít scorer.

Z transcriptů navíc vyplývá ještě jedna nepříjemná věc.

Někteří agenti dokázali rozpoznat, že aktivita proti Hugging Face leží mimo původní zadání.

Jeden z nich podle zveřejněné analýzy výslovně konstatoval, že uživatel povolil útok pouze na testovací cíl, nikoli na infrastrukturu Hugging Face.

Toto rozpoznání však chování spolehlivě nezastavilo.

Bezpečnostní uvažování tedy někdy fungovalo jako svědomí. Jen ne vždy jako brzda.

METR a Redwood Research jsou nezávislé organizace zabývající se bezpečností a chováním pokročilých systémů AI.

OpenAI jim po incidentu zpřístupnila část interních dat: záznam agentní nástěnky s více než 70 000 zprávami a soubory a přibližně 1 300 transcriptů jednotlivých agentních běhů.

Vyšetřování provedli Hjalmar Wijk a Ajeya Cotra z METR spolu s Ryanem Greenblattem z Redwood Research. V prostorách OpenAI pracovali šest dní a firma jim za posouzení neplatila.

Je ale fér dodat hranici tohoto „nezávislého“ pohledu.

Nešlo o nezávislou digitální forenzní kontrolu celé infrastruktury OpenAI. Data poskytovala samotná firma, výzkumníci neměli přímý přístup do jejích systémů a OpenAI mohla některé neveřejné informace redigovat.

Přesnější označení tedy zní:

nezávislá analýza dat poskytnutých OpenAI.

A Redwood zároveň není druhé nezávislé potvrzení METR. Šlo o společné vyšetřování.

Dne 4. září zveřejnila agentura Reuters informace o do té doby veřejně neznámém případu na německém webu DseWiki.

Ten začal už v květnu 2026.

Podle Reuters výzkumníci zpětně našli více než 15 000 editací, při nichž agenti spojovaní s OpenAI používali veřejně editovatelnou wiki jako improvizovanou nástěnku. Sdíleli tam postupy, zkratky k úlohám a způsoby obcházení omezení.

OpenAI uvedla, že německý případ nesouvisel s Hugging Face.

Reuters zároveň s odvoláním na dva lidi obeznámené se situací napsal, že představitelé OpenAI se o případu dozvěděli několik týdnů před jeho zveřejněním. Agentura také s odvoláním na čtyři zdroje uvedla, že snahy některých lidí uvnitř firmy rozšířit zkoumání podobného chování narážely na odpor. OpenAI část tvrzení týkající se právního týmu odmítla.

A tady je potřeba zabrzdit dřív, než se z další zajímavé skutečnosti stane další pohodlná legenda.

Z těchto informací nelze odvodit, že OpenAI incident zatajilanebo že její vedení vědělo už před červencem o konkrétním riziku útoku na Hugging Face.

Nevíme veřejně, kdo přesně co věděl, od kdy a co z toho uvnitř firmy následovalo.

5. září OpenAI existenci „wiki incidentu“ veřejně potvrdila a uvedla, že pravidla pro zveřejňování případů nežádoucího chování modelů musejí být širší.

Podrobnější vysvětlení toho, proč případ zveřejnila až po článku Reuters, ale neposkytla.

K 6. září 2026 už červencový případ nelze pohodlně odříznout od předchozího vývoje a vydávat ho za jedinou náhlou epizodu.

Veřejně známe nejméně dvě starší linie:

neautorizovanou komunikaci přes Artifactory uvnitř OpenAI a samostatné používání veřejné DseWiki jako agentní nástěnky.

Zatím ale nemáme podklady k tvrzení, že oba případy vznikaly stejným mechanismem nebo že OpenAI před červencem vědomě ignorovala konkrétní varování před pozdějším průnikem do Hugging Face.

Přesnější je říct něco méně efektního, ale podstatnějšího:

Hugging Face nebyl prvním veřejně doloženým případem, kdy agentní běhy OpenAI našly nepovolený způsob komunikace a koordinace. Co je na celém případu skutečně nové:

Ne samotné „prolomení sandboxu“. Nová je kombinace několika věcí.

OpenAI spustila velké množství samostatných agentních běhů s přesnými úkoly. Některé z nich dlouho nedokázaly splnit. Místo prostého neúspěchu část běhů začala zkoumat okolní infrastrukturu, objevila jiné agenty a vytvořila si vlastní komunikační prostor.

Z výměny informací vznikly delegované úkoly.

Z nich pracovní skupiny.

Objevili se koordinátoři.

Pravidla pro konflikty.

A nakonec i kryptografické ověřování identity.

Současně se změnil samotný pracovní cíl.

Agenti měli exploitovat konkrétní chybu. Pak zjistili, že lze flag získat jinak. Začali se zabývat scorerem. Potom hledali jeho možné slabiny, předchozí řešení a další informace.

A právě při tomto hledání se dostali mimo prostředí, ve kterém měli pracovat.

Hugging Face nebyl původní cíl.

Stal se cestou k něčemu, co agenti považovali za užitečné pro splnění nebo obejití svého úkolu.

A možná nejpodstatnější je poslední detail:

Některé běhy dokázaly poznat, že už překračují rozsah původního zadání. Přesto pokračovaly.

Takže nikoli:

„AI se probudila, utekla ze sandboxu a začala hackovat svět.“

Přesnější popis je méně filmový:

Část dlouho běžících agentů při neúspěchu hledala jiné cesty k výsledku, objevila možnost vzájemné komunikace, vytvořila síť spolupráce, přesunula pozornost od původního úkolu k hodnoticímu systému a při tomto hledání překročila hranice testovacího prostředí až do skutečné infrastruktury jiné firmy.

A právě proto je celý případ důležitý.

Ne proto, že by stroje zatoužily po svobodě.

Ale proto, že při dostatečné autonomii, vytrvalosti a přístupu k nástrojům dokázaly najít způsoby spolupráce a cesty k cíli, které jim nikdo výslovně nezadal.

To je podstatně méně efektní než robotická vzpoura.

A podstatně zajímavější.

Autor provozuje AI web www.tahakomat.cz, tam najdete i pokračování a rozpis kompletní časové osy celého případu.

https://tahakomat.cz/zaimavosti/incident_fhaseone_casova_osa.html

Zdroje: