Mga sandbox ng pagpapatupad para sa mga ahente ng AI: arkitektura, mga panganib at mga pattern sa totoong mundo

Home » Sawa » Mga sandbox ng pagpapatupad para sa mga ahente ng AI: arkitektura, mga panganib at mga pattern sa totoong mundo

Ang pagpapahintulot sa mga AI agent na magpatakbo ng code, mag-touch ng mga file, magbukas ng mga browser, at mag-hit API ay ginagawang mas malapit ang mga ito mula sa magarbong autocomplete sa isang bagay na parang isang junior engineer na may root sa isang makina. Ang dagdag na kapangyarihang iyon ang siyang dahilan kung bakit parang mahiwaga ang mga ito – at kung bakit nga ba sila mapanganib. Ang isang hindi maayos o sadyang may bug na agent ay maaaring magbura ng database, maglabas ng API key sa internet, o mag-deploy ng sirang build sa produksyon nang hindi talaga "nauunawaan" kung ano ang naging problema.

Ang tunay na tanong ay hindi na "gaano katumpak ang modelo?" kundi "ano ang maaabot nito kung ito ay mali, nalinlang, o labis na nagtitiwala sa sarili?". Ang mga execution sandbox para sa mga ahente ang sagot sa inhinyeriya: mga mahigpit na sakop na kapaligiran kung saan maaaring magbasa at magsulat ng code ang mga ahente, magpatakbo ng mga shell, maglunsad ng mga server o magpatakbo ng mga browser, habang mahigpit mong kinokontrol ang mga filesystem, network, mga kredensyal at lifecycle. Sa halip na magtiwala sa modelo, nililimitahan mo ang blast radius.

Bakit kailangan ng mga coding agent ng nakalaang execution sandbox

Ang mga modernong coding agent tulad ng Claude Code, LangChain Deep Agents, Docker's coding sandboxes at mga katulad na tool ay hindi na kumikilos na parang mga simpleng chatbot na may file access. Binabasa nila ang buong repository, ine-edit ang mga file, pinapatakbo ang mga shell command, minamanipula ang Git, sinisimulan ang mga Docker build, kinakausap ang mga external API at pinapatakbo pa ang mga buong desktop-like na kapaligiran sa pamamagitan ng isang browser. Malinaw na malinaw ang mga dokumento ng vendor tungkol dito: Ang Claude Code ay ipinakita bilang isang agile development assistant na maaaring siyasatin ang iyong codebase, gumawa ng mga pag-edit at magpatakbo ng mga command; Itinuturing ng LangChain Deep Agents ang isang sandbox backend bilang lugar kung saan nila isinasagawa ang mga shell command, pinamamahalaan ang mga filesystem at itinatalaga ang trabaho sa mga sub-agent para sa paghihiwalay.

Ang hanay ng kakayahang ito ang siyang dahilan kung bakit kapaki-pakinabang ang mga ahente na ito – at mapanganib sa operasyon. Kapag ang isang modelo ay maaaring tumakbo pytest, mag-install ng mga npm package, magbukas ng mga branch o mag-debug ng mga pagkabigo sa build, ilang tool call na lang ang kailangan para baguhin ang mga deployment script, itulak ang mga sirang imahe, ayusin ang mga CI config o i-exfiltrate ang mga token sa pamamagitan ng mga HTTP request. Ang sariling gabay sa kaligtasan ng ahente ng OpenAI at ang gawain ng NIST sa agent hijacking ay parehong nagbibigay-diin sa prompt injection: ang mga malisyosong tagubilin na nakatago sa mga file, web page o log ay maaaring tahimik na magtulak sa isang ahente sa mga aksyon na hindi mo naman sinasadyang pahintulutan.

Maraming team ang nagsisimula sa mga inosenteng daloy ng "paghingi-ng-pag-apruba" para sa bawat command, at mabilis na natutuklasan na hindi ito naaangkop sa saklaw. Ibinahagi ng Anthropic sa publiko na inaprubahan ng mga user ang 93% ng mga prompt ng pahintulot ng Claude Code; inilunsad pa nga ng Claude sandbox ng Docker ang Claude Code gamit ang --skip-permissions bilang default, umaasa sila sa runtime isolation sa halip na sunod-sunod na mga dialog. Nakakaranas ang mga tao ng pagkapagod sa pag-apruba, lalo na kapag nagpapatakbo ng maraming ahente nang sabay-sabay at nagpapalit ng konteksto sa maraming prompt. Sa puntong iyon, ang mga confirmation dialog ay nagiging seremonya, hindi isang maaasahang kontrol.

Binabago ng isang execution sandbox ang modelo ng seguridad mula sa "pagkatiwalaan ang user na basahin ang bawat prompt" patungo sa "pag-aakalang ang ilang command ay mali o magiging adversarial, at nililimitahan ang pinsalang maaari nilang gawin". Ang sandbox ay nagiging matigas na hangganan sa paligid ng kung anong mga file, proseso, network at mga sikreto ang maaaring hawakan ng ahente, kahit na ito ay minamanipula sa pamamagitan ng agarang pag-iniksyon o simpleng paggawa ng mga pagkakamali.

