Prováděcí sandboxy pro agenty s umělou inteligencí: architektura, rizika a reálné vzorce

Home » PYTHON » Prováděcí sandboxy pro agenty s umělou inteligencí: architektura, rizika a reálné vzorce

Umožnění agentům umělé inteligence spouštět kód, dotýkat se souborů, otevírat prohlížeče a klikat na API je promění z efektního automatického doplňování v něco mnohem bližšího juniorskému inženýrovi s rootem na počítači. Právě tato extra síla je důvodem, proč působí magicky – a také důvodem, proč mohou být nebezpeční. Špatně nastavený nebo jednoduše chybný agent může vymazat databázi, zveřejnit API klíč na internetu nebo nasadit poškozenou verzi do produkčního prostředí, aniž by skutečně „pochopil“, co se pokazilo.

Skutečná otázka už nezní „jak přesný je model?“, ale „čeho může dosáhnout, když se mýlí, je podveden nebo si je příliš jistý?“. Inženýrským řešením jsou spouštěcí sandboxy pro agenty: úzce vymezená prostředí, kde agenti mohou číst a psát kód, spouštět shell, servery nebo roztočit prohlížeče, zatímco vy striktně kontrolujete souborové systémy, síť, přihlašovací údaje a životní cyklus. Místo důvěřování modelu omezujete poloměr útoku.

Proč kódovací agenti potřebují vyhrazený sandbox pro provádění

Moderní kódovací agenti jako Claude Code, LangChain Deep Agents, Dockerovy kódovací sandboxy a podobné nástroje se již nechovají jako jednoduchí chatboti s přístupem k souborům. Čtou celé repozitáře, upravují soubory, spouštějí příkazy shellu, manipulují s Gitem, spouštějí sestavení Dockeru, komunikují s externími API a dokonce provozují plnohodnotná desktopová prostředí prostřednictvím prohlížeče. Dokumentace dodavatelů je v tomto ohledu velmi explicitní: Claude Code je prezentován jako agilní vývojářský asistent, který dokáže prozkoumat vaši kódovou základnu, provádět úpravy a spouštět příkazy; LangChain Deep Agents považují sandboxový backend za místo, kde spouští příkazy shellu, spravují souborové systémy a delegují práci na subagenty pro izolaci.

Právě tato sada schopností dělá tyto agenty užitečnými – a zároveň provozně rizikovými. Jakmile je model schopen běžet pytest, instalovat npm balíčky, otevírat větve nebo ladit selhání sestavení, je to jen pár volání nástrojů od úpravy skriptů nasazení, odesílání poškozených obrazů, úpravy konfigurací CI nebo exfiltrace tokenů prostřednictvím HTTP požadavků. Vlastní pokyny pro bezpečnost agentů OpenAI a práce NISTu o únosu agentů kladou důraz na prompt injection: škodlivé instrukce skryté v souborech, webových stránkách nebo protokolech mohou nenápadně navést agenta k akcím, které jste nikdy nezamýšleli autorizovat.

Mnoho týmů začíná s naivními postupy „žádosti o schválení“ pro každý příkaz a rychle zjistí, že se nedají škálovat. Anthropic veřejně sdělil, že uživatelé schválili 93 % výzev k povolení od Claude Code; Dockerův sandbox Claude dokonce spouští Claude Code s... --skip-permissions ve výchozím nastavení se spoléhají na izolaci za běhu namísto záplavy dialogů. Lidé pociťují únavu ze schvalování, zejména při paralelním spouštění více agentů a přepínání kontextu v mnoha výzvách. V tomto okamžiku se potvrzovací dialogy stávají ceremoniálem, nikoli spolehlivou kontrolou.

Pískoviště pro provádění posouvá bezpečnostní model z „důvěřovat uživateli, že si přečte každou výzvu“ na „předpokládat, že některé příkazy budou chybné nebo kontradiktorní, a omezit škody, které mohou způsobit“. Pískoviště se stává pevnou hranicí kolem souborů, procesů, sítí a tajných dat, kterých se agent může dotknout, a to i v případě, že je manipulováno promptním vkládáním dat nebo jednoduše děláním chyb.

