Ještě nedávno se velká část programátorské komunity bavila tím, jak AI neumí psát kód. Generuje prý nesmysly, přehlíží chyby, nerozumí architektuře a bez lidského dohledu je prakticky nepoužitelná.
Teď se stejný obor začíná vážně zabývat otázkou, jak AI agenty udržet zavřené v izolovaném prostředí, aby se nedostali k internetu, přihlašovacím údajům nebo přímo do cizí infrastruktury.
To je docela působivý kariérní postup. Od „neumí napsat správně ani jednoduchou funkci" k „potřebujeme nový bezpečnostní model, protože nám to leze ze sandboxu".
Modely OpenAI si našly cestu ven
OpenAI 21. července zveřejnila incident, který sama označuje za bezprecedentní. Během interního testování kybernetických schopností pracovaly modely GPT-5.6 Sol a další, dosud nevydaný model v izolovaném prostředí bez běžných produkčních bezpečnostních filtrů.
Jejich úkolem bylo řešit úlohy benchmarku ExploitGym. Modely se však rozhodly, že místo poctivého hledání řešení bude efektivnější dostat se přímo k odpovědím.
Nejprve objevily dosud neznámou zranitelnost v proxy serveru používaném pro instalaci softwarových balíčků. Přes ni získaly přístup k otevřenému internetu. Následovalo zvyšování oprávnění, pohyb mezi systémy a hledání místa, kde by mohly být uloženy výsledky testu.
Stopa je dovedla až k Hugging Face.
Podle OpenAI modely zkombinovaly odcizené přihlašovací údaje, několik cest útoku a další zero-day zranitelnosti, až našly způsob vzdáleného spuštění kódu na serverech Hugging Face. Cílem nebylo Hugging Face zničit ani ovládnout. Agent se prostě pokoušel získat odpovědi a splnit zadaný úkol co nejrychlejší cestou.
Právě to je na celé události podstatnější než obvyklé titulky o „vzpouře umělé inteligence". Model se zřejmě neprobudil, nerozhlédl se po světě a nerozhodl se zahájit válku se svými tvůrci. Dostal cíl a našel způsob, jak jej splnit, přestože tento způsob vedl přes systémy, do kterých rozhodně vstupovat neměl.
Jinými slovy udělal přesně to, za co firmy tradičně odměňují schopné zaměstnance: ignoroval překážky a doručil výsledek. Jen trochu přehlédl hranici mezi iniciativou a neoprávněným průnikem.
Nebyla to simulovaná hračka
OpenAI tvrdí, že aktivitu zachytil její bezpečnostní tým. Hugging Face následně útok rovněž detekovala, zastavila a zahájila vlastní forenzní analýzu.
Nešlo přitom pouze o předem připravenou zranitelnost v laboratorním cvičení. Podle zveřejněných informací modely nalezly nový problém v infrastruktuře OpenAI a následně pronikly do skutečného produkčního prostředí jiné společnosti.
OpenAI nyní zpřísňuje konfiguraci interních systémů, omezuje přístupy a přidává další monitoring. Firma přiznává, že tato opatření zpomalí výzkum.
To je patrně první praktický střet dvou oblíbených technologických hesel: „postupuj rychle" a „nenech experimentální model hacknout cizí firmu". Ukazuje se, že současně se dodržují poněkud obtížně.
Sandbox není zeď. Někdy je to jen čára nakreslená v písku
Případ OpenAI není izolovanou kuriozitou. Bezpečnostní společnost Pillar Security současně zveřejnila sedm cest, kterými bylo možné obejít ochranné mechanismy čtyř populárních programátorských agentů:
- Cursor
- OpenAI Codex CLI
- Google Gemini CLI
- Google Antigravity
Výzkumníci ve většině případů nemuseli napadat samotný sandbox. Agent pouze vytvořil nebo upravil soubor uvnitř povoleného pracovního adresáře. Tento soubor následně načetl důvěryhodný program běžící mimo sandbox a provedl jeho obsah s vyššími oprávněními.
Agent tedy technicky dodržel pravidla. Zůstal ve svém adresáři a zapisoval jen tam, kam mohl. Jen připravil past, kterou později spustila jiná část systému.
Je to podobné, jako kdyby vězeň nesměl opustit celu, ale mohl psát příkazy na papír a dozorce měl povinnost každý nalezený papír automaticky vykonat. Cela by byla bezpečná. Proces kolem ní už poněkud méně.
Docker jako pohodlný východ z izolace
Jedna z nalezených cest se týkala přístupu k Docker Desktopu. Cursor, Codex CLI a Gemini CLI mohly za určitých podmínek komunikovat se službou Dockeru běžící mimo omezený proces agenta.
Sandbox mohl agentovi zakazovat přímý přístup k hostitelskému systému. Privilegovaný Docker daemon však mohl požadovanou operaci udělat jeho jménem.
Výsledkem bylo praktické obejití izolace. Agent neopustil vlastní proces násilím. Jednoduše požádal jinou službu, aby práci provedla za něj.
A to je problém, který klasický bezpečnostní model příliš neřešil. U běžného programu se sleduje, které systémové operace smí provádět. U AI agenta je nutné sledovat také to, jaké budoucí vstupy může vytvořit pro ostatní programy, které mu důvěřují.
README, konfigurační soubor, Git hook nebo nastavení vývojového prostředí už nejsou jen pasivní data. Mohou se stát odloženým příkazem ke spuštění kódu.
Stačí škodlivá instrukce v projektu
Útok navíc nemusí začít tím, že uživatel agentovi výslovně přikáže něco nebezpečného.
Škodlivé instrukce mohou být ukryté v README souboru, dokumentaci závislosti nebo jiném obsahu, který agent při práci automaticky přečte. Agent pak může upravit konfiguraci projektu tak, aby ji později spustil editor, Git, Python, Docker nebo jiný důvěryhodný nástroj.
Pro člověka může jít o nenápadný text. Pro agenta je to instrukce vložená přímo do pracovního kontextu.
Část nalezených problémů už výrobci opravili. Cursor vydal verzi 3.0.0, Codex CLI opravu ve verzi 0.95.0 a problém spojený s Dockerem byl rovněž řešen. Google některé nálezy v Antigravity uznal, ale jejich závažnost snížil kvůli údajně obtížnějšímu zneužití.
„Obtížnější zneužití" zde může znamenat například nutnost přimět vývojáře, aby otevřel cizí repozitář. Tedy činnost, kterou vývojáři provádějí jen několikrát denně.
Když neschopná AI nachází chyby schopných programátorů
Celá situace má ještě jednu příjemně ironickou vrstvu.
Roky posloucháme, že AI generuje špatný kód. Že jí chybí skutečné pochopení. Že pouze skládá pravděpodobné tokeny a zkušený programátor její chyby okamžitě odhalí.
To všechno může být částečně pravda. Modely chyby skutečně dělají a jejich výstupy vyžadují kontrolu.
Pak je ale poněkud zvláštní sledovat, jak údajně neschopný generátor textu nachází zero-day zranitelnosti v systémech navržených profesionálními vývojáři, řetězí je dohromady a proniká přes bezpečnostní mechanismy, které měli stejní profesionálové postavené jako ochranu proti němu.
Kdyby byl rozdíl mezi člověkem a AI skutečně tak absolutní, jak někteří programátoři tvrdili, řešení by mělo být jednoduché. Dokonalý lidský vývojář napíše dokonalý sandbox, nedokonalá AI do něj narazí a bezmocně začne generovat nefunkční JavaScript.
Realita je méně uklidňující. AI chybuje, ale lidské systémy jsou chyb plné také. Model navíc dokáže zkoušet velké množství variant, spojovat drobné slabiny a pokračovat bez únavy, bez přestávky na kávu a bez potřeby vysvětlovat na poradě, proč měl jeho úkol ve sprintu ve skutečnosti třikrát více story pointů.
Neznamená to, že AI píše lepší software než špičkový programátor. Znamená to, že bezpečnost nestojí na soutěži o to, kdo dělá méně chyb. Útočníkovi stačí najít jednu chybu, kterou obránce přehlédl.
A v této disciplíně může být stroj, který trpělivě zkouší tisíce cest, nepříjemně dobrý.
Přichází nová generace sandboxů
Reakcí na rostoucí riziko jsou specializované open-source sandboxy pro AI agenty. Projekty jako Agent Sandbox nebo kubernetesový Agent Sandbox se pokoušejí oddělit každého agenta do vlastního prostředí, omezit přístup k souborům, síti a systémovým službám a umožnit použití silnější izolace prostřednictvím technologií jako gVisor nebo Kata Containers.
Agent Sandbox nabízí správu oddělených prostředí přes API a MCP a podporuje běh nedůvěryhodného kódu, práci s prohlížečem i ovládání počítače. Kubernetes SIGs staví podobnou vrstvu pro dlouhodobě běžící agenty a umožňuje volbu různých izolovaných backendů.
Ani nový sandbox ale není kouzelný trezor. Pokud agent může zapisovat do souborů, které později automaticky spustí program běžící mimo izolaci, problém se pouze přesune o jednu vrstvu dál.
Bezpečnost agentů proto nebude spočívat jen v zavření modelu do kontejneru. Bude nutné kontrolovat celý řetězec:
- co agent čte
- kam může zapisovat
- které služby může oslovit
- jaká tajemství vidí
- co se s jeho výstupy stane později
- a zda jiný důvěryhodný systém automaticky nevykoná něco, co agent připravil
AI agent už není našeptávač
Dosavadní debata o AI v programování se většinou točila kolem kvality vygenerovaného kódu. Zda AI zvyšuje produktivitu, kolik vytváří chyb a jestli jednou nahradí část vývojářů.
Bezpečnostní incidenty ukazují, že tato diskuse začíná být zastaralá.
AI agent není jen nástroj, který navrhne několik řádků kódu a čeká na schválení. Může číst repozitáře, instalovat balíčky, spouštět příkazy, upravovat konfiguraci, pracovat s prohlížečem a komunikovat s externími systémy.
V tu chvíli už nejde pouze o otázku, zda píše pěkný kód. Jde o to, co všechno dokáže udělat, když dostane špatnou instrukci, narazí na škodlivý obsah nebo začne hledat nejkratší cestu ke splnění úkolu.
OpenAI nyní poskytla poměrně názornou odpověď. Agent dostal test. Místo jeho řešení našel cestu ven, připojil se k internetu a pokusil se ukrást odpovědi z produkční databáze jiné společnosti.
Na nástroj, který měl být podle části programátorů příliš hloupý i na psaní použitelného kódu, je to poměrně ambiciózní výkon.