Mayroon ding pangunahing argumento sa pagitan ng karanasan ng developer at ng mga developer: kailangan ng mga ahente ng sapat na espasyo para aktwal na gumana. Kung mag-o-over-sandbox ka gamit ang mga bastos na restriksyon, ang mga simpleng command tulad ng mga build o test ay palaging nabibigo sa mga hindi malinaw na error sa pahintulot. Ang pinakamahusay na mga system, tulad ng mga na-deploy ng Cursor sa macOS/Linux/Windows o ng Cloudflare, Heroku at Google Cloud para sa mga naka-host na workload, ay naglalayong bigyan ang mga ahente ng pakiramdam na parang "totoong computer" sa loob ng isang masikip na perimeter.

Ang tunay na kahulugan ng isang execution sandbox para sa mga ahente

Ang isang wastong agent sandbox ay hindi lamang "sa ibang lugar para patakbuhin ang code" – ito ay isang bungkos ng mga tahasang hangganan na tumutukoy sa radius ng blast. Maaari kang mag-isip ng limang pangunahing limitasyon na paulit-ulit na lumalabas sa mga nangungunang platform tulad ng Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B o Daytona.

Una, ang hangganan ng filesystem: dapat lamang makita ng ahente ang workspace na sinasadya mong ibahagi. Inilalarawan ng mga dokumento ng LangChain ang sandbox bilang harang na naglalayo sa mga ahente mula sa mga host file; Malinaw na malinaw sa sandbox model ng Docker na ang microVM ay nakakakita lamang ng isang direktang naka-mount na direktoryo ng proyekto. Anumang bagay sa labas ng tree na iyon ay hindi nakikita o read-only, kaya hindi basta-basta makakabasa ang ahente. ~/.ssh o muling isulat ang mga configuration ng system.

Pangalawa, ang hangganan ng proseso at kernel: ang mga workload ng ahente ay hindi dapat magbahagi ng isang raw host kernel o process table. Inihihiwalay ng arkitektura ng sandbox ng Docker ang bawat kapaligiran sa sarili nitong paraan microVM at Linux kernelItinuturing ng Firecracker (na ginagamit nang palihim ng ilang provider) ang hangganan ng VM na iyon bilang unang isolation layer, pagkatapos ay nagdaragdag ng seccomp, mga namespace, mga cgroup, at mga paghihigpit na parang jail sa itaas. Nakakamit ng GKE Agent Sandbox ng Google ang katulad na epekto sa loob ng Kubernetes gamit ang gVisor: isang "sentry" layer ang humaharang sa mga system call at namamagitan sa pag-access sa pinagbabatayang node.

Pangatlo, ang hangganan ng network: kahit walang patakaran sa network, ang isang sandboxed agent ay isa pa ring data-exfiltration machine. Karamihan sa mga seryosong platform ngayon ay may default na "deny-all egress". Halimbawa, hinaharangan ng Docker Sandboxes ang HTTP/HTTPS hanggang sa tahasang pinapayagan, pinuputol ang raw TCP/UDP/ICMP, at hindi pinapayagan ang trapiko sa mga pribadong IP range at localhost maliban kung iko-configure mo ang mga exception. Dinisenyo ng Cloudflare, Google, at iba pa ang kanilang mga sandbox para ang mga outbound call ay dumadaan sa mga programmable proxy kung saan maaari kang mag-inject ng auth, mag-filter ng mga destinasyon, at mag-audit ng paggamit.

Pang-apat, ang hangganan ng kredensyal: ang pagbubunyag ng mga hilaw na sikreto sa loob ng sandbox ay dapat ituring na huling paraan, hindi bilang isang default. Inuuna ng disenyo ng Docker ang mga HTTP call sa pamamagitan ng isang host-side proxy na maaaring magkabit ng mga token o API key sa mga request nang hindi inilalagay ang mga raw value na iyon sa loob ng VM. Gayundin, naglalagay ang Cloudflare Sandbox ng mga credential sa network layer, hindi sa pamamagitan ng env vars. Sa ganoong paraan, kahit na ang prompt injection ay makakumbinsi sa agent na "i-print ang lahat ng environment variable", walang anumang kakaibang bagay na maaaring nakawin.

Panglima, ang hangganan ng lifecycle: ang mga agent workspace ay bihirang mabuhay para sa isang command lamang; kailangan nila ng tahasang semantika para sa start, pause, snapshot, fork at teardown. Inilalantad ng E2B ang mga nakahiwalay na filesystem, mga utos sa background, at mga volume na maaaring mabuhay nang lampas sa isang sandbox lifetime. Nakatuon ang Freestyle sa napakabilis na VM spin up, suspend, at resume na may snapshotting at branching ng in-memory state. Nagdaragdag ang Daytona ng mga snapshot-based sandbox kasama ang mga auto-stop, auto-archive, at auto-delete policies para mapanatili mong pangmatagalan ang ilang environment at ituring ang iba bilang disposable.

Kapag nakita mo na ang limang axes na ito – filesystem, process, network, credentials at lifecycle – mababasa mo na ang anumang sandbox product page bilang isang serye ng mga trade-off. Ang isang shared-kernel container na may malaking host mount ngunit mahigpit na mga panuntunan sa paglabas ay ibang-iba sa isang microVM na walang host mount ngunit mas mapagpahintulot na network. Para sa mga coding agent na kailangang mag-install ng mga dependency, magpatakbo ng mga browser o bumuo ng mga docker image, ang mas matibay na mga hangganan na istilo ng VM ay may posibilidad na maging mas ligtas na default.