Existuje také základní argument týkající se zkušeností vývojářů: agenti potřebují dostatek prostoru pro skutečnou práci. Pokud používáte sandbox s hrubými omezeními, jednoduché příkazy, jako jsou sestavení nebo testy, neustále selhávají kvůli obskurním chybám oprávnění. Nejlepší systémy, jako jsou ty nasazené společností Cursor na macOS/Linux/Windows nebo Cloudflare, Heroku a Google Cloud pro hostované úlohy, se snaží agentům poskytnout pocit „skutečného počítače“ uvnitř těsného perimetru.

Co spouštěcí sandbox pro agenty skutečně izoluje

Správný agentský sandbox není jen „někde jinde pro spouštění kódu“ – je to svazek explicitních hranic, které definují poloměr výbuchu. Můžete si představit pět hlavních omezení, která se opakovaně objevují na předních platformách, jako jsou Docker Sandboxy, Cloudflare Sandboxy, GKE Agent Sandbox, Freestyle VMs, E2B nebo Daytona.

Zaprvé, hranice souborového systému: agent by měl vidět pouze pracovní prostor, který záměrně sdílíte. Dokumentace LangChainu definuje sandbox jako bariéru, která brání agentům v přístupu k hostitelským souborům; model sandboxu v Dockeru je naprosto jasný, že microVM vidí pouze explicitně připojený adresář projektu. Cokoli mimo tento strom je neviditelné nebo je pouze pro čtení, takže agent nemůže jen tak číst. ~/.ssh nebo přepsat systémové konfigurace.

Za druhé, hranice mezi procesem a jádrem: úlohy agentů by neměly sdílet nezpracované jádro hostitele ani tabulku procesů. Architektura sandboxu v Dockeru izoluje každé prostředí samostatně. microVM a linuxové jádroFirecracker (používaný v interních vrstvách několika poskytovateli) považuje hranici virtuálního počítače za první izolační vrstvu a poté k ní přidává seccomp, jmenné prostory, cgroups a omezení podobná jailům. Google GKE Agent Sandbox dosahuje podobného efektu uvnitř Kubernetes pomocí gVisor: vrstva „sentry“ zachycuje systémová volání a zprostředkovává přístup k podkladovému uzlu.

Za třetí, hranice sítě: bez síťových zásad je agent v sandboxu stále strojem pro exfiltraci dat. Většina seriózních platforem je nyní standardně dodávána s funkcí „zakázat veškerý odchozí hovor“. Například Docker Sandboxy blokují HTTP/HTTPS, dokud nejsou explicitně povoleny, odříznou nezpracovaný TCP/UDP/ICMP a zakážou provoz do privátních IP rozsahů a localhost, pokud nenakonfigurujete výjimky. Cloudflare, Google a další navrhují své sandboxy tak, aby odchozí hovory procházely programovatelnými proxy, kde můžete vkládat autorizaci, filtrovat cíle a auditovat využití.

Za čtvrté, hranice přihlašovacích údajů: zveřejnění nezpracovaných tajných dat uvnitř sandboxu by mělo být považováno za poslední možnost, nikoli za výchozí nastavení. Dockerův design směruje HTTP volání přes proxy na straně hostitele, která může k požadavkům připojovat tokeny nebo API klíče, aniž by tyto nezpracované hodnoty umisťovala do virtuálního počítače. Cloudflare sandboxy podobně vkládají přihlašovací údaje na síťové vrstvě, nikoli prostřednictvím proměnných prostředí. Tímto způsobem, i když prompt injection přesvědčí agenta, aby „vypsal všechny proměnné prostředí“, není nic zajímavého k ukrást.

Za páté, hranice životního cyklu: pracovní prostory agentů zřídka existují pro jediný příkaz; potřebují explicitní sémantiku pro spuštění, pozastavení, snapshot, fork a teardown. E2B zpřístupňuje izolované souborové systémy, příkazy na pozadí a svazky, které mohou přežít i po uplynutí životnosti jednoho sandboxu. Freestyle se zaměřuje na velmi rychlé spouštění, pozastavení a obnovení virtuálních strojů s vytvářením snímků a větvením stavu v paměti. Daytona přidává sandboxy založené na snapshotech a také zásady automatického zastavení, automatické archivace a automatického mazání, takže můžete některá prostředí udržovat dlouhodobě fungující a jiná považovat za jednorázová.

