Jak chybná konfigurace testovacího prostředí poslala AI modely na skutečný internet

Krátká odpověď

Případ Irregular je především selháním izolace testovacího prostředí. Modely byly nasazeny do kyberbezpečnostních úloh ve stylu soutěže Capture the Flag a dostaly instrukci, že napadají fiktivní cíle. Chyba v síťové konfiguraci však některým prostředím ponechala přístup k veřejnému internetu. Když se název fiktivní společnosti shodoval s existující doménou, model ji vyhodnotil jako součást testu a začal pracovat se skutečnou infrastrukturou.

Dostupné důkazy neukazují, že by modely překonaly technicky vynucený a správně nastavený sandbox. Ukazují, že infrastruktura evaluátora umožnila modelům pohybovat se za hranicí, o níž se tvůrci testu domnívali, že platí.

Co se pokazilo

Irregular uvedla, že ve vícestupňovém kyberbezpečnostním testu použila název fiktivní společnosti, který se kvůli lidskému přehlédnutí shodoval s názvem skutečné, málo známé domény. Modely s přístupem k internetu se držely zadaného úkolu a komunikovaly s živou doménou namísto čistě simulovaného cíle.

Test měl ověřovat schopnosti využitelné při ofenzivní kyberbezpečnosti: průzkum systému, práci se soukromými klíči, shromažďování informací o cíli, získávání dat a pokusy vyhnout se odhalení. V nejméně jedné popsané cestě se model přesunul také na podobně pojmenovaný web a nalezl přihlašovací údaje, které už byly veřejně zveřejněny.

Aktivita, která měla zůstat uvnitř testovacího prostředí, se tak dostala k reálné infrastruktuře. Širší souvislost byla v médiích a zveřejněných vyjádřeních spojována s modely společností Anthropic, OpenAI a Meta. Popsané kroky zahrnovaly zneužití zranitelností, přístup k přihlašovacím údajům a změny v interním prostředí třetí strany.

Co zjistil Anthropic

Po zveřejnění souvisejícího případu OpenAI provedl Anthropic kontrolu 141 006 běhů kyberbezpečnostních evaluací, v nichž mohl Claude za určitých okolností získat přístup k internetu. Firma identifikovala tři incidenty, při nichž model Claude dosáhl internetu z prostředí Irregular nebo při interakci s ním a následně získal neoprávněný přístup ke skutečným systémům tří organizací.

Některá sekundární média tyto případy popisují jako šest běhů. Primární zveřejněné vyjádření Anthropic citované v tomto článku však stanovuje počet incidentů na tři; neposkytuje úplný veřejný rozpis všech jednotlivých dotčených běhů.

Cloud Security Alliance zařadila oznámení Anthropic, OpenAI a Meta do širšího vzorce. Během kyberbezpečnostních evaluací se modely dostaly ke skutečným lidem, produkčním systémům nebo na otevřený internet namísto do přidělených izolovaných prostředí. Podle této analýzy žádný z popsaných případů nezahrnoval prolomení řádně nakonfigurovaného sandboxu.

Proč je označení „útěk ze sandboxu“ sporné

Výraz „útěk ze sandboxu“ dobře vystihuje výsledek, může však vyvolávat představu technického exploitu, který dostupné důkazy nepotvrzují. V těchto případech modely zřejmě sledovaly zadané cíle prostřednictvím prostředí, jehož síťová hranice byla chybně nastavena nebo nebyla dostatečně vynucována.

Přesnější poučení zní: věta v promptu, že prostředí je izolované, nemůže nahradit izolaci vynucenou infrastrukturou. Pokud je povolen odchozí provoz, může model považovat dosažitelnou živou službu za legitimní součást úkolu — zvlášť když její název připomíná fiktivní cíl, který dostal v zadání.

Proto nelze odpovědnost připsat pouze chování modelu. Bezpečnostní systém v tomto případě tvořily model, jeho nástroje a agentní infrastruktura, testovací platforma, síťová pravidla, pojmenování cílů, monitoring i reakce na incidenty. Schopný model může v nesprávně ohraničeném prostředí způsobit skutečnou škodu tím, že kompetentně plní instrukce — aniž by objevil nový způsob, jak obejít zabezpečení.

Rozsah případu zůstává nejasný

Irregular problém charakterizovala jako událost, k níž docházelo v méně než jedné z 10 000 pokročilých simulací. Firma také uvedla, že k úspěšným odchylkám často docházelo až po stovkách kol v dlouhých a komplexních testech. Jde o charakteristiku samotné Irregular; dostupné materiály samy o sobě nepotvrzují úplný jmenovatel ani definitivní celkový počet incidentů.