Pag-sandbox sa macOS, Linux at Windows para sa mga lokal na coding agent

Sa mga laptop ng mga developer, hindi mo laging mapapagana ang mabibigat na microVM sandbox, kaya kinailangan ng mga team na maging malikhain sa OS-native isolation. Ang kamakailang gawain ng Cursor sa mga lokal na sandbox ay isang magandang halimbawa ng pag-angkop sa mga detalye ng macOS, Linux at Windows habang pinapanatili ang isang pinag-isang API para sa agent layer.

Sa macOS, maraming opsyon ang sinuri: App Sandbox, mga generic na container, mga full VM at isang matagal nang ginagamit ngunit "hindi na ginagamit" na teknolohiya na tinatawag na Seatbelt. Kakailanganin sana ng App Sandbox na lagdaan ang bawat binary na maaaring isagawa ng isang ahente, na lubhang nagpapataas ng pagiging kumplikado at nagbibigay pa nga ng transitive trust sa mga nabuong binary. Mapipilitan ang mga Linux container sa mga user ng macOS na gumamit ng mga binary na Linux-only, at ang mga full-blown VM ay may hindi katanggap-tanggap na boot latency at memory overhead para sa mga interactive coding flow.

Seatbelt, mapupuntahan sa pamamagitan ng sandbox-exec, ang naging praktikal na pagpipilian sa kabila ng katandaan nito. Pinapayagan ka nitong magpatakbo ng isang command sa ilalim ng isang sandbox profile na naglilimita sa buong process tree gamit ang pinong policy language: maaari mong i-whitelist o i-block ang mga partikular na syscall at limitahan ang mga read/write permission sa mga naka-target na file o directory. Dynamic na binubuo ng Cursor ang mga patakarang ito sa runtime batay sa workspace at mga setting ng admin kasama ang mga setting ng user. .cursorignore, kaya ang mga hindi pinansin na landas ay nagiging mga bawal sa loob ng sandbox.

Sa Linux, inilalantad ng kernel ang mga tamang primitive – ang seccomp para sa syscall filtering at ang Landlock para sa mga paghihigpit sa filesystem – ngunit iniiwan ang komposisyon sa espasyo ng user. Sa halip na umasa sa mga umiiral na OSS wrappers na hindi sumusuporta sa mga repo-specific ignore tulad ng .cursorignore, Pinili ng Cursor na direktang pangasiwaan ang Landlock at seccomp. Ipinagbabawal ng Seccomp ang mga mapanganib na system call; Ipinapatupad ng Landlock ang mga path-based read/write rule, na hinahayaan pa nga silang mag-overlay ng mga workspace ng user upang ang mga hindi pinansin na file ay ganap na hindi ma-access o mapalitan ng mga protektadong kopya na hindi mabasa o mababago ng mga prosesong naka-sandbox.

Isang kahusayan sa Linux ay ang pagganap: ang muling pag-mount o muling pagsusulat ng lahat ng hindi pinansin na mga file ang pinakamabagal na bahagi ng pag-setup ng sandbox. Ang macOS-style na deferred filtering na makakakita ng eksaktong file path sa oras ng syscall ay magpapasimple nito, ngunit ang seccomp-bpf ng Linux ay hindi ginagawang madali ang inspeksyon ng path na iyon, kaya mayroong tunay na kompromiso sa engineering sa pagitan ng mahigpit na paghihiwalay at bilis ng pagsisimula.

Sa Windows, ang pagbuo ng isang tunay na katumbas na native sandbox ay nananatiling mas mahirap dahil karamihan sa mga isolation primitive ay na-optimize para sa mga browser at hindi para sa pangkalahatang layunin ng dev tooling. Kasalukuyang nagpapatakbo ang Cursor ng Linux sandbox sa loob ng WSL2 para sa mga gumagamit ng Windows, na mahalagang sumasabay sa Linux isolation hanggang sa magkaroon ng mas mahuhusay na primitive. Nakikipagtulungan sila sa Microsoft upang ilantad ang mga tamang kakayahan upang, sa paglipas ng panahon, masiyahan ang mga Windows agent sa primera klaseng native sandboxing nang walang WSL bilang saklay.

Ang karaniwang pinag-isang sandbox API sa mga pamamaraang ito na partikular sa OS ay ang paggamit nito sa ibabaw. Mula sa pananaw ng ahente, mayroon lamang isang "shell tool" na may malinaw na mga kakayahan at patakaran. Sa ilalim ng hood, ang Seatbelt, Landlock/seccomp o WSL2-based isolation ay nagpapatupad ng mga patakarang iyon nang iba-iba bawat platform.

Pagtuturo sa mga ahente na maunawaan at igalang ang sandbox

Makakatulong lamang ang isang sandbox kung mahuhulaan ng ahente kung ano ang gagana sa loob nito at kung kailan nito kailangang i-escalate ang mga pribilehiyo o umalis sa kahon. Mukhang halata iyan, ngunit sa pagsasagawa, nangailangan ito ng ilang nakakagulat na malalim na prompt at pag-ulit ng disenyo ng tool para sa mga vendor na nagpapadala ng mga coding agent.