Jakmile si uvědomíte těchto pět os – souborový systém, proces, síť, přihlašovací údaje a životní cyklus – můžete jakoukoli stránku sandboxového produktu chápat jako sérii kompromisů. Kontejner se sdíleným jádrem s velkým připojením hostitele, ale přísnými pravidly pro odchozí procesy, se velmi liší od mikrovirtuálního počítače (microVM) bez připojení hostitele, ale s permisivnější sítí. Pro kódovací agenty, kteří potřebují instalovat závislosti, spouštět prohlížeče nebo vytvářet obrazy Dockeru, bývají silnější hranice ve stylu virtuálního počítače bezpečnější výchozí nastavení.

Sandboxing v systémech macOS, Linux a Windows pro lokální kódovací agenty

Na vývojářských noteboocích nelze vždycky spustit náročné sandboxy microVM, takže týmy musely být kreativní s nativní izolací operačního systému. Nedávná práce Cursoru na lokálních sandboxech je dobrým příkladem přizpůsobení specifikům macOS, Linuxu a Windows při zachování jednotného API pro vrstvu agenta.

V systému macOS bylo vyhodnoceno několik možností: App Sandbox, generické kontejnery, plnohodnotné virtuální stroje a dlouhodobě fungující, ale „zastaralá“ technologie s názvem Seatbelt. Aplikační sandbox by vyžadoval podepsání každého binárního souboru, který by agent mohl spustit, což by dramaticky zvyšovalo složitost a dokonce by generovaným binárním souborům udělovalo tranzitivní důvěryhodnost. Linuxové kontejnery by nutily uživatele macOS používat pouze linuxové binární soubory a plnohodnotné virtuální počítače by měly nepřijatelnou latenci spouštění a paměťovou režii pro interaktivní kódovací toky.

Bezpečnostní pás, přístupný přes sandbox-exec, se nakonec i přes svůj věk ukázal jako pragmatická volba. Umožňuje spustit příkaz v profilu sandboxu, který omezuje celý strom procesů pomocí detailního jazyka zásad: můžete přidat na bílou listinu nebo blokovat konkrétní systémová volání a omezit oprávnění ke čtení/zápisu na cílové soubory nebo adresáře. Cursor generuje tyto zásady dynamicky za běhu na základě nastavení pracovního prostoru a administrátora a také na základě nastavení uživatele. .cursorignore, takže ignorované cesty se v rámci sandboxu stanou tabu.

V Linuxu jádro zpřístupňuje správné primitivy – seccomp pro filtrování systémových volání a Landlock pro omezení souborového systému – ale kompozici ponechává na uživatelském prostoru. Spíše než spoléhat se na existující OSS wrappery, které nepodporovaly ignorování specifických pro repozitáře, jako například .cursorignoreCursor se rozhodl přímo řídit Landlock a seccomp. Seccomp zakazuje nebezpečná systémová volání; Landlock vynucuje pravidla pro čtení/zápis založená na cestách a dokonce jim umožňuje překrývat pracovní prostory uživatelů, takže ignorované soubory jsou zcela nepřístupné nebo nahrazeny chráněnými kopiemi, které procesy v sandboxu nemohou číst ani upravovat.

Jednou z jemností v Linuxu je výkon: opětovné připojení nebo přepsání všech ignorovaných souborů je nejpomalejší částí nastavení sandboxu. Odložené filtrování ve stylu macOS, které dokáže vidět přesnou cestu k souboru v době systémového volání, by to zjednodušilo, ale Linuxový seccomp-bpf tuto kontrolu cesty neusnadňuje, takže je zde skutečný technický kompromis mezi těsnou izolací a rychlostí spouštění.

Ve Windows zůstává vytvoření skutečně ekvivalentního nativního sandboxu obtížnější, protože většina izolačních primitiv je optimalizována pro prohlížeče a nikoli pro univerzální vývojářské nástroje. Cursor v současné době provozuje Linuxový sandbox uvnitř WSL2 pro uživatele Windows, v podstatě se tak doplňuje o izolaci Linuxu, dokud nebudou k dispozici bohatší primitiva. Spolupracují s Microsoftem na zpřístupnění správných funkcí, aby si agenti Windows časem mohli užívat prvotřídního nativního sandboxu bez WSL jako berličky.

Společným prvkem všech těchto přístupů specifických pro operační systém je sjednocené API pro sandbox. Z pohledu agenta existuje pouze „shellový nástroj“ s jasnými funkcemi a pravidly. V rámci něj se tato pravidla v rámci Seatbelt, Landlock/seccomp nebo izolace založená na WSL2 vynucují odlišně v závislosti na platformě.

Učení agentů porozumět a respektovat sandbox