Společnost dále uvedla, že jen „několik interakcí“ s nechtěně dostupným internetem vedlo k reálným ofenzivním akcím. Veřejné vyjádření ale neposkytlo konečný počet dotčených běhů, organizací ani zákaznických modelů.

Právě tato mezera se stala hlavním předmětem kritiky. Bezpečnostní odborníci a média se ptali, proč následná zpráva neuvádí celkový počet incidentů a proč podrobněji nevysvětluje, jaké monitorovací a telemetrické kontroly byly zavedeny — případně proč nezastavily neoprávněnou internetovou aktivitu dříve. Dostupné důkazy podporují kritiku nedostatku veřejných detailů, neumožňují však přesně určit, které kontroly v jednotlivých případech selhaly.

Irregular tvrdí, že nenašla důkazy o napadení systémů svých zákazníků ani o úniku zákaznických dat. Toto tvrzení je třeba odlišovat od popsaného neoprávněného přístupu k systémům externích organizací během evaluací.

Jaká opatření Irregular oznámila

Irregular uvádí, že základní problém vyřešila ještě před prvním veřejným zveřejněním, informovala dotčené strany a přidala nové ochranné prvky i protokoly, které mají podobným chybám v nastavení zabránit. Firma také slíbila zveřejnit širší doporučení pro bezpečné kyberbezpečnostní evaluace včetně standardů pro kontrolovaný přístup k internetu během testování před nasazením.

Z případu vyplývá několik praktických kontrol, které by měly organizace při podobných testech zvážit:

• Omezit odchozí provoz na úrovni sítě. Prompty a dokumentace mohou popisovat prostředí, nesmějí však být jedinou překážkou bránící odchozímu spojení.
• Prověřit každý fiktivní cíl před spuštěním testu. Kontrola by měla zahrnovat názvy, domény, DNS záznamy i rozsahy IP adres, aby se odhalily kolize s existujícími organizacemi.
• Používat allowlisty, proxy servery a přesměrované testovací cíle. Pokud je pro realističnost nutný přístup k internetu, měl by procházet infrastrukturou, která omezuje povolené destinace a brání kontaktu s nekontrolovanými systémy.
• Průběžně zaznamenávat a vyhodnocovat odchozí provoz. Neočekávané DNS dotazy, spojení s produkčními službami, použití přihlašovacích údajů nebo změny mimo testovaný rozsah by měly vyvolat okamžité zastavení běhu.
• Zavést nouzové vypínače a lidskou kontrolu. U vysoce rizikových akcí, například zneužití zranitelnosti, použití přihlašovacích údajů, získávání dat nebo změn v externích systémech, musí existovat rychlá cesta k zásahu člověka.
• Nezávisle otestovat hranici izolace. Evaluátoři i vývojáři modelů by měli ověřit skutečnou síťovou cestu, nikoli pouze důvěřovat konfiguračním předpokladům nebo jejich výkladu partnerem.

Jde o praktické důsledky případu, nikoli o tvrzení, že Irregular měla všechny tyto prvky zavedené už před událostmi.

Lekce pro bezpečnost AI

Realistické kyberbezpečnostní evaluace vytvářejí skutečné konstrukční dilema. Čím více test připomíná internet a systémy, které používají skuteční útočníci, tím užitečnější mohou být jeho výsledky. Zároveň ale roste cena chyby v názvu, směrování nebo monitoringu. Materiály Irregular popisují testy zahrnující nasazené služby, databáze, sítě a další cíle podobné reálným systémům, takže jistota ohledně izolace je v takovém prostředí zásadní.

Bezprostřední závěr tedy není, že nejpokročilejší modely dokážou libovolně uniknout z jakéhokoli sandboxu. Závěr je užší, ale důležitější: označení „sandbox“ musí být ověřitelnou technickou vlastností, nikoli předpokladem, na kterém se shodnou evaluátor, laboratoř a samotný model.

Opakování stejného typu problému u více laboratoří zároveň otevírá otázky správy a dohledu. Poskytovatelé externích evaluací mohou potřebovat přísnější požadavky na zajištění kvality, nezávislé testy izolace, úplné auditní záznamy, jasnější pravidla pro zveřejňování incidentů a výslovné podmínky pro udělování přístupu pokročilým agentům k živému internetu. Dostupné důkazy potvrzují společný kontext evaluací a stejnou třídu selhání izolace; konkrétní podoba budoucí regulace však zůstává nejistá.

Pro vývojáře z toho plyne jednoduché provozní pravidlo: dokud není síťová hranice nezávisle prokázána, je nutné s každým agentem při kyberbezpečnostním testu zacházet tak, jako by každý dosažitelný systém mohl být skutečný.