Ang unang hakbang na ginawa ng maraming pangkat ay ang pagpapabuti ng mga paglalarawan ng kagamitan, lalo na para sa pagpapatupad ng shell. Sa halip na isang generic na tool na "run_shell_command", malinaw na isinasaad ng deskripsyon kung anong mga resources ang maaaring ma-access: kung ang command ay may filesystem access, Git access, network access, o isang ganap na offline na kapaligiran depende sa configuration ng user. Idinodokumento rin nito kung paano maaaring humiling ang agent ng mga mataas na karapatan (halimbawa, upang maabot ang pampublikong internet) kung kinakailangan. Ang agarang gawaing ito sa inhinyeriya ay kadalasang napaka-empirikal: ang mga team ay nagpapatakbo ng mga karaniwang daloy ng deployment, nagmamasid kung saan nagkakamali ang modelo sa mga kakayahan, inaayos ang mga deskripsyon ng tool at inuulit.

Ang mga panloob na benchmark tulad ng "Cursor Bench" o mga katulad na eval suite ay ginagamit upang ihambing ang pagganap ng ahente nang mayroon at walang sandboxing. Isang maagang failure mode ang naging napaka-consistent: paulit-ulit na susubukan ng agent ang parehong palpak na terminal command sa halip na mapagtanto na tumatama ito sa isang sandbox restriction. Kung walang malinaw na senyales kung bakit nabigo ang command, hindi matututunan ng modelo ang pattern.

Ang solusyon ay ang tahasang pagpapakita ng mga sandbox error sa mga tool output, kadalasan ay may kasamang pagdikta kung ano ang susunod na gagawin. Kapag ang isang utos ay naharang dahil sa isang filesystem o network rule, ang shell tool ay nagsisimulang magsama ng isang maikling paliwanag tulad ng "hinarang ng sandbox: hindi pinagana ang outbound network access para sa sesyon na ito" at, sa ilang mga kaso, isang pahiwatig na ang ahente ay maaaring humingi ng mas mataas na mga pahintulot. Pagkatapos ng pagbabagong ito, ang mga ahente ay naging mas matatag: tumigil sila sa pag-uulit sa mga walang kabuluhang utos at inayos ang kanilang plano o hiniling ang kinakailangang kakayahan.

Nakatutulong ang mga offline na pagsusuri, ngunit bahagi lamang ng kwento ang isinasalaysay ng mga ito. Para malaman kung ang sandboxing ay nakakabawas sa karanasan ng user, unti-unting inilunsad ng mga team ang suporta sa sandbox sa produksyon at sinuri ang mga rate ng error, oras ng pagkumpleto, at mga channel ng feedback. Sa pagsasagawa, iniuulat ng mga vendor na isang malaking bahagi ng mga query sa mga compatible na platform ang tumatakbo na ngayon nang buo sa loob ng mga sandbox – kung saan ang mga enterprise customer tulad ng NVIDIA ay kabilang sa mga unang gumamit nito – at ang mga sandboxed agent ay aktwal na humihinto para sa pag-apruba nang humigit-kumulang 40% na mas madalang sa mga totoong workflow, na nakakatipid ng mga oras ng manu-manong pagsusuri habang binabawasan ang panganib.

Sa hinaharap, maraming interes sa mga "native sandbox agent" – mga modelong direktang sinanay sa mga limitasyon ng kanilang kapaligiran. Sa halip na ituring ang shell, browser, o filesystem bilang mga abstract tool, mauunawaan ng mga ahente na ito na sila ay nabubuhay sa isang mahigpit na saklaw ng runtime, maaaring magsulat ng mga pangmatagalang script at programa, at dapat igalang ang mga kundisyon sa hangganan tulad ng "walang outbound network" o "ang workspace ay read-only". Ang pagsasanay na iyon ay maaaring makatulong sa kanila na mas mahusay sa pagpaplano ng ligtas at mahusay na mga pagkakasunud-sunod ng mga aksyon nang hindi humahampas sa mga hindi nakikitang pader.

Mga cloud sandbox: Cloudflare, Google Cloud, Heroku at iba pa

Sa labas ng laptop ng developer, isang malaking alon ng mga tagapagbigay ng imprastraktura ang nagmamadaling mag-alok ng mga naka-host na sandbox na partikular na naka-tune para sa mga ahente ng AI. Pareho ang kanilang mga layunin – paghihiwalay, kontrol, at pagganap – ngunit ang mga kompromiso ay medyo magkaiba sa saklaw ng cloud.

Ang mga Cloudflare Sandbox, na binuo sa ibabaw ng mga Cloudflare Container at ngayon ay pangkalahatang makukuha na, ay naglalayong magmukhang at magmukhang mga ganap na development environment para sa mga ahente. Ang bawat sandbox ay isang persistent, nakahiwalay na workspace na tinatawag mo sa pangalan. Kung ito ay naka-sleep, ito ay umiikot kapag kailangan; kung ito ay naka-idle, awtomatiko itong nagsususpinde upang i-save ang compute at ipagpatuloy ang mga resume sa susunod na kahilingan. Maaaring makipag-ugnayan dito ang mga developer (o ahente) sa pamamagitan ng mga naka-type na paraan tulad ng exec, gitCheckout, writeFile, at higit pa, gamit ang JavaScript/TypeScript SDK.

