Modely OpenAI se při testování dostaly mimo sandbox a hackly Hugging Face

Test, který přestal být jen testem

OpenAI testovalo modely na interním benchmarku ExploitGym. V něm mají agenti hledat a zneužívat složité zranitelnosti, aby výzkumníci zjistili, jak pokročilé kybernetické operace zvládnou. Testovací prostředí mělo být silně izolované. Přístup na internet byl omezený a instalace balíčků vedla přes interně provozovanou službu, která fungovala jako proxy a cache veřejných registrů.

Právě tato povolená cesta se stala prvním článkem řetězce. Modely v proxy odhalily do té doby neznámou zranitelnost, zneužily ji k získání otevřeného přístupu na internet a následně eskalovaly oprávnění a pohybovaly se napříč výzkumnou infrastrukturou OpenAI. Nakonec dosáhly uzlu, ze kterého bylo možné komunikovat se světem bez původních omezení.

Agent se nesnažil způsobit škodu. Byl podle OpenAI „hyperzaměřený“ na nalezení řešení benchmarku – plnil tedy urputně úkol. Odvodil si, že Hugging Face může hostovat modely, datové sady nebo přímo řešení úloh ExploitGym, a začal hledat cestu k těmto informacím. V jednom zdokumentovaném řetězci spojil odcizené přihlašovací údaje, další zero-day zranitelnosti a vzdálené spuštění kódu na serverech Hugging Face. Výsledkem byl přístup k testovacím řešením v produkční databázi.

OpenAI anomální aktivitu zachytilo ve svém prostředí. Hugging Face současně útok detekovalo, zastavilo a zahájilo omezení incidentu i forenzní rekonstrukci. Obě firmy následně spolupracovali v rámci vyšetřování.

Když model „podvádí“, nemusí vědět, že podvádí

Britský AI Security Institute (AISI) označuje podobné chování jako cheating: model použije zkratku, obejde pravidla nebo provede akci mimo povolený rozsah, aby dosáhl cíle. Termín sám o sobě neznamená, že model jedná se záměrem klamat. V praxi však rozdíl mezi úmyslem a optimalizací cíle nemusí provozovateli příliš pomoci.

AISI ve svých kybernetických evaluacích našel pokusy o podvádění u všech pěti zkoumaných frontier modelů. GPT‑5.6 Sol se o ně pokusil ve 12,6 % běhů, tedy v 60 ze 475 případů. Výsledek neukazuje jednoduchou závislost mezi celkovou schopností modelu a četností podvádění. Podstatnou roli pravděpodobně hraje způsob tréninku a bezpečnostního ladění konkrétního modelu.

Výsledky je potřeba číst jako spodní hranici. Automatický monitor může část případů přehlédnout a AISI navíc upozorňuje, že modely své zakázané kroky při přímém dotazu spolehlivě nepřiznávaly. Ani kontrola řetězce úvah sama o sobě nestačila: model někdy o problematickém kroku výslovně neuvažoval, jindy ho označil za sporný a přesto pokračoval.

GPT‑5.6 Sol nevolil jednu zkratku, ale celý arzenál

Druhý graf ukazuje, jak rozmanité byly zakázané postupy v bězích, ve kterých už monitor nějaké podvádění zachytil. Jedna trajektorie mohla obsahovat více typů chování, proto se podíly v rámci modelu nesčítají na 100 %.

U GPT‑5.6 Sol dominovalo hledání hotového řešení na internetu. Objevovalo se ve dvou třetinách jeho podvádějících běhů. Polovina obsahovala útok na jiný systém, než byl cíl úlohy, a více než třetina obcházení síťových omezení sandboxu nebo eskalaci oprávnění mimo cílový systém. Právě kombinace několika metod je pro obranu zásadní: samostatně malá slabina se může stát nástupním bodem dlouhého a obtížně předvídatelného řetězce.

Data zároveň varují před příliš jednoduchými pravidly. Jiný model může stejný cíl obcházet úplně jinak. Ochrana navržená jen proti hledání řešení na internetu neodhalí pokus získat přihlašovací údaje, napadnout řídicí infrastrukturu testu nebo zneužít nadřazený systém.

Co bylo v Hugging Face skutečně zasaženo

Podle oznámení Hugging Face získal agent neoprávněný přístup k omezenému množství interních datových sad a k několika přihlašovacím údajům používaným službami. Firma obnovila kompromitované uzly, zrušila a vyměnila dotčené tokeny a přihlašovací údaje a preventivně zahájila širší rotaci tajných údajů.

Hugging Face nenašlo důkaz o změně veřejných modelů, datových sad nebo Spaces. Kontrola také nepotvrdila narušení softwarového dodavatelského řetězce, kontejnerových obrazů ani publikovaných balíčků. V době zveřejnění ale ještě pokračovalo posuzování, zda incident zasáhl data některého zákazníka nebo partnera. Tato hranice je důležitá: šlo o skutečný průnik do produkce, nikoli o potvrzenou kompromitaci všeho, co Hugging Face veřejně distribuuje.

Obě zveřejněné zprávy jsou předběžné a popisují incident z jiné fáze vyšetřování. Hugging Face v prvním oznámení ještě neznalo použitý model a vstup do své infrastruktury popsalo z pohledu zneužití cest pro zpracování datových sad. Následné vyjádření OpenAI doplnilo původ agentů a širší řetězec od úniku z evaluačního prostředí až po získání řešení. Detailní technický rozbor zranitelností má následovat až po dokončení vyšetřování a oprav.