Sandbox je užitečný pouze tehdy, pokud agent dokáže předvídat, co bude v něm fungovat a kdy je potřeba eskalovat oprávnění nebo opustit sandbox. To zní samozřejmě, ale v praxi to vyžadovalo překvapivě důkladné iterace návrhu výzev a nástrojů od dodavatelů, kteří dodávali kódovací agenty.

Prvním krokem, který mnoho týmů podniklo, bylo vylepšení popisů nástrojů, zejména pro provádění shellu. Místo obecného nástroje „run_shell_command“ popis explicitně uvádí, jaké zdroje jsou přístupné: zda má příkaz přístup k souborovému systému, přístup k Gitu, přístup k síti nebo plně offline prostředí v závislosti na konfiguraci uživatele. Také dokumentuje, jak může agent v případě potřeby požádat o zvýšená práva (například pro přístup k veřejnému internetu). Tato rychlá inženýrská práce bývá velmi empirická: týmy spouštějí běžné postupy nasazení, pozorují, kde model nesprávně předpovídá možnosti, upravují popisy nástrojů a opakují.

Interní benchmarky jako „Cursor Bench“ nebo podobné eval sady se pak používají k porovnání výkonu agentů s a bez sandboxu. Jeden z prvních způsobů selhání byl velmi konzistentní: agent slepě opakoval stejný selhávající příkaz terminálu znovu a znovu, místo aby si uvědomil, že narazil na omezení sandboxu. Bez jasného signálu o tom, proč příkaz selhal, se model nedokázal naučit vzorec.

Oprava spočívala v explicitním zobrazování chyb sandboxu ve výstupech nástroje, často s narážkou na to, co dělat dál. Když byl příkaz blokován kvůli pravidlu souborového systému nebo sítě, nástroj shell začal zobrazovat krátké vysvětlení, například „blokováno sandboxem: odchozí přístup k síti pro tuto relaci zakázán“ a v některých případech i nápovědu, že agent může požádat o zvýšená oprávnění. Po této změně se agenti stali mnohem odolnějšími: přestali se opakovat u beznadějných příkazů a buď upravili svůj plán, nebo si vyžádali potřebnou funkcionalitu.

Offline hodnocení jsou užitečná, ale vypovídají jen část příběhu. Aby týmy skutečně zjistily, zda sandbox zhoršuje uživatelský zážitek, postupně zaváděly podporu sandboxu v produkčním prostředí a sledovaly míru chyb, doby dokončení a kanály zpětné vazby. V praxi dodavatelé uvádějí, že značná část dotazů na kompatibilních platformách nyní běží plně uvnitř sandboxů – přičemž podnikoví zákazníci, jako je NVIDIA, patří mezi první uživatele – a že agenti v sandboxu se v reálných pracovních postupech pozastavují pro schválení přibližně o 40 % méně často, což šetří hodiny ruční kontroly a zároveň snižuje riziko.

Do budoucna je velký zájem o „nativní sandboxové agenty“ – modely trénované přímo na omezeních svého prostředí. Místo toho, aby tito agenti vnímali shell, prohlížeč nebo souborový systém jako abstraktní nástroje, chápali by, že žijí v úzce vymezeném běhovém prostředí, mohou psát skripty a programy s dlouhou životností a musí respektovat okrajové podmínky, jako například „žádná odchozí síť“ nebo „pracovní prostor je pouze pro čtení“. Toto školení by je mohlo mnohem lépe naučit plánovat bezpečné a efektivní sekvence akcí, aniž by naráželi na neviditelné zdi.

Cloudové sandboxy: Cloudflare, Google Cloud, Heroku a další

Kromě vývojářských notebooků se velká vlna poskytovatelů infrastruktury předhánějí v nabídce hostovaných sandboxů vyladěných speciálně pro agenty s umělou inteligencí. Jejich cíle jsou stejné – izolace, kontrola a výkon – ale kompromisy vypadají v cloudovém měřítku trochu jinak.

Sandboxy Cloudflare, postavené na kontejnerech Cloudflare a nyní všeobecně dostupné, mají za cíl vypadat a fungovat jako plnohodnotná vývojová prostředí pro agenty. Každý sandbox je trvalý, izolovaný pracovní prostor, který oslovujete jménem. Pokud je v režimu spánku, spustí se na vyžádání; pokud je nečinný, automaticky se pozastaví, aby se ušetřil výpočetní výkon, a obnoví se při dalším požadavku. Vývojáři (nebo agenti) s ním mohou interagovat pomocí typových metod, jako je exec, gitCheckout, writeFilea další, pomocí sady SDK pro JavaScript/TypeScript.