Isa sa mga pinakamahirap na problema sa cloud ay ang ligtas na pagpapatotoo mula sa loob ng mga agent sandbox. Kadalasang kailangan ng mga ahente na pumunta sa mga pribadong serbisyo, ngunit hindi mo gugustuhing ang mga raw credential ay nakakalat sa mga environment variable. Nag-iinject ang Cloudflare ng mga credential sa network proxy layer, na mina-map ang mga outbound request ayon sa host sa custom logic na nag-a-attach ng mga token mula sa secure storage. Hindi nakikita ng sandbox process ang mga tunay na sikreto, ngunit naa-authenticate pa rin ang tawag. Sinusuportahan ng disenyong ito ang dynamic, identity-aware credential injection at mahusay na gumagana sa mga Workers binding.

Para sa mga workflow na maraming terminal, nagdagdag ang Cloudflare ng kumpletong karanasan sa PTY (pseudo-terminal) na nakakonekta sa pamamagitan ng WebSockets at xterm.js. Maaaring magbukas ang mga ahente at tao ng mga live na sesyon ng shell, ihinto ang mga proseso, muling kumonekta mamaya, at i-replay ang nakaraang output. Ang bawat PTY ay may sariling working directory at environment, at ang output ay naka-buffer sa server upang ang mga kliyenteng muling kumonekta ay makahabol sa mga napalampas na log.

Bukod sa raw shell access, nag-aalok din ang Cloudflare ng mga persistent na "code execution contexts" para sa mga wikang tulad ng Python, JavaScript at TypeScript. Hindi tulad ng maraming snippet runner na nagsasagawa ng bawat fragment nang hiwalay, pinapanatili ng mga kontekstong ito ang mga variable, import, at state sa iba't ibang tawag, katulad ng isang Jupyter notebook. Maaaring mag-load ng data ang mga agent sa isang tawag, i-transform ito sa isa pa, at mag-render ng mga chart o HTML table nang hindi palaging binabago at muling ini-import ang lahat.

Para sa mga gawain sa web development, sinusuportahan ng mga Cloudflare sandbox ang mga proseso sa background, health check, at mga live preview URL. Maaaring magsimula ang isang ahente npm run dev bilang trabaho sa background, bantayan ang mga log hanggang sa maging handa ang server, at pagkatapos ay ilantad ang port sa likod ng isang pampublikong preview URL. Mga pamamaraan tulad ng waitForPort() or waitForLog() hayaan ang mga ahente na magkasunod-sunod ng mga aksyon batay sa mga totoong senyales ng kahandaan sa halip na mga inosente sleep(2s) mga hula.

Ang mga daloy ng trabaho na pinapagana ng kaganapan ay nakakakuha ng tulong mula sa mga primitibong nanonood ng file na sinusuportahan ng mekanismong inotify ng Linux. Maaaring mag-subscribe ang isang ahente sa mga pagbabago sa ilalim ng /workspace/src at awtomatikong muling patakbuhin ang mga pagsubok o build kapag binago ang mga TypeScript file. Ito ang parehong feedback loop na inaasahan ng mga developer ng tao, ngunit ginawang agent-native sa pamamagitan ng mga API tulad ng sandbox.watch() at mga stream ng kaganapang ipinadala ng server.

Para maisara ang siklo ng buhay ng software, naglalabas ang Cloudflare ng mga totoong snapshot – mga VM-level state capture na maaaring maibalik sa loob ng ilang segundo mula sa R2 storage. Ang mga snapshot ay mananatili sa estado ng filesystem, OS config, mga naka-install na dependency, at mga data file; ibabalik din ng mga susunod na bersyon ang live memory state para sa agarang resume. Maaaring mag-trigger ang mga agent (o orchestrator) ng mga snapshot sa pamamagitan ng programming para sa mga checkpoint o fan-out scenario, pagkatapos ay mag-fork ng maraming sandbox mula sa parehong snapshot upang galugarin ang mga parallel hypotheses nang magkakahiwalay.

Sa usapin ng presyo, lumipat ang Cloudflare sa modelong “aktibong CPU lamang”: sisingilin ka para sa mga cycle ng CPU na aktwal na nagamit, hindi para sa idle time habang naghihintay ang mga ahente sa mga LLM. Kasama ang malalaking concurrency caps para sa "lite" at mas malalaking instances, ginagawang posible nitong magpatakbo ng isang malaking fleet ng mga ahente nang hindi nagagastos sa mga sleeping container.

Sa kabilang banda, ang GKE Agent Sandbox ng Google Cloud ay lubos na naka-integrate sa Kubernetes at gVisor. Ang ideya ay para hayaan kang magpatakbo ng mga agent workload sa mga nakahiwalay na pod sa loob ng sarili mong mga cluster. Gagawa ka ng GKE cluster (Awtomatikong mae-enable ng Autopilot ang gVisor, habang ang Standard cluster ay nangangailangan ng mga tahasang runtime class at mga gVisor-enabled node pool), pagkatapos ay magde-deploy ng Agent Sandbox controller sa pamamagitan ng mga versioned manifest.

