- 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 sistema.
- Moderne platforme kombiniraju OS primitive (Seatbelt, Landlock, gVisor, microVM) s apstrakcijama višeg nivoa poput snimaka, toplih bazena, volumena i PTY-ova kako bi sandboxovi bili sigurni i brzi.
- Tajne, mrežne politike, povjerenje u radni prostor i odbrana od promptno-injektiranja čine pravu kontrolnu ravan; sama izolacija hosta nije dovoljna za sigurno izvršavanje agenta.
- Oblak i lokalni ekosistemi (Cloudflare, GKE, Heroku, Docker, Freestyle, E2B, Daytona, Cursor, LangChain) konvergiraju oko sandbox okruženja za izvršavanje kao podrazumijevanog načina za pokretanje nepouzdanog koda generiranog od strane agenata.
Dozvoljavanje 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 mašini. 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 pun grešaka može izbrisati bazu podataka, procuriti API ključ na internet ili implementirati neispravnu verziju u produkciju bez da zaista "razumijeva" šta je pošlo po zlu.
Pravo pitanje više nije „koliko je model tačan?“, već „šta može postići kada je pogrešan, 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 servere ili ubrzavati preglednike, dok vi strogo kontrolirate datotečne sisteme, mrežu, vjerodajnice i životni ciklus. Umjesto da vjerujete modelu, ograničavate radijus eksplozije.
Zašto agentima za kodiranje treba poseban sandbox za izvršavanje
Moderni agenti za kodiranje poput Claude Code-a, LangChain Deep Agents-a, Docker-ovih sandbox-ova 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 shell naredbe, manipulišu Gitom, pokreću Docker buildove, komuniciraju s vanjskim API-jima, pa čak i upravljaju potpunim okruženjima sličnim desktop računarima putem preglednika. Dokumentacija dobavljača je vrlo eksplicitna po ovom pitanju: Claude Code je predstavljen kao agilni asistent za razvoj koji može pregledati vašu kodnu bazu, vršiti izmjene i pokretati naredbe; LangChain Deep Agents tretira sandbox backend kao mjesto gdje izvršavaju shell naredbe, upravljaju datotečnim sistemima i delegiraju posao podagentima radi izolacije.
Upravo ovaj skup mogućnosti čini ove agente korisnim – i operativno rizičnim. Kada model može da se pokrene pytest, instalirati npm pakete, otvoriti grane ili otkloniti greške prilikom izgradnje, samo je nekoliko poziva alata udaljeno od modificiranja 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 brzo ubrizgavanje: zlonamjerne instrukcije skrivene u datotekama, web stranicama ili zapisnicima mogu tiho usmjeriti agenta na radnje koje nikada niste namjeravali odobriti.
Mnogi timovi počinju s naivnim tokovima "traženja odobrenja" za svaku komandu i brzo otkriju da se ne skaliraju. Anthropic je javno podijelio da su korisnici odobrili 93% Claude Codeovih upita za dozvole; Dockerov Claude sandbox čak pokreće Claude Code sa --skip-permissions po defaultu, oslanjajući se na izolaciju tokom izvršavanja umjesto na mnoštvo dijaloga. Ljudi osjećaju umor od odobravanja, posebno kada istovremeno pokreću više agenata i mijenjaju kontekst kroz mnoge upite. U tom trenutku, dijalozi za potvrdu postaju ceremonija, a ne pouzdana kontrola.
Izvršni sandbox mijenja sigurnosni model od „vjeruj korisniku da će pročitati svaki upit“ do „pretpostavi da će neke naredbe biti pogrešne ili neprijateljske i ograniči štetu koju mogu prouzrokovati“. Pješčanik postaje čvrsta granica oko datoteka, procesa, mreža i tajni koje agent može dodirnuti, čak i kada se njime manipuliše brzim ubrizgavanjem ili jednostavno pravljenjem grešaka.
Postoji i osnovni argument koji se odnosi na iskustvo programera: agentima je potrebno dovoljno prostora da bi zapravo radili. Ako previše koristite sandbox s grubim ograničenjima, jednostavne naredbe poput izgradnje ili testiranja stalno ne uspijevaju zbog nejasnih grešaka u dozvolama. Najbolji sistemi, poput onih koje je Cursor implementirao na macOS/Linux/Windows ili Cloudflare, Heroku i Google Cloud za hostovana opterećenja, imaju za cilj da agentima pruže osjećaj "pravog računara" unutar uskog perimetra.
Šta izvršni sandbox za agente zaista izoluje
Pravi agentski sandbox nije samo „negdje drugdje za izvršavanje koda“ – to je skup eksplicitnih granica koje definiraju radijus eksplozije. Možete se sjetiti 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 sistema: agent bi trebao vidjeti samo radni prostor koji namjerno dijelite. LangChainova dokumentacija predstavlja sandbox kao barijeru koja drži agente podalje od host datoteka; 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 sistemske konfiguracije.
Drugo, granica procesa i jezgra: radna opterećenja agenata ne bi trebala dijeliti sirovo jezgro hosta ili tabelu procesa. Dockerova sandbox arhitektura izoluje svako okruženje u svom microVM i Linux kernelFirecracker (koji u "insight" okruženju koristi nekoliko provajdera) tretira tu granicu virtuelne mašine kao prvi sloj izolacije, a zatim dodaje seccomp, namespaces, cgroups i ograničenja slična jail-u. Googleov GKE Agent Sandbox postiže sličan efekat unutar Kubernetesa koristeći gVisor: "sentry" sloj presreće sistemske pozive i posreduje u pristupu osnovnom čvoru.
Treće, granica mreže: bez mrežne politike, agent u sandboxu je i dalje mašina za izvlačenje podataka. Većina ozbiljnih platformi sada se isporučuje sa zadanim postavkama "zabrani sav izlaz". Docker Sandboxovi, na primjer, blokiraju HTTP/HTTPS dok se eksplicitno ne dozvoli, prekidaju sirovi TCP/UDP/ICMP i ne dozvoljavaju promet prema privatnim IP rasponima i localhostu osim ako ne konfigurirate izuzetke. Cloudflare, Google i drugi dizajniraju svoje sandboxove tako da odlazni pozivi idu kroz programabilne proxyje gdje možete ubrizgati autorizaciju, filtrirati odredišta i revidirati korištenje.
Četvrto, granica akreditiva: otkrivanje sirovih tajni unutar sandboxa treba tretirati kao krajnju mjeru, a ne kao zadanu opciju. 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 VM-a. Cloudflare Sandboxovi slično ubrizgavaju akreditive na mrežnom sloju, a ne putem env varijabli. Na taj način, čak i ako prompt inject uvjeri agenta da "ispiše sve varijable okruženja", nema ništa sočno za ukrasti.
Peto, granica životnog ciklusa: radni prostori agenata rijetko postoje samo za jednu komandu; potrebna im je eksplicitna semantika za pokretanje, pauziranje, snimanje, fork i rastavljanje. E2B otkriva izolirane datotečne sisteme, pozadinske naredbe i volumene koji mogu opstati duže od jednog životnog vijeka sandboxa. Freestyle se fokusira na vrlo brzo pokretanje, obustavljanje i nastavak rada VM-a sa snimkama i grananjem stanja u memoriji. Daytona dodaje sandboxove zasnovane na snimcima, plus politike automatskog zaustavljanja, automatskog arhiviranja i automatskog brisanja tako da možete dugo održavati neka okruženja, a druga tretirati kao jednokratna.
Kada jednom vidite ovih pet osa – datotečni sistem, proces, mrežu, akreditacije i životni ciklus – možete bilo koju stranicu sandbox proizvoda protumačiti kao niz kompromisa. Kontejner sa dijeljenim jezgrom i velikim montiranjem hosta, ali strogim pravilima izlaza, veoma se razlikuje od microVM-a bez montiranja hosta, ali sa popuštanijom mrežom. Za programere koji trebaju instalirati zavisnosti, pokretati preglednike ili graditi slike Dockera, jače granice u stilu VM-a su obično sigurnija podrazumijevana vrijednost.
Sandboxing na macOS-u, Linuxu i Windowsu za lokalne programerske agente
Na laptopima za razvojne programere nije uvijek moguće pokrenuti teške microVM sandbox-ove, pa su timovi morali biti kreativni s izolacijom koja je izvorno prilagođena operativnom sistemu. Cursorov nedavni rad na lokalnim sandbox okruženjima 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, potpune virtuelne mašine i dugotrajna, 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ćavalo složenost, pa čak i dodjeljivalo generiranim binarnim datotekama tranzitivno povjerenje. Linux kontejneri bi prisilili korisnike macOS-a da koriste samo Linux binarne datoteke, a potpuno razvijene virtuelne mašine imale 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 uprkos svojim godinama. Omogućava vam pokretanje naredbe pod sandbox profilom 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 ove politike za vrijeme izvođenja na osnovu postavki radnog prostora i administratora, plus korisničkih postavki. .cursorignore, tako da ignorisane putanje postaju zabranjene unutar sandbox-a.
Na Linuxu, kernel otkriva prave primitive – seccomp za filtriranje sistemskih poziva i Landlock za ograničenja datotečnog sistema – 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 direktno orkestrirati Landlock i seccomp. Seccomp zabranjuje opasne sistemske pozive; Landlock provodi pravila čitanja/pisanja zasnovana na putanjama, čak im dozvoljavajući da prekrivaju korisničke radne prostore tako da su ignorisane 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 ignorisanih datoteka je najsporiji dio podešavanja sandboxa. Odloženo filtriranje u macOS stilu koje može vidjeti tačnu putanju datoteke u vrijeme sistemskog poziva bi ovo pojednostavilo, ali Linuxov seccomp-bpf ne olakšava tu inspekciju putanje, tako da postoji pravi inženjerski kompromis između čvrste izolacije i brzine pokretanja.
Na Windowsu, izgradnja zaista ekvivalentnog izvornog sandbox okruženja ostaje teža jer je većina izolacijskih primitiva optimizirana za preglednike, a ne za opće alate za razvoj. Cursor trenutno pokreće Linux sandbox unutar WSL2 za Windows korisnike, u suštini koristeći Linux izolaciju dok ne budu dostupne bogatije primitive. Oni sarađuju sa Microsoftom kako bi otkrili prave mogućnosti tako da vremenom Windows agenti mogu uživati u prvoklasnom, izvornom sandboxu bez WSL-a kao potpore.
Zajednička nit svih ovih pristupa specifičnih za operativne sisteme je objedinjeni sandbox API na vrhu. Sa stanovišta agenta, postoji samo "ljuskasti alat" sa jasnim mogućnostima i pravilima. Ispod haube, Seatbelt, Landlock/seccomp ili izolacija zasnovana na WSL2 primjenjuju ta pravila različito u zavisnosti od platforme.
Učenje agenata da razumiju i poštuju sandbox
Sandbox pomaže samo ako agent može predvidjeti šta će unutar njega funkcionirati i kada treba eskalirati privilegije ili napustiti sandbox. To zvuči očigledno, ali u praksi je zahtijevalo iznenađujuće duboke iteracije u dizajnu brzih koraka i 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: da li komanda ima pristup datotečnom sistemu, pristup Gitu, pristup mreži ili potpuno offline 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 benchmarkovi poput „Cursor Bench“ ili sličnih eval paketa se zatim koriste za poređenje performansi agenata sa i bez sandboxinga. Jedan od ranih načina kvara bio je vrlo konzistentan: agent bi slijepo ponavljao istu neuspjelu terminalnu komandu iznova i iznova, umjesto da shvati da nailazi na ograničenje sandboxa. Bez jasnog signala o tome zašto je komanda neuspješna, model nije mogao naučiti obrazac.
Rješenje je bilo eksplicitno prikazivanje grešaka sandboxa u izlazima alata, često uz podsjetnik šta dalje raditi. Kada bi komanda bila blokirana zbog pravila sistema datoteka ili mreže, alat ljuske je počeo uključivati kratko objašnjenje poput „blokirano od strane sandboxa: izlazni mrežni pristup onemogućen za ovu sesiju“ i, u nekim slučajevima, nagovještaj da agent može tražiti povišene dozvole. Nakon ove promjene, agenti su postali mnogo otporniji: prestali su se ponavljati na beznadežnim komandama i ili su prilagodili svoj plan ili zatražili potrebne mogućnosti.
Offline evaluacije su korisne, ali one govore samo dio priče. Da bi zaista znali da li sandbox narušava korisničko iskustvo, timovi su postepeno uvodili podršku za sandbox u produkciji i pratili stope grešaka, vrijeme završetka i kanale za povratne informacije. U praksi, dobavljači izvještavaju da značajan dio upita na kompatibilnim platformama sada u potpunosti radi unutar sandbox okruženja – s poslovnim korisnicima poput NVIDIA-e među prvima koji su to učinili – i da agenti u sandbox okruženjima zapravo pauziraju za odobrenje oko 40% rjeđe u stvarnim radnim procesima, štedeći sate ručnog pregleda uz smanjenje rizika.
Gledajući unaprijed, postoji veliko interesovanje za "izvorne sandbox agente" - modele obučene direktno na ograničenjima svog okruženja. Umjesto da tretiraju ljusku, preglednik ili datotečni sistem kao apstraktne alate, ovi agenti bi razumjeli da žive u usko ograničenom okruženju izvršavanja, da mogu pisati dugotrajne skripte i programe i da moraju poštovati granične uslove kao što su „nema izlazne mreže“ ili „radni prostor je samo za čitanje“. Ta obuka bi ih mogla učiniti mnogo boljim u planiranju sigurnih i efikasnih sekvenci akcija bez udaranja o nevidljive zidove.
Cloud sandboxovi: Cloudflare, Google Cloud, Heroku i drugi
Izvan laptopa programera, veliki talas dobavljača infrastrukture se utrkuje da ponudi hostovane sandbox sisteme posebno podešene za AI agente. Njihovi ciljevi su isti – izolacija, kontrola i performanse – ali kompromisi izgledaju malo drugačije na nivou oblaka.
Cloudflare sandboxovi, izgrađeni na Cloudflare kontejnerima i sada općenito dostupni, imaju za cilj da izgledaju i djeluju 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 po potrebi; ako je u stanju mirovanja, automatski se obustavlja radi uštede računarskih resursa i nastavlja s radom pri sljedećem zahtjevu. Programeri (ili agenti) mogu komunicirati s njim putem tipiziranih metoda kao što su exec, gitCheckout, writeFile, i više, koristeći JavaScript/TypeScript SDK.
Jedan od najsloženijih problema u oblaku je sigurna autentifikacija iznutra agentskih sandbox okruženja. 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 povezivanjem.
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 uživo, prekidati procese, ponovo se povezivati kasnije i reproducirati prošli izlaz. Svaki PTY ima svoj radni direktorij i okruženje, a izlaz se baferuje na serveru tako da klijenti koji se ponovo povezuju mogu nadoknaditi propuštene logove.
Pored pristupa sirovom shell-u, Cloudflare također nudi trajne "kontekste izvršavanja koda" za jezike poput Pythona, JavaScripta i TypeScripta. Za razliku od mnogih pokretača isječaka koji izvršavaju svaki fragment izolovano, ovi konteksti čuvaju varijable, uvoze i stanje u svim pozivima, slično kao Jupyter bilježnica. Agenti mogu učitavati podatke u jednom pozivu, transformirati ih u drugom i prikazivati grafikone ili HTML tabele bez stalnog ponovnog parsiranja i ponovnog uvoza svega.
Za zadatke web razvoja, Cloudflare sandbox okruženja 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 zapise dok server ne bude spreman, a zatim izloži port iza javne URL adrese za pregled. Metode poput waitForPort() or waitForLog() Neka agenti sekvenciraju akcije na osnovu stvarnih signala spremnosti umjesto naivnih sleep(2s) nagađanja.
Tokovi rada vođeni događajima dobijaju poticaj od primitiva za nadgledanje datoteka koje podržava Linuxov mehanizam inotify. Agent se može pretplatiti na promjene pod /workspace/src i automatski ponovo 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 kao što je sandbox.watch() i tokove događaja koje šalje server.
Kako bi se zatvorila petlja životnog ciklusa, Cloudflare uvodi prave snimke stanja – snimke stanja na nivou virtuelne mašine koji se mogu vratiti za nekoliko sekundi iz R2 skladišta. Snimci čuvaju stanje datotečnog sistema, konfiguraciju operativnog sistema, instalirane zavisnosti i datoteke podataka; buduće verzije će također vratiti stanje aktivne memorije za trenutni nastavak. Agenti (ili orkestratori) mogu programski pokrenuti snimke za kontrolne tačke ili scenarije širenja, a zatim izdvojiti više sandbox okruženja iz istog snimka 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ćava 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 da vam se omogući pokretanje opterećenja agenata u izoliranim podovima unutar vaših vlastitih klastera. Kreirate GKE klaster (Autopilot može automatski omogućiti gVisor, dok Standardni klasteri trebaju eksplicitne klase za izvršavanje i gVisor-omogućene skupove čvorova), a zatim implementirate Agent Sandbox kontroler 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 Servis tada djeluje kao prolaz 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 ruteru pružili odgovarajući ulaz i mTLS. Na strani klijenta, Google pruža Python "Agentic Sandbox" biblioteku koja obuhvata cijeli životni ciklus: kreirajte zahtjev za sandbox iz predloška, pričekajte dok ne bude spreman, pokrenite shell naredbe i očistite kada završite.
Sve ovo je i dalje "samo Kubernetes" ispod haube, ali upakovano 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 uređaje. 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 se završe. Heroku je ponovo koristio ovu infrastrukturu kao sandbox-ove 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 strimuje rezultate nazad, ograničavajući radijus eksplozije na kratkotrajni kontejner.
Ovim sandbox okruženjima možete pristupiti putem ugrađenih alata u Heroku Agents API-ju ili implementacijom servera otvorenog koda Model Context Protocol (MCP). MCP serveri otkrivaju standardizirane krajnje tač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 server 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.
LangChain-ovi Deep Agent-i dodaju još jednu dimenziju integracijom sa sandbox provajderima trećih strana kao što su Runloop, Daytona i Modal. Uzorak je jednostavan: Deep Agent nastavlja s radom gdje god želite (lokalno ili u oblaku), ali kad god treba pokrenuti naredbe, kreirati datoteke ili izvršiti kod, te operacije se prosljeđuju udaljenom sandboxu. 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 kreiranjem 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 od latencije. Agenti za kodiranje se ne ponašaju kao noćni batch poslovi. Oni pokreću interaktivne petlje: čitaju kod, predlažu izmjene, izvršavaju testove, analiziraju logove, pozivaju alate, čekaju na ljude, a zatim ponavljaju. U stvarnim sesijama, oni također istražuju više grana problema, napuštaju neke rute i vraćaju se na druge kasnije.
Zbog toga su platforme poput Freestylea opsjednute životnim ciklusom virtuelnih mašina kraćim od jedne sekunde i bogatom semantikom stanja. Njihove virtuelne mašine (VM) su potpune Linux mašine sa root pristupom, systemd servisima, podrškom za ugniježđenu virtuelizaciju i potpunim umrežavanjem. Dokumentacija tvrdi da je pružanje usluga (provisioning) za manje od 800 ms od API poziva do pokretanja VM, obustava/nastavak rada za manje od 100 ms i mogućnost snimanja (snapshot) ili forkovanja VM-ova (fork) usred izvršavanja uz minimalan utjecaj na performanse. Oni eksplicitno navode stanje preglednika kao korisnika: ako je agent doveo preglednik u zanimljivo stanje, može forknuti tu VM 20 puta iz istog snimka umjesto da ponovo kreira to stanje od nule.
Googleov SandboxWarmPool za GKE izražava istu ideju u Kubernetes terminologiji: održavajte skup prethodno zagrijanih podova kako agenti ne bi plaćali pune kazne za hladno pokretanje za svako novo pokretanje. Daytonini radni prostori zasnovani na snimcima podataka, plus politike automatskog zaustavljanja/arhiviranja/brisanja, podešavaju životni ciklus za različite tipove 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 sistemima i volumenima koji se mogu ponovo koristiti je druga strana iste medalje. Ove funkcije omogućavaju agentu da održava dev server ili testni sistem u radu dok istražuje promjene koda ili da dijeli trajni volumen između više efemernih sandbox okruženja tokom vremena. Bez ovoga, agenti na kraju izvršavaju jednokratne naredbe i gube kontekst, što ubija produktivnost.
Koristan način za procjenu bilo kojeg sandboxa za rad agenata je postavljanje nekoliko direktnih pitanja. Mogu li pokrenuti novo okruženje za manje od sekunde? Mogu li čisto sačuvati 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 efikasne 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 ravan
Čak i uz savršenu izolaciju hosta, lako je izgraditi nesiguran sistem ako zanemarite tajne, mrežne politike i povjerenje u radni prostor. Dockerova sandbox dokumentacija je osvježavajuće iskrena po ovom pitanju. microVM i njen privatni Docker daemon formiraju glavnu granicu povjerenja s hostom. Međutim, unutar te VM-e, agent ima punu kontrolu na root nivou, a dijeljeni radni prostor je montiran za čitanje i pisanje. Podrazumevano, sve izmjene datoteka se odmah odražavaju na hostu. Izlaz iz mreže je podrazumevano odbijen i dozvoljen je samo putem eksplicitnih pravila, a HTTP zahtjevi koriste proxy na strani hosta koji može ubrizgati akreditive bez otkrivanja sirovih tajni VM-u.
To znači da je izolacija hosta samo prvi korak; i dalje morate razmišljati o tome šta agent može učiniti radnom prostoru i vanjskom svijetu. Dockerova dokumentacija eksplicitno upozorava da ako agent uređuje skripte, ljudi ih kasnije izvršavaju – Git hooks, CI konfiguracije, IDE definicije zadataka, Makefile mete, package.json skripte – šteta se može "prenijeti" nazad na host ili CI sisteme kada se te skripte pokrenu. Čak ističu da se Git kači .git/ ne pojavljuje se u git diff, što olakšava tiho opstajanje zlonamjerne logike.
Proksiranje akreditiva je moćno, ali suptilno. Dockerov odlazni proxy osigurava da tajne ostanu izvan VM-a, ali i dalje omogućava agentu da djeluje koristeći te identitete protiv dozvoljenih hostova. Neki tokovi - poput pisanja prilagođenih env varijabli u datoteke kao što su /etc/sandbox-persistent.sh – probijte ovu granicu namjernim pohranjivanjem tajni unutar virtualne mašine, što je sigurno samo ako istinski vjerujete agentu i sandboxu.
Opseg konfiguracije je jednako važan kao i tajne. Docker-ov FAQ navodi da konfiguracije na nivou korisnika poput ~/.claude or ~/.codex na hostu se ne kopiraju u sandbox; vidljiva je samo konfiguracija ograničena na projekat u dijeljenom radnom prostoru. Anthropic-ova dokumentacija za konfiguraciju naglašava da postavke na nivou projekta - alati, dozvole, MCP serveri, hookovi - nadjačavaju one na nivou korisnika i dijele se između timova. Drugim riječima, bilo koje politike, instrukcije i dodaci koje priložite repozitoriju postaju glavna površina koju agent vidi.
OpenAI-jevo uputstvo za vještine ističe slične tačke, ali malo drugačijim rječnikom. Paketi alata (Vještine) mogu predstavljati rizik od krađe podataka uzrokovane brzim ubrizgavanjem. Dokumentacija upozorava na direktno izlaganje nekontroliranog, javnog tržišta vještina krajnjim korisnicima, jer zlonamjerne SKILL.md datoteke mogu poništiti pravila, pokrenuti destruktivne radnje ili procuriti privatne podatke. Preporučuju provjeru vještina programera, njihovo ograničavanje na određene tokove 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 ravan za agentske sandboxove obuhvata četiri sloja. Izolacija hosta štiti vaše mašine i čvorove klastera. Povjerenje radnog prostora štiti budućeg čovjeka ili CI koji će pokretati datoteke proizvedene unutar sandboxa. Mrežna politika štiti vanjske sisteme i privatne izvore podataka. Upravljanje akreditivima š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 dnevnika – ugrađuje zlonamjerne instrukcije 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 model bude prevaren, ali mogu dramatično smanjiti negativne posljedice kada se to dogodi.
Cloud platforme i agentska okruženja počinju kodirati ove lekcije. Tajni proxyji, dozvoljene odlazne domene, konfiguracije ograničenog repozitorija, podagenti s užim mogućnostima, tokovi odobravanja zasnovani na hook-ovima i reproducibilni sandbox-ovi su sve dijelovi iste slagalice: prihvatite da su modeli podložni greškama i osmislite okruženje tako da cijena te podložnosti greškama ostane ograničena.
U lokalnim i cloud postavkama, izvršni sandbox za agente se najbolje može shvatiti kao pažljivo povučena linija: on ne čini model pametnijim, već čini njegove greške manje katastrofalnim i uočljivijim. Sa pravom kombinacijom kontrola datotečnog sistema, procesa, mreže, tajnih podataka i životnog ciklusa, plus pametnim učenjem agenta o njegovom okruženju, možete dozvoliti AI sistemima da kloniraju repozitorije, pokreću testove, pokreću preglednike, pa čak i da dodiruju sisteme 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; i dalje morate razmišljati o tome šta agent može učiniti radnom prostoru i vanjskom svijetu, uključujući riesgos como. daljinsko izvršavanje koda. Dockerova dokumentacija eksplicitno upozorava da ako agent uređuje skripte, ljudi ih kasnije izvršavaju – Git hooks, CI konfiguracije, IDE definicije zadataka, Makefile mete, package.json skripte – šteta se može "prenijeti" nazad na host ili CI sisteme kada se te skripte pokrenu.
