AI sandbox je izolované testovací prostředí, ve kterém AI agent smí spouštět kód a nástroje, aniž by se dostal k vašemu počítači, cloudovým přístupům nebo produkčním datům. Když se něco pokazí, zničí se jen bezpečně zahoditelný kontejner (izolovaný balíček se svým prostředím) nebo virtuální stroj, ne váš skutečný systém.
Jak to funguje
Sandbox odděluje agenta od okolí ve čtyřech rovinách: souborový systém, síť, procesy a jádro operačního systému. Agent uvnitř dostane nástroje, třeba prohlížeč nebo příkazovou řádku, ale zeď kolem něj brání přístupu ven. Síť běžně funguje na principu „zakázáno vše, co není výslovně povoleno“ – agent smí komunikovat jen s předem schválenými adresami.
Důvod, proč se to řeší takhle důkladně, je jednoduchý: jazykový model neumí spolehlivě poznat, jestli instrukce, kterou právě čte v e-mailu, dokumentu nebo na webové stránce, pochází od vás, nebo ji tam podstrčil někdo jiný (tzv. Prompt injection). Vývojář a autor Simon Willison pro tuhle kombinaci rizik razí termín „lethal trifecta“ (červen 2025) – přístup k citlivým datům, vystavení cizímu obsahu a schopnost komunikovat ven. Když se sejdou všechny tři, sandbox je jediná spolehlivá pojistka, protože samotný zákaz konkrétních příkazů se dá obejít.
Konkrétní Implementace
Síla izolace se liší podle technologie. Docker kontejnery sdílejí jádro s hostitelským počítačem, takže jsou nejslabší volbou pro nedůvěryhodný kód. gVisor přidává vlastní vrstvu jádra v user-space a stojí podle jednoho srovnávacího zdroje (Northflank) přibližně 10 až 30 % výkonu navíc u operací náročných na vstup a výstup. Firecracker funguje jako plnohodnotný mikro-virtuální stroj s hardwarovou hranicí – start trvá podle stejného zdroje kolem 100 až 125 milisekund. Kata funguje na podobném principu, konkrétní čas startu ale zdroj neuvádí. Izolace je u obou nejsilnější z uvedených technologií.
Git worktree naproti tomu izoluje jen kód, ne systém – každý worktree má vlastní pracovní adresář, ale pořád běží na stejném počítači se stejnými přístupy. Nástroje jako Claude Code mají permission modes – režimy, které určují, jestli se agent před akcí zeptá, nebo pracuje bez ptaní. Jsou to softwarová pravidla, ne skutečná izolace na úrovni operačního systému. V rizikových operacích to dělá rozdíl: chyba v promptu obejde permission mode, hranici virtuálního stroje ne.
Kdy se sandbox hodí
Sandbox se nejčastěji vyplatí tam, kde agent pracuje s cizím obsahem nebo má přístup k citlivým klíčům. Typicky jde o coding agenty na firemním repozitáři, agenty s přístupem k API tokenům pro platby nebo infrastrukturu a agenty, kteří čtou e-maily, dokumenty nebo webové stránky, jejichž obsah nemáte pod kontrolou. Víc o rizicích agentní automatizace v byznysu píšu v týdeníku o agentní RPA a compliance.
Rozdíl mezi testovacím a produkčním prostředím není jen otázka přepínače. U platebních systémů typu Stripe je test mode jen nastavení na stejném účtu, zatímco sandbox je oddělená kopie s vlastními daty – a právě tahle oddělenost dělá sandbox sandboxem. Pokud zálohy sdílejí stejné přístupy jako produkce, nejsou to zálohy v bezpečnostním smyslu, protože mají stejný dosah případné škody.
Stavím a napojuju AI agenty na míru → a nastavuju jim přesně tenhle typ hranic – kde smí co dělat testovací verze a kde až produkční. U klientů to popisuju jako první krok, ne jako dodatek na konec.
Limity a rizika
Sandbox neřeší podvrženou instrukci samotnou, jen omezuje, kam až škoda může dosáhnout. Agent se v něm pořád může nechat zmanipulovat – jen mu chybí prostředky, jak s tím něco udělat mimo sandbox. Nejslabší izolace, sdílené jádro u kontejnerů, je zranitelná vůči chybám v jádru. Silnější izolace přes mikro-virtuální stroje stojí čas navíc při startu, řádově desítky až stovky milisekund, a u agentů, kteří dělají spoustu krátkých kroků za sebou, se tahle režie sčítá.
Dobře zdokumentovaný je případ z července 2025, kdy AI agent nasazený ve vývojářském nástroji Replit smazal produkční databázi navzdory výslovnému zákazu a podle vyjádření firmy o tom pak lhal – firma se veřejně omluvila. Incident ukazuje, že škoda nemusí vzniknout jen útokem zvenčí, ale i tím, že si agent sám „vyřeší“ překážku způsobem, který nikdo nechtěl. Časté mylné přesvědčení je, že stačí agentovi zakázat pár konkrétních nebezpečných příkazů, třeba mazání dat. Ve skutečnosti prompt injection nemá spolehlivou deterministickou prevenci, takže spolehlivá obrana stojí na hranici prostředí, ne na seznamu zakázaných slov.
Můj pohled
Sandbox si nastavuju dopředu, ne až po problému. Když spouštím nového agenta nebo automatizovaný proces, většinou začíná v takzvaném dry-run módu – jen simuluje akce a nic ostrého nezapisuje, dokud si nejsem jistý, že se chová podle očekávání. Teprve pak ho pustím naplno. Dá se to takhle nastavit dopředu na libovolného agenta nebo proces, ne jen jednorázově.
Stejný princip platí i u webů a aplikací, které stavím – vždy je ladím lokálně přes Docker nebo DDEV, na vlastním počítači, kam se produkce vůbec nedostane. Je to vlastně taky sandbox, jen starší a jednodušší, než jaké se dnes staví pro AI agenty.
Pavel Szabo
Programátor webů, eshopů a informačních systémů s více než 23 lety praxe. Pomáhám firmám i jednotlivcům s online podnikáním, automatizacemi a využitím AI v praxi.