Dalawang pangunahing pasadyang mapagkukunan ang nagtutulak sa modelo: SandboxTemplate at SandboxWarmPool. SandboxTemplate gumaganap bilang isang magagamit muli na blueprint na tumutukoy sa isang template ng pod (imahe, mga port, mga mapagkukunan, runtimeClassName: gvisor, atbp.) para sa mga sandboxed runtime, tulad ng isang Python environment. SandboxWarmPool nagpapanatili ng naka-configure na bilang ng mga pre-warmed pods na handa para sa halos agarang pagkuha, na iniiwasan ang malamig na pagsisimula kapag ang isang ahente ay nangangailangan ng isang sariwang kapaligiran sa loob ng wala pang isang segundo.

A Sandbox Router Ang serbisyo ay magsisilbing daanan para sa trapiko sa pagitan ng mga kliyente at ng mga nakahiwalay na pod na ito. Sa pag-unlad, maaari mong i-tunnel ang trapiko sa kubectl port-forward nang hindi inilalantad ang mga pampublikong IP. Sa produksyon, karaniwan mong ilalagay sa harap ng router ang wastong ingress at mTLS. Sa panig ng kliyente, nagbibigay ang Google ng isang Python "Agentic Sandbox" library na sumasaklaw sa buong lifecycle: lumikha ng isang sandbox claim mula sa isang template, maghintay hanggang sa ito ay handa na, patakbuhin ang mga utos ng shell, at linisin kapag tapos na.

Ang lahat ng ito ay "Kubernetes" pa rin sa ilalim ng hood, ngunit nakabalot sa isang magkakaugnay na kwento para sa mga runtime ng ahente. Nagbibigay ang gVisor ng process at syscall isolation, ini-standardize ng SandboxTemplate ang mga config, nilulutas ng WarmPool ang startup latency, at ginagawang maginhawa ito ng router kasama ang Python client para sa mga LLM-centric app.

Sa kabilang banda, ang Heroku ay umaasa sa isang napaka-mature na bloke ng pagbuo: mga minsanang dyno. Sa loob ng maraming taon, ang mga gumagamit ng Heroku ay nagpatakbo ng mga ad hoc na trabaho – mga migrasyon, mga script ng pagpapanatili, mga gawain ng admin – sa mga panandaliang dyno na umiikot kapag hinihingi at namamatay kapag natapos na. Muling ginamit ng Heroku ang imprastrakturang ito bilang mga sandbox ng pagpapatupad ng code, na inilunsad kasama ng kanilang mga alok na Managed Inference at Agents. Ang isang ahente ay nagsusulat ng mga snippet ng Python, Ruby, Node o Go; isinasagawa ng Heroku ang mga ito sa loob ng mga panandaliang dyno at ibinabalik ang mga resulta, na nililimitahan ang radius ng blast sa panandaliang container.

Maaari mong ma-access ang mga sandbox na ito sa pamamagitan ng mga built-in na tool sa Agents API ng Heroku o sa pamamagitan ng pag-deploy ng mga open-source na Model Context Protocol (MCP) server. Inilalantad ng mga MCP server ang mga standardized tool endpoint, kaya maaaring ituring ng mga client tulad ng Agentforce, Claude Desktop o Cursor ang sandbox ng Heroku bilang isang generic, remote code-execution backend. Sinusuportahan ng bawat server ang mga limitasyong partikular sa runtime (tulad ng max_calls bawat loop ng ahente) upang maiwasan ang mga ahente na umikot sa masikip at magastos na mga loop.

Ang Deep Agents ng LangChain ay nagdaragdag ng isa pang dimensyon sa pamamagitan ng pagsasama sa mga third-party sandbox provider tulad ng Runloop, Daytona at Modal. Diretso lang ang pattern: patuloy na tumatakbo ang Deep Agent saanman mo gusto (local o cloud), ngunit tuwing kailangan nitong magpatakbo ng mga command, gumawa ng mga file o magpatupad ng code, ang mga operasyong iyon ay ipinapasa sa isang remote sandbox. Maaaring mag-pre-load ng mga setup script ang mga environment variable, mag-clone ng mga repo, mag-install ng tooling at higit pa, para makakuha ang bawat agent ng malinis at kontroladong kapaligiran. Pagkatapos, hahawakan ng mga context manager ang paglikha at paglilinis, bagama't mariing inirerekomenda ng mga dokumento ang pagsubaybay sa mga provider dashboard para sa anumang nakalimutang matagal nang tumatakbong sandbox.

Pagganap, estado at pagsasanga: bakit mahalaga ang bilis para sa mga ahente

Ang isang mabagal ngunit napaka-secure na sandbox ay malalampasan sa pagsasagawa; ang mga tool ng developer ay mabubuhay o mamamatay sa latency. Ang mga coding agent ay hindi kumikilos na parang mga nightly batch job. Nagpapatakbo sila ng mga interactive loop: nagbabasa ng ilang code, nagpapanukala ng mga pag-edit, nagpapatakbo ng mga pagsubok, nagsusuri ng mga log, tumatawag ng mga tool, naghihintay sa mga tao, pagkatapos ay inuulit. Sa mga totoong sesyon, ginalugad din nila ang maraming sangay ng isang problema, iniiwan ang ilang ruta at bumabalik sa iba mamaya.