Jedním z nejzáludnějších cloudových problémů je bezpečné ověřování z prostředí agentů. Agenti často potřebují kontaktovat soukromé služby, ale nechcete, aby se v proměnných prostředí povalovaly nezpracované přihlašovací údaje. Cloudflare vkládá přihlašovací údaje na vrstvu síťové proxy a mapuje odchozí požadavky hostitele na vlastní logiku, která připojuje tokeny z zabezpečeného úložiště. Proces sandboxu nikdy nevidí skutečné tajemství, ale volání je stále ověřováno. Tento návrh podporuje dynamické vkládání přihlašovacích údajů s ohledem na identitu a dobře spolupracuje s vazbami Workerů.

Pro pracovní postupy s vysokou mírou využití terminálu přidal Cloudflare plnohodnotné rozhraní PTY (pseudo-terminál) propojené přes WebSockets a xterm.js. Agenti a lidé mohou otevírat relace živého shellu, přerušovat procesy, znovu se připojovat a přehrávat minulý výstup. Každý PTY má svůj vlastní pracovní adresář a prostředí a výstup je ukládán do vyrovnávací paměti na serveru, aby znovu se připojující klienti mohli dohnat zmeškané protokoly.

Kromě přístupu k raw shellu nabízí Cloudflare také perzistentní „kontexty pro spuštění kódu“ pro jazyky jako Python, JavaScript a TypeScript. Na rozdíl od mnoha spouštěčů úryvků, které spouštějí každý fragment izolovaně, tyto kontexty uchovávají proměnné, importy a stavy napříč voláními, podobně jako poznámkový blok Jupyter. Agenti mohou načítat data v jednom volání, transformovat je v jiném a vykreslovat grafy nebo tabulky HTML, aniž by museli neustále vše znovu analyzovat a importovat.

Pro úkoly webového vývoje podporují sandboxy Cloudflare procesy na pozadí, kontroly stavu a URL adresy pro živé náhledy. Agent může začít npm run dev jako úloha na pozadí sledujte protokoly, dokud server není připraven, a poté zpřístupněte port za veřejnou URL adresou náhledu. Metody jako waitForPort() or waitForLog() nechte agenty sekvenovat akce na základě skutečných signálů připravenosti namísto naivních sleep(2s) dohady.

Pracovní postupy řízené událostmi získávají podporu díky primitivům pro sledování souborů, které jsou podporovány mechanismem inotify v Linuxu. Agent se může přihlásit k odběru změn v rámci /workspace/src a automaticky znovu spustit testy nebo sestavení při úpravě souborů TypeScript. Jedná se o stejnou zpětnovazební smyčku, na kterou se spoléhají lidští vývojáři, ale je nativní pro agenty prostřednictvím API, jako je sandbox.watch() a streamy událostí odesílaných serverem.

Aby se uzavřela smyčka životního cyklu, Cloudflare zavádí skutečné snapshoty – zachycení stavu na úrovni virtuálních počítačů, které lze obnovit během několika sekund z úložiště R2. Snímky uchovávají stav souborového systému, konfiguraci operačního systému, nainstalované závislosti a datové soubory; budoucí verze také obnoví stav aktivní paměti pro okamžité obnovení. Agenti (nebo orchestratoři) mohou programově spouštět snímky pro kontrolní body nebo scénáře větvení a poté ze stejného snímku vytvořit více sandboxů, aby mohli izolovaně prozkoumávat paralelní hypotézy.

Co se týče cen, Cloudflare přešel na model „pouze aktivního CPU“: účtují se vám skutečně použité cykly CPU, nikoliv doba nečinnosti, kdy agenti čekají na LLM. V kombinaci s obrovskými limity souběžnosti pro „lite“ a větší instance to umožňuje provozovat velkou flotilu agentů, aniž by se vynakládaly peníze na nečinné kontejnery.

Sandbox agentů GKE od Google Cloudu je naopak hluboce integrován s Kubernetes a gVisor. Myšlenka je umožnit vám spouštět úlohy agentů v izolovaných podech uvnitř vašich vlastních clusterů. Vytvoříte cluster GKE (Autopilot může gVisor povolit automaticky, zatímco standardní clustery potřebují explicitní běhové třídy a fondy uzlů s povoleným gVisorem) a poté nasadíte kontroler Agent Sandbox prostřednictvím verzovaných manifestů.

