- Izvršni sandboxovi definiraju stroge granice za datoteke, procese, mrežu i tajne tako da agenti za kodiranje mogu pokretati moćne operacije bez ugrožavanja hostova ili produkcijskih sustava.
- Moderne platforme kombiniraju OS primitive (Seatbelt, Landlock, gVisor, microVM-ovi) s apstrakcijama više razine poput snapshotsa, warm pool-ova, volumena i PTY-ova kako bi sandboxovi bili sigurni i brzi.
- Tajne, mrežne politike, povjerenje radnog prostora i obrana ubrizgavanjem prompta tvore pravu kontrolnu ravninu; sama izolacija hosta nije dovoljna za sigurno izvršavanje agenta.
- Oblačni i lokalni ekosustavi (Cloudflare, GKE, Heroku, Docker, Freestyle, E2B, Daytona, Cursor, LangChain) konvergiraju oko sandbox okruženja za izvršavanje kao zadanog načina pokretanja nepouzdanog koda generiranog od strane agenta.
Dopuštanje AI agentima da pokreću kod, dodiruju datoteke, otvaraju preglednike i koriste API-je pretvara ih iz otmjenog automatskog dovršavanja u nešto mnogo bliže mlađem inženjeru s root pristupom na računalu. Upravo ta dodatna moć je razlog zašto se osjećaju magično – i upravo razlog zašto mogu biti opasni. Nepravilno usklađen ili jednostavno agent s greškama može izbrisati bazu podataka, procuriti API ključ na internet ili implementirati neispravnu verziju u produkciju bez da stvarno „razumijeva“ što je pošlo po zlu.
Pravo pitanje više nije „koliko je model točan?“, već „što može postići kada je u krivu, prevaren ili previše samouvjeren?“. Izvršni sandboxovi za agente su inženjersko rješenje: usko ograničena okruženja u kojima agenti mogu čitati i pisati kod, pokretati ljuske, pokretati poslužitelje ili vrtjeti preglednike, dok vi strogo kontrolirate datotečne sustave, mrežu, vjerodajnice i životni ciklus. Umjesto da vjerujete modelu, ograničavate radijus eksplozije.
Zašto agentima za kodiranje treba namjenski sandbox za izvršavanje
Moderni agenti za kodiranje poput Claude Codea, LangChain Deep Agentsa, Dockerovih sandboxova za kodiranje i sličnih alata više se ne ponašaju kao jednostavni chatbotovi s pristupom datotekama. Oni čitaju cijele repozitorije, uređuju datoteke, pokreću naredbe ljuske, manipuliraju Gitom, pokreću Docker buildove, komuniciraju s vanjskim API-jima, pa čak i upravljaju potpunim okruženjima sličnim desktopu putem preglednika. Dokumentacija dobavljača je vrlo eksplicitna o tome: Claude Code je predstavljen kao agilni pomoćnik za razvoj koji može pregledati vašu kodnu bazu, unositi izmjene i pokretati naredbe; LangChain Deep Agents tretira sandbox backend kao mjesto gdje izvršavaju naredbe ljuske, upravljaju datotečnim sustavima i delegiraju posao podagentima za izolaciju.
Upravo taj skup mogućnosti čini ove agente korisnima – i operativno rizičnima. Nakon što se model može pokrenuti pytest, instalirati npm pakete, otvoriti grane ili otkloniti pogreške u izgradnji, samo je nekoliko poziva alata udaljeno od mijenjanja skripti za implementaciju, slanja oštećenih slika, podešavanja CI konfiguracija ili krađe tokena putem HTTP zahtjeva. OpenAI-jeve vlastite smjernice za sigurnost agenata i NIST-ov rad na otmici agenata naglašavaju prompt inject: zlonamjerne upute skrivene u datotekama, web stranicama ili zapisnicima mogu tiho usmjeriti agenta na radnje koje nikada niste namjeravali odobriti.
Mnogi timovi započinju s naivnim tokovima "traženja odobrenja" za svaku naredbu i brzo otkriju da se ne skaliraju. Anthropic je javno podijelio da su korisnici odobrili 93% Claude Codeovih upita za dopuštenja; Dockerov Claude sandbox čak pokreće Claude Code s --skip-permissions prema zadanim postavkama, oslanjajući se na izolaciju tijekom izvođenja umjesto na mnoštvo dijaloga. Ljudi osjećaju umor od odobravanja, posebno kada paralelno pokreću više agenata i mijenjaju kontekst u mnogim upitima. U tom trenutku, dijalozi za potvrdu postaju ceremonija, a ne pouzdana kontrola.
Izvršni sandbox mijenja sigurnosni model s „vjeruj korisniku da će pročitati svaki upit“ na „pretpostavi da će neke naredbe biti pogrešne ili suprotstavljene i ograniči štetu koju mogu prouzročiti“. Pješčanik postaje čvrsta granica oko datoteka, procesa, mreža i tajni koje agent može dodirnuti, čak i kada se njime manipulira brzim ubrizgavanjem ili jednostavno greškama.
Postoji i osnovni argument o odnosu programera i iskustva: agentima je potrebno dovoljno prostora za stvarni rad. Ako previše koristite sandbox s grubim ograničenjima, jednostavne naredbe poput izgradnje ili testiranja stalno ne uspijevaju zbog nejasnih pogrešaka u dopuštenjima. Najbolji sustavi, poput onih koje je Cursor implementirao na macOS/Linux/Windows ili Cloudflare, Heroku i Google Cloud za hostana opterećenja, imaju za cilj dati agentima osjećaj "pravog računala" unutar uskog perimetra.
Što izvršni sandbox za agente zapravo izolira
Pravi agentski sandbox nije samo „negdje drugdje za izvršavanje koda“ – to je skup eksplicitnih granica koje definiraju radijus eksplozije. Možete zamisliti pet glavnih ograničenja koja se iznova i iznova pojavljuju na vodećim platformama poput Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B ili Daytona.
Prvo, granica datotečnog sustava: agent bi trebao vidjeti samo radni prostor koji namjerno dijelite. LangChainova dokumentacija definira sandbox kao barijeru koja agente drži podalje od datoteka hosta; Dockerov sandbox model je kristalno jasan da microVM vidi samo eksplicitno montirani direktorij projekta. Sve izvan tog stabla je nevidljivo ili samo za čitanje, tako da agent ne može slučajno čitati. ~/.ssh ili prepisati konfiguracije sustava.
Drugo, granica procesa i jezgre: radna opterećenja agenata ne bi trebala dijeliti sirovu jezgru hosta ili tablicu procesa. Dockerova sandbox arhitektura izolira svako okruženje u vlastitu microVM i Linux kernelFirecracker (koji u "interface" koristi nekoliko pružatelja usluga) tretira tu granicu virtualnog stroja kao prvi sloj izolacije, a zatim dodaje seccomp, namespaces, cgroups i ograničenja slična jailu. Googleov GKE Agent Sandbox postiže sličan učinak unutar Kubernetesa pomoću gVisora: sloj "sentry" presreće sistemske pozive i posreduje u pristupu temeljnom čvoru.
Treće, granica mreže: bez mrežne politike, agent u sandboxu je i dalje stroj za izvlačenje podataka. Većina ozbiljnih platformi sada se isporučuje s zadanim postavkama "zabrani sav izlaz". Docker Sandboxovi, na primjer, blokiraju HTTP/HTTPS dok se izričito ne dopusti, prekidaju sirovi TCP/UDP/ICMP i ne dopuštaju promet prema privatnim IP rasponima i localhostu osim ako ne konfigurirate iznimke. Cloudflare, Google i drugi dizajniraju svoje sandboxove tako da odlazni pozivi prolaze kroz programabilne proxyje gdje možete ubrizgati autorizaciju, filtrirati odredišta i revidirati korištenje.
Četvrto, granica vjerodajnica: otkrivanje sirovih tajni unutar sandboxa treba tretirati kao krajnju mjeru, a ne kao zadanu mjeru. Dockerov dizajn usmjerava HTTP pozive putem proxyja na strani hosta koji može priložiti tokene ili API ključeve zahtjevima bez postavljanja tih sirovih vrijednosti unutar virtualnog stroja. Cloudflare Sandboxovi slično ubrizgavaju vjerodajnice na mrežnom sloju, a ne putem varijabli okruženja. Na taj način, čak i ako prompt injection uvjeri agenta da "ispiše sve varijable okruženja", nema ništa sočno za ukrasti.
Peto, granica životnog ciklusa: radni prostori agenata rijetko žive za jednu naredbu; potrebna im je eksplicitna semantika za pokretanje, pauziranje, snimanje, fork i teardown. E2B otkriva izolirane datotečne sustave, pozadinske naredbe i volumene koji mogu preživjeti dulje od jednog životnog vijeka sandboxa. Freestyle se fokusira na vrlo brzo pokretanje, obustavljanje i nastavak rada virtualnog stroja sa snimkama i grananjem stanja u memoriji. Daytona dodaje sandboxove temeljene na snimkama plus pravila automatskog zaustavljanja, automatskog arhiviranja i automatskog brisanja tako da možete dugo održavati neka okruženja, a druga tretirati kao jednokratna.
Nakon što vidite ovih pet osi – datotečni sustav, proces, mrežu, vjerodajnice i životni ciklus – možete bilo koju stranicu sandbox proizvoda protumačiti kao niz kompromisa. Kontejner s dijeljenom jezgrom i velikim montiranjem hosta, ali strogim pravilima izlaza, vrlo se razlikuje od microVM-a bez montiranja hosta, ali s dopustivijom mrežom. Za programere koji trebaju instalirati ovisnosti, pokretati preglednike ili izrađivati slike Dockera, jače granice u stilu VM-a obično su sigurnija zadana postavka.
Sandboxing na macOS-u, Linuxu i Windowsu za lokalne programerske agente
Na prijenosnim računalima za razvojne programere nije uvijek moguće pokrenuti teške microVM sandboxove, pa su timovi morali biti kreativni s izolacijom temeljenom na operativnom sustavu. Cursorov nedavni rad na lokalnim sandboxima dobar je primjer prilagođavanja specifičnostima macOS-a, Linuxa i Windowsa uz zadržavanje jedinstvenog API-ja za sloj agenta.
Na macOS-u je procijenjeno nekoliko opcija: App Sandbox, generički kontejneri, potpuni virtualni strojevi i dugovječna, ali „zastarjela“ tehnologija pod nazivom Seatbelt. App Sandbox bi zahtijevao potpisivanje svake binarne datoteke koju bi agent mogao izvršiti, što bi dramatično povećalo složenost, pa čak i dodijelilo generiranim binarnim datotekama tranzitivno povjerenje. Linux kontejneri bi prisilili korisnike macOS-a da koriste samo Linux binarne datoteke, a potpuno razvijeni virtualni strojevi imali bi neprihvatljivu latenciju pokretanja i memorijsko opterećenje za interaktivne tokove kodiranja.
Sigurnosni pojas, pristup putem sandbox-exec, na kraju se pokazao kao pragmatičan izbor unatoč svojim godinama. Omogućuje vam pokretanje naredbe u profilu sandboxa koji ograničava cijelo stablo procesa preciznim jezikom pravila: možete staviti na bijelu listu ili blokirati određene sistemske pozive i ograničiti dozvole za čitanje/pisanje na ciljane datoteke ili direktorije. Cursor dinamički generira ova pravila tijekom izvođenja na temelju postavki radnog prostora i administratora te korisničkih postavki. .cursorignore, tako da ignorirani putevi postaju zabranjeni unutar sandboxa.
Na Linuxu, kernel otkriva prave primitive – seccomp za filtriranje sistemskih poziva i Landlock za ograničenja datotečnog sustava – ali kompoziciju ostavlja korisničkom prostoru. Umjesto oslanjanja na postojeće OSS omotače koji nisu podržavali ignoriranja specifična za repozitorij, poput .cursorignoreCursor je odlučio izravno orkestrirati Landlock i seccomp. Seccomp zabranjuje opasne sistemske pozive; Landlock provodi pravila čitanja/pisanja temeljena na putanjama, čak im dopuštajući da prekrivaju korisničke radne prostore tako da su ignorirane datoteke potpuno nedostupne ili zamijenjene zaštićenim kopijama koje procesi u sandboxu ne mogu čitati ili mijenjati.
Jedna suptilnost na Linuxu su performanse: ponovno montiranje ili prepisivanje svih ignoriranih datoteka najsporiji je dio postavljanja sandboxa. Odgođeno filtriranje u macOS stilu koje može vidjeti točnu putanju datoteke u vrijeme sistemskog poziva bi to pojednostavilo, ali Linuxov seccomp-bpf ne olakšava tu inspekciju putanje, pa postoji pravi inženjerski kompromis između čvrste izolacije i brzine pokretanja.
Na Windowsima je izgradnja doista ekvivalentnog izvornog sandboxa i dalje teža jer je većina izolacijskih primitiva optimizirana za preglednike, a ne za općenite razvojne alate. Cursor trenutno pokreće Linux sandbox unutar WSL2 za Windows korisnike, u biti koristeći Linux izolaciju dok ne postanu dostupni bogatiji primitivi. Surađuju s Microsoftom kako bi otkrili prave mogućnosti kako bi s vremenom Windows agenti mogli uživati u prvoklasnom, izvornom sandboxu bez WSL-a kao potpore.
Zajednička nit svih ovih pristupa specifičnih za operativni sustav je objedinjeni sandbox API na vrhu. S gledišta agenta, postoji samo „ljuskasti alat“ s jasnim mogućnostima i pravilima. Ispod haube, Seatbelt, Landlock/seccomp ili izolacija temeljena na WSL2 provode ta pravila različito ovisno o platformi.
Učenje agenata da razumiju i poštuju sandbox
Pješčanik pomaže samo ako agent može predvidjeti što će unutar njega funkcionirati i kada treba eskalirati privilegije ili napustiti okvir. To zvuči očito, ali u praksi je zahtijevalo iznenađujuće duboku iteraciju prompta i dizajna alata za dobavljače koji isporučuju agente za kodiranje.
Prvi korak koji su mnogi timovi poduzeli bio je poboljšanje opisa alata, posebno za izvršavanje ljuske. Umjesto generičkog alata „run_shell_command“, opis eksplicitno navodi koji su resursi dostupni: ima li naredba pristup datotečnom sustavu, Gitu, mreži ili potpuno izvanmrežno okruženje, ovisno o konfiguraciji korisnika. Također dokumentira kako agent može zatražiti povišena prava (na primjer, za pristup javnom internetu) kada je to potrebno. Ovaj brzi inženjerski rad obično je vrlo empirijski: timovi pokreću uobičajene tokove implementacije, promatraju gdje model pogrešno predviđa mogućnosti, prilagođavaju opise alata i ponavljaju.
Interni kriteriji poput „Cursor Bench“ ili sličnih evaluacijskih paketa zatim se koriste za usporedbu performansi agenata sa i bez sandboxinga. Jedan od ranih načina kvara bio je vrlo dosljedan: agent bi naslijepo ponavljao istu neuspjelu terminalnu naredbu iznova i iznova umjesto da shvati da nailazi na ograničenje sandboxa. Bez jasnog signala o tome zašto je naredba neuspjela, model nije mogao naučiti obrazac.
Rješenje je bilo eksplicitno prikazivanje pogrešaka sandboxa u izlazima alata, često uz podsjetnik što učiniti sljedeće. Kada je naredba bila blokirana zbog pravila datotečnog sustava ili mreže, alat ljuske počeo je uključivati kratko objašnjenje poput „blokirano sandboxom: izlazni mrežni pristup onemogućen za ovu sesiju“ i, u nekim slučajevima, naznaku da agent može zatražiti povišena dopuštenja. Nakon ove promjene, agenti su postali mnogo otporniji: prestali su se ponavljati na beznadnim naredbama i ili su prilagodili svoj plan ili zatražili potrebnu mogućnost.
Offline evaluacije su korisne, ali one govore samo dio priče. Kako bi se doista znalo narušava li sandbox korisničko iskustvo, timovi su postupno uvodili podršku za sandbox u produkciji i pratili stope pogrešaka, vrijeme dovršetka i kanale povratnih informacija. U praksi, dobavljači izvještavaju da se znatan udio upita na kompatibilnim platformama sada u potpunosti izvršava unutar sandboxa - s poslovnim korisnicima poput NVIDIA-e među prvima koji su ga usvojili - i da agenti u sandboxu zapravo pauziraju za odobrenje oko 40% rjeđe u stvarnim tijekovima rada, štedeći sate ručnog pregleda uz smanjenje rizika.
Gledajući u budućnost, postoji veliki interes za „izvorne agente u sandboxu“ – modele obučene izravno na ograničenjima svog okruženja. Umjesto da tretiraju ljusku, preglednik ili datotečni sustav kao apstraktne alate, ovi agenti bi razumjeli da žive u usko ograničenom okruženju izvođenja, mogu pisati dugotrajne skripte i programe te moraju poštivati granične uvjete poput „nema izlazne mreže“ ili „radni prostor je samo za čitanje“. Ta bi ih obuka mogla učiniti puno boljim u planiranju sigurnih i učinkovitih nizova radnji bez udaranja o nevidljive zidove.
Cloud sandboxovi: Cloudflare, Google Cloud, Heroku i drugi
Izvan prijenosnih računala programera, veliki val pružatelja infrastrukture utrkuje se u ponudi hostiranih sandboxova posebno podešenih za AI agente. Njihovi ciljevi su isti – izolacija, kontrola i performanse – ali kompromisi izgledaju malo drugačije na razini oblaka.
Cloudflare sandboxovi, izgrađeni na Cloudflare kontejnerima i sada općenito dostupni, imaju za cilj izgledati i djelovati kao potpuna razvojna okruženja za agente. Svaki sandbox je trajni, izolirani radni prostor kojem se obraćate po imenu. Ako je u stanju mirovanja, pokreće se na zahtjev; ako je u stanju mirovanja, automatski se obustavlja radi uštede računalstva i nastavlja s radom pri sljedećem zahtjevu. Razvojni programeri (ili agenti) mogu s njim komunicirati putem tipiziranih metoda kao što su exec, gitCheckout, writeFilei više, pomoću JavaScript/TypeScript SDK-a.
Jedan od najtežih problema u oblaku je sigurna autentifikacija unutar agentskih sandboxova. Agenti često trebaju pristupiti privatnim servisima, ali ne želite da se sirovi podaci za prijavu nalaze u varijablama okruženja. Cloudflare ubrizgava podatke za prijavu na sloj mrežnog proxyja, mapirajući odlazne zahtjeve hosta na prilagođenu logiku koja prilaže tokene iz sigurne pohrane. Proces sandboxa nikada ne vidi prave tajne, ali poziv se i dalje autentificira. Ovaj dizajn podržava dinamičko ubrizgavanje podataka za prijavu koji je svjestan identiteta i dobro se slaže s Workers vezama.
Za radne procese koji zahtijevaju puno terminala, Cloudflare je dodao potpuno PTY (pseudo-terminalno) iskustvo povezano preko WebSocketsa i xterm.js-a. Agenti i ljudi mogu otvarati sesije žive ljuske, prekidati procese, ponovno se povezivati kasnije i reproducirati prošli izlaz. Svaki PTY ima svoj radni direktorij i okruženje, a izlaz se pohranjuje u međuspremnik na poslužitelju tako da ponovno povezani klijenti mogu nadoknaditi propuštene zapise.
Uz pristup sirovoj ljusci, Cloudflare također nudi trajne "kontekste izvršavanja koda" za jezike poput Pythona, JavaScripta i TypeScripta. Za razliku od mnogih isječaka koji izvršavaju svaki fragment zasebno, ovi konteksti čuvaju varijable, uvoze i stanje u svim pozivima, slično kao Jupyter bilježnica. Agenti mogu učitati podatke u jednom pozivu, transformirati ih u drugom i prikazati grafikone ili HTML tablice bez stalnog ponovnog parsiranja i ponovnog uvoza svega.
Za zadatke web razvoja, Cloudflare sandboxovi podržavaju pozadinske procese, provjere ispravnosti i URL-ove za pregled uživo. Agent može započeti npm run dev kao pozadinski posao, prati zapisnike dok poslužitelj ne bude spreman, a zatim izloži port iza javnog URL-a za pregled. Metode poput waitForPort() or waitForLog() neka agenti sekvenciraju akcije na temelju stvarnih signala spremnosti umjesto naivnih sleep(2s) nagađanja.
Tijekovi rada vođeni događajima dobivaju poticaj od primitiva za praćenje datoteka koje podržava Linuxov mehanizam inotify. Agent se može pretplatiti na promjene pod /workspace/src i automatski ponovno pokrenuti testove ili verzije kada se TypeScript datoteke modificiraju. Ovo je ista petlja povratnih informacija na koju se oslanjaju ljudski programeri, ali napravljena za agente putem API-ja poput sandbox.watch() i tokove događaja poslanih s poslužitelja.
Kako bi se zatvorila petlja životnog ciklusa, Cloudflare uvodi prave snimke stanja – snimke stanja na razini virtualnog stroja koje se mogu vratiti u sekundama iz R2 pohrane. Snimke pohranjuju stanje datotečnog sustava, konfiguraciju OS-a, instalirane ovisnosti i podatkovne datoteke; buduće verzije će također vratiti stanje aktivne memorije za trenutni nastavak. Agenti (ili orkestratori) mogu programski pokrenuti snimke za kontrolne točke ili scenarije širenja, a zatim stvoriti više sandboxova iz iste snimke kako bi istražili paralelne hipoteze u izolaciji.
Što se tiče cijena, Cloudflare je prešao na model "samo aktivni CPU": naplaćuju vam se stvarno korišteni CPU ciklusi, a ne vrijeme neaktivnosti dok agenti čekaju na LLM-ove. U kombinaciji s ogromnim ograničenjima konkurentnosti za "lite" i veće instance, ovo omogućuje pokretanje velike flote agenata bez trošenja novca na uspavane kontejnere.
S druge strane, Google Cloudov GKE Agent Sandbox je duboko integriran s Kubernetesom i gVisorom. Ideja je omogućiti vam pokretanje opterećenja agenata u izoliranim podovima unutar vlastitih klastera. Izrađujete GKE klaster (Autopilot može automatski omogućiti gVisor, dok Standardni klasteri trebaju eksplicitne klase vremena izvođenja i skupove čvorova omogućene gVisorom), a zatim implementirate kontroler Agent Sandboxa putem verzioniranih manifesta.
Dva osnovna prilagođena resursa pokreću model: SandboxTemplate i SandboxWarmPool. SandboxTemplate djeluje kao višekratno upotrebljiv nacrt koji specificira predložak poda (slika, portovi, resursi, runtimeClassName: gvisoritd.) za okruženja u sandboxu, kao što je Python okruženje. SandboxWarmPool održava konfigurirani broj prethodno zagrijanih podova spremnim za gotovo trenutno preuzimanje, izbjegavajući hladne startove kada agentu treba svježe okruženje za manje od sekunde.
A Sandbox Router Usluga tada djeluje kao pristupnik za promet između klijenata i ovih izoliranih podova. U razvoju možete tunelirati promet kroz kubectl port-forward bez otkrivanja javnih IP adresa. U produkciji biste obično usmjerivaču pružili odgovarajući ulaz i mTLS. Na strani klijenta, Google pruža Python biblioteku "Agentic Sandbox" koja obuhvaća cijeli životni ciklus: stvorite zahtjev za sandbox iz predloška, pričekajte dok ne bude spreman, pokrenite naredbe ljuske i očistite kada završite.
Sve je to i dalje „samo Kubernetes“ ispod haube, ali upakirano u koherentnu priču za agente u okruženju. gVisor pruža izolaciju procesa i sistemskih poziva, SandboxTemplate standardizira konfiguracije, WarmPool rješava latenciju pokretanja, a ruter i Python klijent čine ga praktičnim za aplikacije usmjerene na LLM.
S druge strane, Heroku se oslanja na vrlo zreo gradivni blok: jednokratne dinamometarske strojeve. Godinama su korisnici Herokua pokretali ad hoc poslove – migracije, skripte za održavanje, administratorske zadatke – u kratkotrajnim dinamometrima koji se pokreću na zahtjev i prekidaju rad kada završe. Heroku je ponovno koristio ovu infrastrukturu kao sandboxe za izvršavanje koda, pokrenute uz njihove ponude Managed Inference i Agents. Agent piše isječke koda za Python, Ruby, Node ili Go; Heroku ih izvršava unutar kratkotrajnih dinamometra i struji rezultate natrag, ograničavajući radijus eksplozije na kratkotrajni spremnik.
Ovim sandbox okruženjima možete pristupiti putem ugrađenih alata u Heroku Agents API-ju ili implementacijom MCP (Model Context Protocol) poslužitelja otvorenog koda. MCP poslužitelji otkrivaju standardizirane krajnje točke alata, tako da klijenti poput Agentforcea, Claude Desktopa ili Cursora mogu tretirati Herokuov sandbox kao generički, udaljeni backend za izvršavanje koda. Svaki poslužitelj podržava ograničenja specifična za vrijeme izvođenja (kao što max_calls po petlji agenta) kako bi se spriječilo da se agenti vrte u uskim, skupim petljama.
LangChainovi Deep Agents dodaju još jednu dimenziju integracijom s pružateljima sandbox okruženja trećih strana poput Runloop-a, Daytona-e i Modal-a. Uzorak je jednostavan: Deep Agent nastavlja raditi gdje god želite (lokalno ili u oblaku), ali kad god treba pokretati naredbe, stvarati datoteke ili izvršavati kod, te se operacije prosljeđuju u udaljeni sandbox. Skripte za postavljanje mogu unaprijed učitati varijable okruženja, klonirati repozitorije, instalirati alate i još mnogo toga, tako da svaki agent dobiva čisto, kontrolirano okruženje. Upravitelji konteksta zatim rukuju stvaranjem i čišćenjem, iako dokumentacija snažno preporučuje praćenje nadzornih ploča pružatelja usluga za sve zaboravljene dugotrajne sandboxe.
Performanse, stanje i grananje: zašto je brzina važna za agente
Spor, ali ultra siguran sandbox će se u praksi zaobići; alati za razvojne programere žive ili umiru ovisno o latenciji. Agenti za kodiranje ne ponašaju se kao noćni batch poslovi. Oni pokreću interaktivne petlje: čitaju kod, predlažu izmjene, provode testove, analiziraju logove, pozivaju alate, čekaju ljude, a zatim ponavljaju. U stvarnim sesijama također istražuju više grana problema, napuštaju neke rute i vraćaju se na druge kasnije.
Zato platforme poput Freestylea opsjedaju životni ciklus virtualnih strojeva kraći od sekunde i bogatom semantikom stanja. Njihovi virtualni strojevi su potpuni Linux strojevi s root pristupom, systemd uslugama, podrškom za ugniježđenu virtualizaciju i potpunim umrežavanjem. Dokumentacija tvrdi da je vrijeme pružanja od API poziva do pokretanja virtualnog stroja manje od 800 ms, obustava/nastavak rada za manje od 100 ms i mogućnost snimanja ili forkiranja virtualnih strojeva tijekom izvršavanja uz minimalan utjecaj na performanse. Izričito navode stanje preglednika kao korisnika: ako je agent doveo preglednik u zanimljivo stanje, može forkirati taj virtualni stroj 20 puta iz istog snapshota umjesto da ponovno stvori to stanje od nule.
Googleov SandboxWarmPool za GKE izražava istu ideju u Kubernetes terminima: održavajte skup prethodno zagrijanih podova kako agenti ne bi plaćali pune kazne za hladno pokretanje za svako novo pokretanje. Daytonini radni prostori temeljeni na snimkama podataka plus pravila automatskog zaustavljanja/arhiviranja/brisanja prilagođavaju životni ciklus za različite vrste sesija: aktivna razvojna okruženja, kratkotrajne eksperimente i dugotrajne osnovne linije.
E2B-ov naglasak na pozadinskim poslovima, direktorijima koji se mogu pratiti, izoliranim datotečnim sustavima i volumenima koji se mogu ponovno koristiti druga je strana iste medalje. Ove značajke omogućuju agentu da održava razvojni poslužitelj ili testni sustav u pogonu dok istražuje promjene koda ili dijeli trajni volumen na više efemernih sandbox okruženja tijekom vremena. Bez toga, agenti na kraju izbacuju jednokratne naredbe i gube kontekst, što ubija produktivnost.
Koristan način za procjenu bilo kojeg sandboxa za rad agenata je postavljanje nekoliko izravnih pitanja. Mogu li pokrenuti novo okruženje za manje od sekunde? Mogu li čisto spremiti i vratiti stanje, uključujući djelomične izgradnje ili sesije preglednika? Mogu li podijeliti stanje za paralelno istraživanje? Mogu li zadržati dugotrajne, ali resursno učinkovite radne prostore za tokove "vratite se kasnije"? Što više odgovora "da" dobijete, to se vaši agenti mogu ponašati kao pravi inženjeri umjesto kao pokretači skripti bez stanja.
Tajne, mrežne politike i povjerenje u radni prostor kao prava kontrolna ravnina
Čak i uz savršenu izolaciju hosta, lako je izgraditi nesiguran sustav ako zanemarite tajne, mrežne politike i povjerenje radnog prostora. Dockerova dokumentacija o sandboxu je osvježavajuće iskrena po tom pitanju. microVM i njegov privatni Docker daemon tvore glavnu granicu povjerenja s hostom. Međutim, unutar tog VM-a, agent ima punu kontrolu na root razini, a dijeljeni radni prostor je montiran za čitanje i pisanje. Prema zadanim postavkama, sva uređivanja datoteka odmah se odražavaju na hostu. Izlaz iz mreže je prema zadanim postavkama odbijen i dopušten je samo putem eksplicitnih pravila, a HTTP zahtjevi koriste proxy na strani hosta koji može ubrizgati vjerodajnice bez otkrivanja sirovih tajni VM-u.
To znači da je izolacija hosta samo prvi korak; još uvijek morate razmišljati o tome što agent može učiniti radnom prostoru i vanjskom svijetu. Dockerova dokumentacija izričito upozorava da ako agent uređuje skripte, ljudi ih kasnije izvršavaju – Git hooks, CI konfiguracije, IDE definicije zadataka, Makefile ciljevi, package.json skripte – šteta se može "prenijeti" natrag na host ili CI sustave kada se te skripte pokrenu. Čak ističu da se Git priključuje .git/ ne pojavljivati se u git diff, što olakšava tiho ustrajanje zlonamjerne logike.
Proxyiranje vjerodajnica je moćno, ali suptilno. Dockerov izlazni proxy osigurava da tajne ostanu izvan virtualnog stroja, ali i dalje omogućuje agentu da djeluje koristeći te identitete protiv dopuštenih hostova. Neki tokovi - poput pisanja prilagođenih varijabli okruženja u datoteke kao što su /etc/sandbox-persistent.sh – probiti ovu granicu namjernim pohranjivanjem tajni unutar virtualnog stroja, što je sigurno samo ako istinski vjerujete agentu i sandboxu.
Opseg konfiguracije je jednako važan kao i tajne. Dockerov FAQ navodi da konfiguracije na razini korisnika poput ~/.claude or ~/.codex na hostu se ne kopiraju u sandbox; vidljiva je samo konfiguracija na razini projekta u dijeljenom radnom prostoru. Anthropicova dokumentacija konfiguracije naglašava da postavke na razini projekta - alati, dopuštenja, MCP poslužitelji, hooks - nadjačavaju one na razini korisnika i dijele se između timova. Drugim riječima, bilo koje politike, upute i dodaci koje priložite repozitoriju postaju glavno područje površine koje agent vidi.
OpenAI-jev vodič za vještine ističe slične točke, ali malo drugačije objašnjene. Vještine (paketi alata) mogu predstavljati rizike od izbacivanja podataka temeljene na brzom ubrizgavanju. Dokumentacija upozorava na izravno izlaganje nekontroliranog, javnog tržišta vještina krajnjim korisnicima, budući da zlonamjerne SKILL.md datoteke mogu nadjačati pravila, pokrenuti destruktivne radnje ili procuriti privatne podatke. Preporučuju provjeru vještina razvojnih programera, njihovo ograničavanje na određene tijekove rada, skrivanje radnji s velikim utjecajem iza dodatnih odobrenja i provjera pravila te tretiranje vještina kao dijela vašeg modela prijetnje.
Kada se sve dijelove spoji, „prava“ kontrolna ravnina za agentske sandboxove obuhvaća četiri sloja. Izolacija hosta štiti vaše strojeve i čvorove klastera. Povjerenje radnog prostora štiti budućeg čovjeka ili CI-ja koji će pokretati datoteke proizvedene unutar sandboxa. Mrežna politika štiti vanjske sustave i privatne izvore podataka. Upravljanje vjerodajnicama štiti identitete putem kojih agent može djelovati. Robustan dizajn ima odgovore za sva četiri, ne samo za prvo.
Uz to, i dalje vam je potreban zdrav skepticizam prema brzom ubrizgavanju i otmici agenta. NIST, OWASP i OpenAI opisuju varijante istog obrasca: nepouzdani unos – README, web stranica, datoteka zapisnika – ugrađuje zlonamjerne upute koje preusmjeravaju ponašanje agenta. Generiranje prošireno pretraživanjem i fino podešavanje ne rješavaju ovo magično. Dobro instrumentirani sandbox plus dobra politika ne mogu spriječiti da se model prevari, ali mogu dramatično smanjiti negativne posljedice kada se to dogodi.
Platforme u oblaku i okruženja za izvršavanje agenata počinju kodirati ove lekcije. Tajni proxyji, dopuštene izlazne domene, konfiguracije s ograničenim repozitorijskim opsegom, podagenti s užim mogućnostima, tokovi odobravanja temeljeni na hookovima i reproducibilni sandboxovi, sve su to dijelovi iste slagalice: prihvatite da su modeli pogrešivi i osmislite okruženje tako da cijena te pogrešljivosti ostane ograničena.
U lokalnim i cloud postavkama, izvršni sandbox za agente najbolje je shvatiti kao pažljivo povučenu liniju: on ne čini model pametnijim, već čini njegove pogreške manje katastrofalnim i uočljivijim. S pravom kombinacijom kontrola datotečnog sustava, procesa, mreže, tajnog i životnog ciklusa, plus pametnim učenjem agenta o njegovom okruženju, možete dopustiti AI sustavima da kloniraju repozitorije, pokreću testove, pokreću preglednike, pa čak i dodiruju sustave slične produkcijskim - bez da im date ključeve svega što vam je važno.
To znači da je izolacija hosta samo prvi korak; još uvijek morate razmisliti o tome što agent može učiniti radnom prostoru i vanjskom svijetu, uključujući riesgos como daljinsko izvršavanje koda. Dockerova dokumentacija izričito upozorava da ako agent uređuje skripte, ljudi ih kasnije izvršavaju – Git hooks, CI konfiguracije, IDE definicije zadataka, Makefile ciljevi, package.json skripte – šteta se može "prenijeti" natrag na host ili CI sustave kada se te skripte pokrenu.