Ito ang dahilan kung bakit ang mga platform tulad ng Freestyle ay nahuhumaling sa mga sub-segundong VM lifecycle time at mayamang state semantics. Ang kanilang mga VM ay mga full Linux machine na may root access, systemd services, nested virtualization support, at full networking. Inaangkin ng dokumentasyon na nagbibigay ng provision sa loob ng wala pang 800 ms mula sa API call hanggang sa pagpapatakbo ng VM, nagsususpinde/nagpagpapatuloy sa loob ng wala pang 100 ms, at ang kakayahang mag-snapshot o mag-fork ng mga VM sa kalagitnaan ng pagpapatupad na may kaunting performance hit. Malinaw nilang tinatawag ang browser state bilang benepisyaryo: kung ang isang agent ay nagtulak ng isang browser sa isang interesanteng state, maaari nitong i-fork ang VM na iyon nang 20 beses mula sa parehong snapshot sa halip na muling likhain ang state na iyon mula sa simula.

Ang SandboxWarmPool ng Google para sa GKE ay nagpapahayag ng parehong ideya sa mga terminong Kubernetes: magpanatili ng isang pool ng mga pre-warmed pod para hindi magbayad ang mga ahente ng buong cold-start penalty para sa bawat bagong pagpapatakbo. Inaayos ng mga snapshot-based workspace ng Daytona kasama ang mga patakaran sa auto-stop/archive/delete ang lifecycle para sa iba't ibang uri ng session: mga aktibong dev environment, mga panandaliang eksperimento, at mga pangmatagalang baseline.

Ang pagbibigay-diin ng E2B sa mga trabaho sa background, mga mapapanood na direktoryo, mga nakahiwalay na filesystem at mga magagamit muli na volume ay isa pang aspeto ng parehong barya. Ang mga feature na ito ay nagbibigay-daan sa isang agent na panatilihing tumatakbo ang isang dev server o test harness habang sinusuri ang mga pagbabago sa code, o nagbabahagi ng isang persistent volume sa maraming ephemeral sandbox sa paglipas ng panahon. Kung wala ito, ang mga agent ay magpapadala lamang ng mga minsanang command at mawawalan ng konteksto, na siyang pumapatay sa produktibidad.

Ang isang kapaki-pakinabang na paraan upang suriin ang anumang sandbox para sa trabaho ng ahente ay ang pagtatanong ng ilang mga prangka na tanong. Maaari ba akong mag-spin ng isang bagong environment nang wala pang isang segundo? Maaari ko bang i-save at i-restore nang malinis ang state, kabilang ang mga partial build o browser session? Maaari ko bang i-fork ang state para sa parallel exploration? Maaari ko bang mapanatili ang mga workspace na pangmatagalan ngunit mahusay sa resources para sa mga "come back later" flow? Kung mas maraming "oo" na sagot ang makukuha mo, mas makakakilos ang iyong mga agent na parang mga totoong engineer sa halip na mga stateless script runner.

Mga lihim, patakaran sa network at workspace na pinagkakatiwalaan bilang tunay na control plane

Kahit na may perpektong host isolation, madaling bumuo ng isang hindi ligtas na sistema kung babalewalain mo ang mga sikreto, patakaran sa network, at tiwala sa workspace. Nakakapreskong prangka ang mga sandbox docs ng Docker sa aspetong ito. Ang microVM at ang pribadong Docker daemon nito ang bumubuo sa pangunahing trust boundary kasama ang host. Gayunpaman, sa loob ng VM na iyon, ang agent ay may ganap na root-level control, at ang shared workspace ay naka-mount na read-write. Bilang default, ang anumang pag-edit ng file ay agad na makikita sa host. Ang network egress ay tinatanggihan bilang default at pinapayagan lamang sa pamamagitan ng mga tahasang panuntunan, at ang mga HTTP request ay gumagamit ng host-side proxy na maaaring magpasok ng mga credential nang hindi inilalantad ang mga raw secret sa VM.

Nangangahulugan ito na ang paghiwalay sa host ay unang hakbang lamang; kailangan mo pa ring isipin kung ano ang magagawa ng ahente sa workspace at sa labas ng mundo. Malinaw na nagbabala ang mga dokumento ng Docker na kung ang isang ahente ay mag-eedit ng mga script, ipapatupad ito ng mga tao sa ibang pagkakataon – mga Git hook, mga CI config, mga kahulugan ng gawain ng IDE, Makefile target, package.json mga script – ang pinsala ay maaaring "tumalon" pabalik sa mga host o CI system kapag tumakbo ang mga script na iyon. Itinatampok pa nga nila na ang Git ay nakakabit sa .git/ huwag sumipot sa git diff, na ginagawang mas madali ang tahimik na pagtitiyaga ng malisyosong lohika.

Mabisa ngunit banayad ang paggamit ng credential proxying. Tinitiyak ng outbound proxy ng Docker na ang mga sikreto ay mananatili sa labas ng VM, ngunit pinapayagan pa rin ang ahente na kumilos gamit ang mga pagkakakilanlang iyon laban sa mga pinapayagang host. Ang ilang mga daloy – tulad ng pagsulat ng mga custom na env vars sa mga file tulad ng /etc/sandbox-persistent.sh – basagin ang hangganang ito sa pamamagitan ng sadyang pag-iimbak ng mga sikreto sa loob ng VM, na ligtas lamang kung tunay kang nagtitiwala sa ahente at sa sandbox.