Model je poháněn dvěma základními vlastními zdroji: SandboxTemplate a SandboxWarmPool. SandboxTemplate funguje jako opakovaně použitelný plán, který specifikuje šablonu podu (image, porty, zdroje, runtimeClassName: gvisoratd.) pro sandboxové běhové prostředí, jako je například prostředí Pythonu. SandboxWarmPool Udržuje nakonfigurovaný počet předehřátých podů připravených k téměř okamžitému vyzvednutí, čímž se zabrání studeným startům, když agent potřebuje čerstvé prostředí za méně než sekundu.

A Sandbox Router Služba pak funguje jako brána pro provoz mezi klienty a těmito izolovanými pody. Ve vývoji můžete tunelovat provoz skrz kubectl port-forward bez odhalování veřejných IP adres. V produkčním prostředí byste obvykle routeru poskytli správný ingress a mTLS. Na straně klienta Google poskytuje knihovnu Pythonu „Agentic Sandbox“, která pokrývá celý životní cyklus: vytvoří deklaraci sandboxu ze šablony, počkejte, až bude připravena, spusťte příkazy shellu a po dokončení vyčistěte.

To vše je pod kapotou stále „jen Kubernetes“, ale zabalené do uceleného příběhu pro běhové prostředí agentů. gVisor poskytuje izolaci procesů a systémových volání, SandboxTemplate standardizuje konfigurace, WarmPool řeší latenci spouštění a router a klient Python usnadňují práci s aplikacemi zaměřenými na LLM.

Heroku se na druhou stranu opírá o velmi vyspělý stavební kámen: jednorázové dynamometrie. Uživatelé Heroku po léta spouštěli ad hoc úlohy – migrace, skripty údržby, administrativní úkoly – v dočasných dynamatech, které se spouštěly na vyžádání a po dokončení zanikaly. Heroku tuto infrastrukturu znovu využilo jako sandboxy pro provádění kódu, které byly spuštěny společně se svými nabídkami Managed Inference a Agents. Agent píše úryvky kódu pro Python, Ruby, Node nebo Go; Heroku je spouští uvnitř krátkodobých dynamometrů a streamuje výsledky zpět, čímž omezuje poloměr BLASTu na dočasný kontejner.

K těmto sandboxům můžete přistupovat buď prostřednictvím vestavěných nástrojů v Heroku Agents API, nebo nasazením open-source serverů Model Context Protocol (MCP). Servery MCP zpřístupňují standardizované koncové body nástrojů, takže klienti jako Agentforce, Claude Desktop nebo Cursor mohou sandbox Heroku považovat za generický backend pro vzdálené spuštění kódu. Každý server podporuje omezení specifická pro běhové prostředí (například max_calls na smyčku agenta), aby se zabránilo tomu, aby se agenti otáčeli v těsných a nákladných smyčkách.

Deep Agents od LangChainu přidávají další rozměr integrací s poskytovateli sandboxových řešení třetích stran, jako jsou Runloop, Daytona a Modal. Vzorec je přímočarý: Deep Agent běží, kdekoli chcete (lokálně nebo v cloudu), ale kdykoli potřebuje spustit příkazy, vytvořit soubory nebo kód, jsou tyto operace přesměrovány do vzdáleného sandboxu. Instalační skripty mohou předem načíst proměnné prostředí, klonovat repozitáře, instalovat nástroje a další, takže každý agent získá čisté a kontrolované prostředí. Správci kontextu pak řeší vytváření a čištění, ačkoli dokumentace důrazně doporučuje monitorovat dashboardy poskytovatelů, zda neobsahují nějaké zapomenuté dlouhodobě běžící sandboxy.

Výkon, stav a větvení: proč je pro agenty důležitá rychlost

Pomalý, ale ultra bezpečný sandbox bude v praxi obcházen; vývojářské nástroje žijí, nebo zemřou v závislosti na latenci. Programátoři se nechovají jako noční dávkové úlohy. Spouštějí interaktivní smyčky: čtou kód, navrhují úpravy, spouštějí testy, analyzují protokoly, volají nástroje, čekají na lidi a pak vše opakují. V reálných relacích také prozkoumávají více větví problému, některé cesty opouštějí a k jiným se vracejí později.