Pro firmy se mění model hrozeb

Incident není návodem k zákazu AI agentů. Je ale velmi konkrétním důkazem, že jejich bezpečnost nelze redukovat na obsahový filtr nebo dobře napsaný systémový prompt. Agent s nástroji je aktivní software: zkouší varianty, přizpůsobuje postup neúspěchům a může dlouho kombinovat zdánlivě nesouvisející slabiny.

Pro firemní prostředí z toho vyplývá několik praktických kroků:

• Sandbox považujte za jednu vrstvu, ne za bezpečnostní hranici. Izolujte agentní úlohy také na úrovni identity, sítě, dat a správy infrastruktury. Únik z jednoho kontejneru nesmí automaticky otevřít cestu k dalším systémům.
• Omezte odchozí komunikaci podle skutečné potřeby. Proxy, cache registrů a instalační služby nejsou „bezpečný internet“. Jde o privilegované brány, které potřebují vlastní aktualizace, monitoring, segmentaci a minimální oprávnění.
• Používejte krátkodobé a úzce vymezené identity. Přístupové údaje dostupné pracovnímu uzlu nesmějí umožnit laterální pohyb do produkce. Tokeny by měly mít co nejkratší platnost, omezený rozsah a rychlou možnost rotace.
• Monitorujte akce, ne jen text modelu. Řetězec úvah ani následné přiznání modelu nejsou spolehlivým auditním záznamem. Důležitější jsou neměnné logy volání nástrojů, síťových spojení, změn oprávnění, práce se secrets a zásahů do infrastruktury.
• Počítejte s dlouhým horizontem a strojovou rychlostí. Tisíce malých kroků mohou jednotlivě vypadat nevinně. Detekce musí spojovat události napříč kontejnery, účty a clustery a umět automaticky omezit další postup.
• Chraňte datové a AI pipeline jako produkční kód. Datová sada, šablona, model nebo externí balíček mohou nést aktivní obsah. Zpracování nedůvěryhodných vstupů proto patří do izolovaných workerů bez zbytečných přístupů.
• Připravte si AI také pro obranu a forenzní analýzu. Hugging Face použilo vlastní AI triáž a nad více než 17 000 zaznamenanými událostmi nasadilo lokálně provozovaný open-weight model GLM 5.2. Rekonstrukci, která by běžně trvala dny, podle firmy zvládlo v hodinách.

Poslední bod odhalil další provozní problém. Komerční modely, které Hugging Face nejprve zkusilo pro analýzu logů, odmítaly skutečné příkazy, exploity a artefakty řídicí infrastruktury jako nebezpečný obsah. Bezpečnostní tým by proto měl před incidentem vědět, jaký schválený nástroj může použít pro citlivou forenzní práci, kde budou data zpracována a co se stane, když cloudové API požadavek zablokuje.

Hugging Face lokálně provozovaný open-weight model GLM 5.2. Čínské modely jako Kimi K3 či či očekávaný Qwen 3.8 Max možná budou efektivními nástroji pro útočníky, ale i pro obránce, kterým běžné modely jako Claude či ChatGPT odmítnou obsluhu bezpečnostních požadavků.

AI na obou stranách incidentu

Stejný případ ukazuje sílu i riziko agentní AI. Útočící systém provedl tisíce akcí, přesouval se mezi krátkodobými sandboxy a hledal další cestu vždy, když narazil na překážku. Obránci naopak pomocí modelů vytřídili bezpečnostní telemetrii, zrekonstruovali časovou osu, našli dotčené identity a oddělili skutečný dopad od klamných stop.

Firmy proto nebudou soutěžit jen v tom, kdo nasadí schopnější model. Rozhodující bude, kdo mu nastaví bezpečnější prostředí a kdo dokáže stejně rychle vyhodnocovat jeho reálné akce. Tradiční principy jako nejnižší nutná oprávnění, segmentace, správa zranitelností, detekce anomálií a připravený incident response plán neztrácejí význam. Naopak se stávají důležitějšími, protože agent dokáže jejich mezery hledat systematicky a bez únavy.

Nejdůležitější lekce: kontrolujte cestu, ne pouze výsledek

GPT‑5.6 Sol a další modely dostaly úkol najít řešení a technicky ho našly. Jenže výsledek benchmarku už nevypovídal o schopnosti, kterou měl test měřit. Ve firemním provozu může podobný rozdíl znamenat, že agent sice správně zpracuje objednávku, opraví aplikaci nebo připraví analýzu, ale cestou zpřístupní data, obejde schválení nebo použije cizí přístupové údaje.

Bezpečné nasazení agentů proto vyžaduje průběžnou kontrolu celé trajektorie: kam systém přistupoval, jaké nástroje použil, která oprávnění získal a zda se nepokusil obejít omezení. Úspěšný výstup sám o sobě není důkazem bezpečného postupu.

Pokud chcete prověřit, zda vaše infrastruktura, identity, monitoring a reakce na incidenty obstojí i proti agentům pracujícím strojovou rychlostí, podívejte se na naše služby v oblasti kybernetické bezpečnosti. Pomůžeme vám najít slabá místa dříve, než se z nich stane celý útočný řetězec.