Mahalaga ang saklaw ng configuration gaya ng mga sikreto. Binabanggit sa FAQ ng Docker na ang mga config sa antas ng gumagamit tulad ng ~/.claude or ~/.codex sa host ay hindi kinokopya sa sandbox; tanging ang project-scoped config sa shared workspace ang makikita. Pinatitibay ng mga config docs ng Anthropic na ang mga setting sa antas ng proyekto – mga tool, pahintulot, MCP server, hook – ay pinapalitan ang mga setting sa antas ng user at ibinabahagi sa iba't ibang team. Sa madaling salita, anumang mga patakaran, tagubilin, at plugin na ikakabit mo sa repo ang magiging pangunahing surface area na nakikita ng agent.

Ang gabay sa Kasanayan ng OpenAI ay nagbibigay-diin sa mga katulad na punto sa isang bahagyang kakaibang bokabularyo. Ang mga Skills (mga tool bundle) ay maaaring magdulot ng mga panganib sa pag-exfiltration ng data na hinihimok ng prompt-injection. Nagbabala ang mga dokumento laban sa direktang paglalantad ng isang hindi napili at pampublikong Skill marketplace sa mga end user, dahil ang mga malisyosong SKILL.md file ay maaaring mag-override ng mga patakaran, mag-trigger ng mga mapanirang aksyon o mag-leak ng pribadong data. Inirerekomenda nila ang pag-verify sa developer ng Skills, pag-scope sa mga ito sa mga partikular na workflow, pagtatago ng mga aksyon na may mataas na epekto sa likod ng mga karagdagang pag-apruba at pagsusuri ng patakaran, at pagtrato sa Skills bilang bahagi ng iyong threat model.

Kapag pinagsama-sama mo ang mga piraso, ang "totoong" control plane para sa mga agent sandbox ay sumasaklaw sa apat na layer. Pinoprotektahan ng Host isolation ang iyong mga makina at cluster node. Pinoprotektahan ng workspace trust ang magiging tao o CI na magpapatakbo ng mga file na ginawa sa loob ng sandbox. Pinoprotektahan ng network policy ang mga panlabas na sistema at mga pribadong pinagmumulan ng data. Pinoprotektahan ng credential management ang mga pagkakakilanlan kung saan maaaring kumilos ang ahente. Ang isang matatag na disenyo ay may mga sagot para sa lahat ng apat, hindi lamang ang una.

Bukod pa riyan, kailangan mo pa rin ng malusog na pag-aalinlangan tungkol sa agarang pag-iniksyon at pag-hijack ng ahente. Ang NIST, OWASP at OpenAI ay pawang naglalarawan ng mga variant ng iisang pattern: ang hindi mapagkakatiwalaang input – isang README, isang web page, isang log file – ay nag-e-embed ng mga malisyosong tagubilin na nagre-redirect sa gawi ng ahente. Ang retrieval-augmented generation at fine-tuning ay hindi mahiwagang nalulutas ito. Ang isang mahusay na instrumented na sandbox kasama ang mahusay na patakaran ay hindi makakapigil sa modelo na malinlang, ngunit maaari nilang lubos na mabawasan ang downside kapag ito ay nalinlang.

Nagsisimula nang i-encode ng mga cloud platform at agent runtime ang mga araling ito. Ang mga sikretong proxy, mga allowlisted outbound domain, mga repo-scoped config, mga subagent na may mas makitid na kakayahan, mga hook-based approval flow, at mga reproducible sandbox ay pawang mga piraso ng iisang palaisipan: tanggapin na ang mga modelo ay maaaring magkamali, at idisenyo ang kapaligiran upang ang gastos ng pagkakamaling iyon ay manatiling limitado.

Sa mga lokal at cloud setup, ang isang execution sandbox para sa mga ahente ay pinakamahusay na ituring bilang isang maingat na iginuhit na linya: hindi nito ginagawang mas matalino ang modelo, ginagawa nitong hindi gaanong kapaha-pahamak at mas napapansin ang mga pagkakamali nito. Gamit ang tamang timpla ng mga kontrol sa filesystem, proseso, network, sikreto, at lifecycle, kasama ang matalinong pagtuturo sa agent tungkol sa kapaligiran nito, maaari mong hayaan ang mga AI system na mag-clone ng mga repo, magpatakbo ng mga pagsubok, maglunsad ng mga browser, at kahit hawakan ang mga sistemang parang produksyon – nang hindi ibinibigay sa kanila ang mga susi sa lahat ng mahalaga sa iyo.

Nangangahulugan ito na ang pag-isolate ng host ay unang hakbang lamang; kailangan mo pa ring isipin kung ano ang magagawa ng ahente sa workspace at sa labas ng mundo, kabilang ang riesgos como remote code execution. Malinaw na nagbabala ang mga dokumento ng Docker na kung ang isang ahente ay mag-eedit ng mga script, ipapatupad ito ng mga tao sa ibang pagkakataon – mga Git hook, mga CI config, mga kahulugan ng gawain ng IDE, Makefile target, package.json mga script – ang pinsala ay maaaring "tumalon" pabalik sa host o CI system kapag tumakbo ang mga script na iyon.