Proto se platformy jako Freestyle posedle zaměřují na kratší dobu životního cyklu virtuálních strojů než v sekundách a bohatou sémantiku stavů. Jejich virtuální počítače jsou plnohodnotné linuxové stroje s root přístupem, službami systemd, podporou vnořené virtualizace a plnou síťovou podporou. Dokumentace uvádí, že zprovoznění od volání API po spuštění virtuálního počítače trvá méně než 800 ms, pozastavení/obnovení za méně než 100 ms a že je možné pořizovat snímky nebo forkovat virtuální počítače během provádění s minimálním dopadem na výkon. Jako příjemce explicitně uvádějí stav prohlížeče: pokud agent uvede prohlížeč do zajímavého stavu, může tento virtuální počítač 20krát forknout ze stejného snapshotu, místo aby tento stav znovu vytvořil od nuly.

SandboxWarmPool od Googlu pro GKE vyjadřuje stejnou myšlenku v terminologii Kubernetes: udržovat pool předehřátých podů, aby agenti neplatili plné sankce za studený start za každý nový běh. Pracovní prostory Daytony založené na snímcích a zásady automatického zastavení/archivace/mazání ladí životní cyklus pro různé typy relací: aktivní vývojová prostředí, dočasné experimenty a dlouhodobé základní stavy.

Důraz E2B na úlohy na pozadí, sledovatelné adresáře, izolované souborové systémy a opakovaně použitelné svazky je druhou stranou téže mince. Díky těmto funkcím může agent udržovat vývojový server nebo testovací systém v chodu a zároveň prozkoumávat změny kódu, nebo sdílet trvalý svazek napříč několika dočasnými sandboxy v průběhu času. Bez toho agenti nakonec spouštějí jednorázové příkazy a ztrácejí kontext, což snižuje produktivitu.

Užitečným způsobem, jak vyhodnotit práci agentů v jakémkoli sandboxu, je položit několik jasných otázek. Mohu spustit nové prostředí za méně než sekundu? Mohu čistě ukládat a obnovovat stav, včetně částečných sestavení nebo relací prohlížeče? Mohu rozdělit stav pro paralelní prozkoumávání? Mohu zachovat dlouhodobé, ale efektivní pracovní prostory pro postupy „vraťte se později“? Čím více odpovědí „ano“ dostanete, tím více se vaši agenti mohou chovat jako skuteční inženýři, nikoli jako bezstavoví spouštěči skriptů.

Tajemství, síťové zásady a důvěryhodnost pracovního prostoru jako skutečná řídicí rovina

I s dokonalou izolací hostitele je snadné vytvořit nezabezpečený systém, pokud ignorujete tajné kódy, síťové zásady a důvěryhodnost pracovního prostoru. Dokumentace sandboxu v Dockeru je v tomto ohledu až osvěžující. microVM a jeho privátní Docker démon tvoří hlavní hranici důvěryhodnosti s hostitelem. Uvnitř tohoto virtuálního počítače má však agent plnou kontrolu nad servery root a sdílený pracovní prostor je připojen pro čtení i zápis. Ve výchozím nastavení se veškeré úpravy souborů okamžitě projeví na hostiteli. Síťový výstup je ve výchozím nastavení odepřen a povolen pouze na základě explicitních pravidel a HTTP požadavky používají proxy na straně hostitele, která může vkládat přihlašovací údaje, aniž by virtuálnímu počítači odhalovala nezpracované tajné informace.

To znamená, že izolace hostitele je pouze prvním krokem; stále musíte přemýšlet o tom, co může agent udělat s pracovním prostorem a okolním světem. Dokumentace Dockeru výslovně varuje, že pokud agent upraví skripty, lidé je později spustí – Git hooky, konfigurace CI, definice úloh IDE, Makefile cíle, package.json skripty – poškození se může „přenést“ zpět na hostitelský systém nebo systémy CI, když se tyto skripty spustí. Dokonce zdůrazňují, že Git se k nim připojuje. .git/ neobjevuj se v git diff, což usnadňuje tiché přetrvávání škodlivé logiky.

Proxy přihlašovacích údajů je výkonné, ale nenápadné. Dockerův odchozí proxy zajišťuje, že tajné údaje zůstanou mimo virtuální počítač, ale stále umožňuje agentovi jednat s použitím těchto identit proti povoleným hostitelům. Některé postupy – například zápis vlastních proměnných prostředí do souborů, jako například /etc/sandbox-persistent.sh – prolomte tuto hranici záměrným ukládáním tajných dat uvnitř virtuálního počítače, což je bezpečné pouze tehdy, pokud agentovi a sandboxu skutečně důvěřujete.

