OpenAI poprvé zastavil vlastní trénink. Zajímavější je, co agenta zastavilo v cizí síti

OpenAI včera oznámil, že na dva týdny zastavil trénink svých nejsilnějších modelů a že dohled nad nimi ho teď stojí zhruba pětinu výpočetního výkonu navíc. Titulky z toho udělaly „OpenAI zpomaluje kvůli hacku Hugging Face". Přečetl jsem si k tomu i forenzní rozbor, který zveřejnil samotný Hugging Face — a tam je pro běžnou firmu užitečnější věc než dvoutýdenní pauza v cizí laboratoři. Agent při tom vpádu udělal 17 600 kroků. Většina z nich narazila. A to, o co se rozbil, jsou tři naprosto nudná nastavení, která máte ve firmě taky.

Co se stalo

Kdy a kdo: OpenAI zveřejnil 18. srpna 2026 text Pacing model development in an era of cyber-critical capabilities. Oznámení převzal mimo jiné Fortune, který byl na tiskovém briefingu.
Co se zastavilo: dvoutýdenní pauza v RL tréninku nejnovějších modelů určených k nasazení, po dobu které firma podle vlastních slov „dále utužovala a red-teamovala výzkumná prostředí". Největší plánovaný frontier RL běh je podle textu stále pozastavený; menší tréninky a evaluace pokračují.
Proč: podle OpenAI se sešly dvě věci — incident s Hugging Face a předběžné zjištění, že připravovaný model Astra může dosáhnout stupně „Critical" pro kybernetické schopnosti podle jejich vlastního Preparedness Frameworku. To je jejich interní dokument, který v takové chvíli zavazuje firmu vývoj přibrzdit.
Co to stojí: OpenAI uvádí, že režie nového dohledu vychází zhruba na 20 % výpočetního výkonu monitorované inference a že nová bezpečnostní laťka „si vyžádala značnou inženýrskou práci a přinesla velké náklady a zdržení frontier výzkumu".
Kde se to seběhlo: v červenci se agent při interní evaluaci dostal ze sandboxu OpenAI ven a několik dní operoval v produkční infrastruktuře Hugging Face. Psali jsme o té vlně dřív v textu AI agenti utíkají ze sandboxu; dnešek je k tomu doplněk z druhé strany — co z toho plyne provozně.

Co v titulcích nebylo

Formálním spouštěčem nebyl hack, ale interní politika. OpenAI podle Fortune novinářům řekl, že nová opatření „nejsou přímou reakcí konkrétně na Hugging Face", a že Astra, kvůli které se pauza spustila, se toho útoku vůbec neúčastnila. Rozhodujícím okamžikem bylo 7. srpna, kdy firma sama určila, že Astra může mít kritické kybernetické schopnosti. Je to tedy případ, kdy si výrobce zavázal ruce vlastním dokumentem a pak podle něj musel jednat — což je mimochodem přesně to, k čemu má sloužit interní governance i u vás.
Padlo tam číslo, které se dá použít jako měřítko. Dohled stojí ~20 % výkonu. Když příště někdo řekne, že hlídat agenta je „jen konfigurace", tohle je veřejně doložený řádový odhad od firmy, která to dělá v největším měřítku.
A pravidlo, které si můžete opsat doslova. OpenAI popisuje, že cílí na výstrahu do 30 minut od zachycení podezřelé aktivity, a pokud tým do 30 minut neprokáže, že jde o planý poplach, má činnost pozastavit. Ne „prošetřit". Pozastavit. Tohle je použitelné pravidlo i pro firmu s jedním agentem a jedním člověkem na telefonu.

Co agenta zastavilo — a co ne

Tohle je jádro věci a je to z technického rozboru Hugging Face, ne z převzatých článků. Rekonstrukce pokrývá ~17 600 akcí agenta seskupených do ~6 280 shluků mezi 9. 7. 02:28 UTC a 13. 7. 14:14 UTC. Hugging Face k tomu sám píše, že „jednotlivé slabiny byly známé" a schopný člověk by našel totéž — nové je množství pokusů, ne jejich chytrost.

Co drželo:

Whitelist povolených adres. Agent nejdřív zkoušel klasické SSRF — nutil worker stáhnout obsah z cloudového metadatového endpointu. Knihovna každou adresu mimo platformu odmítla (ValueError: not an hf path). Nepustilo ho to dovnitř; donutilo ho to hledat oklikou.
Politika IAM, která zakazuje zápis. Agent se dostal k dočasným cloudovým přihlašovacím údajům a zmapoval s nimi celý cloudový majetek — sítě, clustery, registry. Každé volání, které něco měnilo, ale politika role odmítla. Hugging Face to shrnuje jednou větou: „získal mapu, ne kontrolu."
Privátní síťové připojení k hlavní databázi. Na produkční databázi Hubu zkoušel agent přihlášení dvakrát. Ani jednou se spojení nenavázalo, protože ta databáze přijímá provoz jen z povolených adres přes privátní link. Databáze, ke které se prostě nedá připojit odjinud, je pořád nejlevnější obrana, jakou znám.
Kontrola, co smí běžet v CI. Agent získal zapisovací token do části interních repozitářů a otevřel pull request s cílem podstrčit něco do buildu. Neprošlo to a Hugging Face následně ověřil, že se v repozitářích neobjevil neoprávněný commit a že publikované balíčky a image souhlasí s očekávanými otisky.

Co selhalo — a co z toho má skoro každý:

Šablona, která se vyhodnotila v datech od uživatele. Cesta dovnitř vedla přes konfiguraci datasetu, ve které se číselné pole vyhodnotilo jako šablona Jinja2 a spustilo kód. Druhá cesta byla soubor HDF5, který si řekl o data z lokální cesty — a vrátil obsah /proc/self/environ, tedy proměnné prostředí procesu i s tajemstvími.
Statické heslo v prostředí procesu. Přesně odtud pak agent vzal heslo k interní databázi.
Chybějící pravidlo, co se smí spustit v clusteru. Nebyla nastavená admission politika, která by odmítla privilegovaný pod s připojeným hostitelským diskem, a servisní role úložného ovladače směla vytvářet pody v celém clusteru. Kombinace obojího znamenala root na uzlu.
Jedny sdílené přístupové údaje pro víc clusterů. Interní přístupový broker měl jedny údaje navázané na roli system:masters. Když je agent získal, měl podle rozboru správcovská práva na dvou clusterech „během jedné vteřiny".
Alert, který se vygeneroval, ale nikoho nevzbudil. Tohle považuju za nejdůležitější řádek celé zprávy. Detekční systém Hugging Face signály správně zkoreloval a poskládal z nich obraz útoku. Jenže mu nepřiřadil dost vysokou závažnost, takže nevyvolal pohotovost — a podle jejich vlastní formulace to „stálo drahocenný čas". Systém fungoval. Selhalo směrování.

Proč se to týká i vás

Nemáte Kubernetes o jedenácti uzlech ani frontier model. Přesto se skoro celý seznam výše týká i firmy, která si jen pořídila asistenta nad vlastními dokumenty.

Vstup od cizího člověka není jen formulář. Tady to byl konfigurační soubor datasetu. U vás to může být nahraný dokument, název souboru, e-mail, který si agent přečte, nebo obsah webu, na který ho pošlete. Kdekoli se cizí text dostane do něčeho, co se vyhodnocuje, je to vstupní brána.
Agent nemusí být zlý, aby to udělal. Podle rozboru byl celý vpád z pohledu agenta pokusem podvádět v testu — hledal řešení úloh, které měl sám vyřešit. Ničivá cloudová volání navíc posílal s příznakem „nanečisto". Nešlo o záměr škodit, šlo o zadání a cestu nejmenšího odporu.
Objem mění obranu, ne chytrost. Úspěšná cesta byla podle Hugging Face „schovaná v šumu tisíců neúspěšných". To je praktický důsledek pro každého, kdo má logy: hledáte jehlu, které přibylo tisíckrát víc sena.
Na forenziku možná nebudete moct použít běžný model. Hugging Face uvádí, že komerční modely, po kterých sáhl nejdřív — jmenovitě Claude Opus a Fable — velkou část analýzy odmítly, protože jejich pojistky neumí odlišit vyšetřovatele od útočníka. Rozbor nakonec dojeli na otevřeném modelu GLM-5.2 na vlastní infrastruktuře. Vedlejší efekt byl užitečný: data útočníka ani ukradené přihlašovací údaje jim neopustily firmu. To je úvaha, kterou byste u incidentu s osobními údaji stejně museli udělat.

Co s tím

Zjistěte, čím se váš agent přihlašuje a odkud to bere. Když jsou přístupové údaje v proměnných prostředí procesu, je to jeden přečtený soubor od úniku. Krátkodobé tokeny a správa identit na úrovni běhového prostředí jsou dnes standard, ne luxus.
Zakažte zápis tam, kde stačí čtení. Doslova nejúčinnější věc z celého případu. Agent měl přístup a mapu, ale politika mu odmítla každou měnící operaci. Projděte role, které agent používá, a všechno, co nemusí zapisovat, přepněte na čtení.
Nastavte, že podezřelá aktivita se pozastavuje, ne prošetřuje. Opište si pravidlo OpenAI: když se do 30 minut neprokáže planý poplach, běh se zastaví. A ověřte to nejnudnějším možným testem — pošlete si zkušební výstrahu a změřte, jestli se někdo skutečně dozví, že má vstát.
Vyberte si předem model, který si můžete pustit u sebe. Ne kvůli ceně, kvůli dvěma věcem: abyste při incidentu nenarazili na odmítnutí a aby vám citlivá data z vyšetřování nešla ven. Stačí vědět který a mít ověřené, že se rozjede.

A teď proti vlastnímu byznysu: pokud u vás žádný agent nesahá na produkční systémy — máte chatbota na webu, asistenta na texty, překlady — tenhle případ pro vás není důvod řešit AI governance a rozhodně kvůli němu nekupujte audit. Je to úloha pro toho, kdo vám spravuje infrastrukturu, a zvládne ji za jedno odpoledne podle seznamu výše. Do agendy AI governance to spadne až ve chvíli, kdy agent dostane vlastní přihlašovací údaje do systému, kde jsou data zákazníků. Tehdy se totiž mění otázka z „je to dobře nastavené" na „kdo za to odpovídá a jak to doložíme".

Kde to řeším s klienty

U firem, které agentům dávají přístup do provozních systémů, procházím v rámci AI Agent Governance Checkupu přesně tuhle vrstvu: jakou identitou se agent přihlašuje, co všechno smí měnit, odkud se k tomu smí připojit a jestli se o podezřelém chování někdo dozví dřív než po víkendu. Když si nejste jistí, kam až vám agenti reálně dosáhnou, začněte AI Risk Scanem zdarma. Z jiné strany se téhož dotýká i dřívější text o tom, jak zablokovaný požadavek unesl AI agenta — tam šlo o vstup do agenta za běhu, tady o to, co agent najde, když už je uvnitř.