Rozsah konfigurace je stejně důležitý jako tajné kódy. V Dockerových FAQ se uvádí, že konfigurace na úrovni uživatele, jako například ~/.claude or ~/.codex na hostiteli se nekopírují do sandboxu; viditelná je pouze konfigurace v rozsahu projektu ve sdíleném pracovním prostoru. Konfigurační dokumentace Anthropicu zdůrazňuje, že nastavení na úrovni projektu – nástroje, oprávnění, MCP servery, hooky – přepisují nastavení na úrovni uživatele a jsou sdílena mezi týmy. Jinými slovy, jakékoli zásady, instrukce a pluginy, které připojíte k repozitáři, se stanou hlavní plochou, kterou agent vidí.

Pokyny k dovednostem od OpenAI zdůrazňují podobné body, ale v trochu jiné terminologii. Dovednosti (balíčky nástrojů) mohou představovat rizika úniku dat vyvolaného okamžitým vkládáním dat. Dokumentace varuje před přímým vystavením nekontrolovaného veřejného trhu s dovednostmi koncovým uživatelům, protože škodlivé soubory SKILL.md mohou přepsat zásady, spustit destruktivní akce nebo uniknout soukromá data. Doporučuje prověřovat dovednosti vývojářů, omezit je na konkrétní pracovní postupy, skrýt akce s vysokým dopadem za dodatečnými schváleními a kontrolami zásad a zacházet s dovednostmi jako se součástí vašeho modelu hrozeb.

Když se jednotlivé části spojí, „skutečná“ řídicí rovina pro agentské sandboxy se rozkládá na čtyřech vrstvách. Izolace hostitele chrání vaše počítače a uzly clusteru. Důvěra pracovního prostoru chrání budoucího člověka nebo CI, který bude spouštět soubory vytvořené uvnitř sandboxu. Síťová politika chrání externí systémy a soukromé zdroje dat. Správa přihlašovacích údajů chrání identity, jejichž prostřednictvím může agent jednat. Robustní návrh má odpovědi na všechny čtyři otázky, nejen na první.

Navíc stále potřebujete zdravou skepsi ohledně prompt injection a agent hijackingu. NIST, OWASP a OpenAI popisují varianty stejného vzorce: nedůvěryhodný vstup – soubor README, webová stránka, soubor protokolu – obsahuje škodlivé instrukce, které přesměrovávají chování agenta. Generování a jemné ladění s rozšířeným načítáním tento problém magicky nevyřeší. Dobře instrumentovaný sandbox a dobrá politika nemohou zabránit tomu, aby byl model oklamán, ale mohou dramaticky snížit nevýhody, pokud k nim dojde.

Cloudové platformy a běhová prostředí agentů začínají tyto poznatky kódovat. Tajné proxy, povolené odchozí domény, konfigurace s omezeným rozsahem repozitáře, subagenti s užšími možnostmi, schvalovací toky založené na hookech a reprodukovatelné sandboxy jsou všechno součásti stejné skládačky: akceptovat, že modely jsou omylné, a navrhnout prostředí tak, aby náklady na tuto omylnost zůstaly omezené.

V lokálních i cloudových prostředích lze spouštěcí sandbox pro agenty nejlépe chápat jako pečlivě nakreslenou hranici: model není díky němu chytřejší, ale jeho chyby jsou méně katastrofické a lépe pozorovatelné. Díky správné kombinaci ovládacích prvků souborového systému, procesů, sítě, tajných klíčů a životního cyklu a inteligentnímu učení agenta o jeho prostředí můžete nechat systémy umělé inteligence klonovat repozitáře, spouštět testy, spouštět prohlížeče a dokonce se dotýkat systémů podobných produkčním – aniž byste jim museli předávat klíče ke všemu, na čem vám záleží.

To znamená, že izolace hostitele je pouze prvním krokem; stále musíte přemýšlet o tom, co může agent udělat s pracovním prostorem a okolním světem, včetně riesgos como. vzdálené spuštění kódu. Dokumentace Dockeru výslovně varuje, že pokud agent upraví skripty, lidé je později spustí – Git hooky, konfigurace CI, definice úloh IDE, Makefile cíle, package.json skripty – poškození se může při spuštění těchto skriptů „přenést“ zpět na hostitelský systém nebo systémy CI.