Disposable VM para sa AI coding agent

Bakit mas mainam ang disposable VM kaysa sa laptop mo

Bigyan ang coding agent ng disposable VM. Ang pinakamalalang magagawa nito ay sirain ang isang machine na maaari mong i-rebuild sa loob ng ten minutes. Mananatiling may root access ang agent. Makakapag-install pa rin ito ng packages at makakapagpatakbo ng test suite nang hindi humihingi ng pahintulot sa bawat hakbang. Ang kaibahan ay kung saan napupunta ang pinsala. Sa laptop, kasama ng agent sa iisang home directory ang iyong SSH keys, browser profile, mga .env files, at lahat ng repository na na-clone mo. Sa throwaway server, mayroon lamang itong shell, checkout, at wala nang ibang mahalagang makuha.

Iyon ang buong punto. Tungkol ito sa hindi pantay na epekto, hindi sa posibilidad. Kadalasang maayos ang isang maingat na agent sa isang maingat na laptop. Ngunit kapag nagkaproblema ito, ang kapalit ay hindi isang masamang commit. Ito ay pag-restore mula sa backup, kung mayroon ka nito.

Tukuyin ang lawak ng pinsala bago ito pagtalunan

Ang lawak ng pinsala ay ang hanay ng mga bagay na maaaring maabot ng isang proseso. Para sa agent na tumatakbo bilang normal mong user sa normal mong machine, mas malawak ang hanay na ito kaysa sa karaniwang iniisip ng mga tao.

Kasama rito ang ~/.ssh/id_ed25519, na karaniwang hindi naka-encrypt dahil nagsawa ka nang i-type ang passphrase. Kasama rin ang ~/.aws/credentials at ~/.config/gh/hosts.yml, na sadyang plain text. Kasama ang bawat sibling repository sa ilalim ng ~/code, kabilang ang mga may production connection string sa lokal na env file. Kasama rin ang shell history mo, na naglalaman ng mga token na minsan mong na-paste. Kasama rin ang network na kinabibilangan ng laptop mo, na madalas ay home o office network na may mga serbisyong walang authentication.

Wala sa mga ito ang nangangailangan ng malisyosong agent. Kailangan lamang ng isang command na mukhang tama ngunit mali. Isang rm -rf na may unset variable na nag-e-expand sa /, isang git clean -xfd sa maling directory, isang docker system prune -af --volumes na nadadamay ang lokal mong database, o isang chmod -R 777 na inilapat sa home directory. Ang mga agent ay sinanay gamit ang parehong internet na nagturo sa iba ng mga command na iyon.

Hindi ang paghatol ng agent ang mekanismong nagliligtas sa iyo. Ang nagliligtas sa iyo ay ang katotohanang ang machine na tatamaan ng pinsala ay isang machine na handa mong mawala.

Nakababagot ang cost math, at iyon ang punto

Ilang dolyar bawat buwan ang gastos sa isang maliit na VPS. Isang araw ang kailangan para mabawi ang developer laptop, at iyon na ang pinakamagandang sitwasyon: agad mong napansin ang problema at mayroon kang backup.

Kuwentahin ito gamit ang sarili mong mga numero. Kunin ang iyong hourly rate, at i-multiply ito sa mga oras na kakailanganin para mag-reinstall ng operating system, mag-restore ng home directory, mag-rotate ng SSH key, mag-rotate ng personal access token, at muling mag-clone ng dalawampung repository. Ihambing ito sa gastos ng pinakamaliit na server na ibinebenta ng iyong provider sa loob ng labindalawang buwan. Mas mababa sa isang insidente kada ilang taon ang break-even, at hindi kailangang malubha ang insidente para lumampas dito. Sapat na ang isang hapon na nawala dahil sa sirang local environment para mabayaran ang buong taon.

Ang ikalawang bahagi ng math ay snapshots. Ang snapshot bago ang isang mapanganib na run ay nagbabago sa isang masamang resulta mula sa “i-restore ang buong setup ko” tungo sa “mag-roll back at sumubok ng ibang prompt.” Hindi available ang opsyong ito sa laptop na ginagamit mo ngayon sa pagta-type, dahil hindi ka makakagawa ng snapshot ng machine habang ginagamit mo ito bilang iyong workstation.

Ang kalagayan noong Hulyo 2026

May tatlong tapat na sagot sa tanong na “saan dapat tumakbo ang agent,” at pinagpapalit nila ang parehong dalawang bagay: kung gaano katibay ang boundary, at kung gaano karaming setup ang kaya mong tanggapin.

Isang lokal na micro VM. Nagbo-boot ang mga tool sa kategoryang ito ng tunay na virtual machine sa sarili mong hardware, mina-mount dito ang iyong repository, at binibigyan ang agent ng root access sa loob nito. Ang clawk ang kasalukuyang halimbawa, at eksaktong ito ang pangunahing punto ng post na ito: bigyan ang coding agents ng disposable Linux VM, hindi ang iyong laptop. Noong Hulyo 2026, tina-target nito ang macOS 14 at mas bagong bersyon sa Apple silicon, na may experimental na suporta sa Linux sa pamamagitan ng Firecracker, at ini-install gamit ang brew install clawkwork/tap/clawk. Patakbuhin ang clawk sa loob ng repository para i-boot ang sandbox at mag-attach ng agent, ang clawk down para ihinto ito, at ang clawk destroy para alisin ito. Hypervisor ang boundary, kaya matibay ito. Ang limitasyon ay nasa machine mong dala-dala palagi ang VM, kaya nakikipag-agawan ito sa memory at humihinto kapag isinara mo ang takip ng laptop.

Isang container. Ang Docker ang sagot na naka-install na sa karamihan, at talagang kapaki-pakinabang ito.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

Itinatapon ng --rm ang container paglabas, at hindi ito binibigyan ng --network none ng anumang network access, na magandang default para sa build o test run. Dapat malinaw kung ano ang hindi nito ginagawa: nakikihati ang container sa host kernel, kaya maaaring maging daan palabas ang kernel bug, at nawawala ang boundary sa sandaling idagdag mo ang --privileged o i-mount ang /var/run/docker.sock para “magamit ng agent ang Docker.” Ang pag-mount ng Docker socket sa isang container ay katumbas ng pagbibigay sa container na iyon ng root access sa host.

Isang plain VPS na maaari mong i-rebuild. Walang bagong tool, may tunay na kernel boundary, may provider snapshots, at patuloy itong tumatakbo kapag isinara mo ang iyong laptop. Ito ang pattern na inilalarawan ng natitirang bahagi ng gabay na ito, at ito ang nananatiling gumagana sa mahahabang pagtakbo ng agent, dahil walang pakialam ang isang job na inaabot ng apat na oras kung umuwi ka na.

Pattern para sa VPS: bigyan ang agent ng sariling user

Magsimula sa isang hardened na server. Saklaw ng unang sampung minuto sa bagong VPS ang mga bahaging hindi partikular sa agent: updates, non-root login, key-only SSH, at firewall.

Pagkatapos, gumawa ng account na para lamang sa agent. Sa ganitong paraan, hindi maaapektuhan ng isang pagkakamali rito ang iba pang bahagi ng server.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

Ibig sabihin ng --disabled-password, walang password na maaaring hulaan. Maa-access mo ang account gamit ang sudo -u agent o SSH key. Tandaan na sadyang wala ang agent sa group na sudo. Kapag may sudo ang agent, mayroon itong root access. Maaaring basahin ng root ang mga file ng lahat ng ibang user. Kaya magiging pormalidad lamang ang isolation na ginawa mo. Kung tunay na kailangang mag-install ng packages ang agent, nangangahulugan ito na dapat itong magkaroon ng sarili nitong buong server, hindi na dapat bigyan ng sudo sa isang shared server. Nasa least privilege para sa mga Linux user sa VPS ang pangkalahatang mga panuntunan.

Suriin ang boundary bago mo ito pagkatiwalaan. Bilang user na agent, subukang basahin ang file na pagmamay-ari ng sarili mong account:

sudo -u agent cat /home/you/.ssh/id_ed25519

Dapat mong makita ang cat: /home/you/.ssh/id_ed25519: Permission denied. Kung key material ang nakikita mo, mode 755 ang home directory mo at hindi pa tunay ang isolation. Ayusin ito gamit ang sudo chmod 700 /home/you.

Panatilihing ganap na wala sa machine ang mga credential

Nawawala ang layunin ng isang disposable machine kung kokopyahin mo rito ang mga production secret. Simple ang panuntunan: walang nasa machine na iyon ang dapat maging credential na ayaw mong i-rotate ngayong hapon.

Para sa git, i-forward ang iyong SSH agent sa halip na kumopya ng key. Mananatili ang private key sa iyong laptop, at mga request lang para sa signature ang dadaan sa koneksyon.

ssh -A agent@203.0.113.10
ssh -T git@github.com

Dapat magbalik ng sagot ang ikalawang command na Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Pinatutunayan nito na gagana ang git push kahit walang key file sa server. Patakbuhin ang ls -la ~/.ssh sa machine pagkatapos, at tiyaking walang private key dito.

May isang mahalagang caveat ang agent forwarding, kaya sabihin ito nang malinaw: habang nakakonekta ka, maaaring gamitin ng sinumang may root sa server ang forwarded socket para mag-authenticate bilang ikaw. Sa server na ikaw lang ang ibang user, katanggap-tanggap ang trade-off na ito. Sa shared machine, hindi ito katanggap-tanggap, at mas mabuting gumamit ng deploy key na limitado sa isang repository. Saklaw ito sa Mga pangunahing kaalaman sa pamamahala ng SSH key.

Para sa mga API key, bigyan ang agent ng sarili nitong key at sariling spending limit. Iimbak ito sa file na pagmamay-ari ng user na agent, na may mode 600. Kapag winasak ang machine, i-revoke ang key na iyon sa halip na pag-isipan kung na-leak ba ito. Ang pagpapanatiling nakikita ng model spend sa bawat key ang dahilan kung bakit nananatiling predictable ang mga numero sa Pagkontrol sa gastos ng AI agent sa isang VPS.

Limitahan ang maaabot ng agent sa network

Kalahati lang ng boundary ang filesystem isolation. Ang kabilang kalahati ay egress: kung kanino maaaring kumonekta ang proseso. Maaaring i-filter ng Linux ang outbound traffic batay sa user na lumikha nito, kaya eksaktong angkop ito sa pattern na ito.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

Binabasa ang mga rule ayon sa pagkakasunod-sunod, kaya sinasaklaw ng huling REJECT ang lahat ng hindi pinayagan ng mga naunang linya. Subukan ito bilang agent:

sudo -u agent curl -sS -m 5 http://example.com

Dapat itong mabigo na may curl: (7) Failed to connect to example.com port 80: Connection refused, dahil agad na sumasagot ang reject rule sa halip na hayaang mag-hang ang connection. Dapat pa ring magtagumpay ang HTTPS request sa parehong host.

May dalawang mahalagang limitasyon. Una, mawawala ang mga rule na ito sa susunod na reboot maliban kung ise-save mo ang mga ito gamit ang sudo apt install -y iptables-persistent at pagkatapos ay sudo netfilter-persistent save. Ikalawa, mga port at address ang fina-filter nito, hindi mga pangalan. Ang rule na nagpapahintulot sa port 443 ay nagpapahintulot sa lahat ng HTTPS host sa internet. Sapat ito para maabot ang model API, ngunit sapat din para maabot ang isang pastebin. Para sa tunay na domain allow-list, kailangang dumaan ang traffic sa proxy na bumabasa sa hinihiling na hostname. Mas marami itong configuration kaysa sa karaniwang nais ng mga setup ng iisang developer. Sabihin lamang ang aktuwal mong mayroon: port-level egress control sa isang machine na handa mong mawala.

Ibalik sa malinis na estado sa pagitan ng mga task

Hindi dapat maliitin ang benepisyo ng malinis na estado sa bawat task. Ang agent na gumugol ng tatlong oras sa huling ticket ay maaaring nag-iwan ng mga naka-install na package, mga migration na bahagyang nailapat, isang lipas na node_modules, at git working tree na may mga pagbabagong hindi nasuri ng iba. Namamana ng susunod na task ang lahat ng ito, at nauubos ang review budget mo sa pagtukoy kung aling kalat ang nauugnay sa bawat run.

Ang pinakasimpleng paraan ay gumamit ng bagong checkout sa bawat task.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

Ang mas matibay na paraan ay gumawa ng provider snapshot nang isang beses, kaagad matapos i-set up ang machine at bago ito magamit ng anumang agent. Kapag ni-restore ang snapshot na iyon, ibinabalik ang buong system, kasama ang mga package, sa isang kilalang estado. Karaniwang ginagawa ito ng mga provider sa control panel o sa pamamagitan ng API, hindi bilang command sa mismong machine, kaya nakadepende sa provider mo ang eksaktong mga hakbang. Ang mahalaga ay gawin ang snapshot habang wala pang kakaiba sa machine.

Itago sa labas ng disposable machine ang anumang mahalaga sa iyo. Karaniwang nangangahulugan ito ng pag-push ng mga branch sa halip na pag-iimbak ng mga ito nang lokal. Kung may naiwan sa machine na hindi mo gustong mawala, i-back up ito nang maayos gamit ang mga restic backup sa isang VPS. Kapaki-pakinabang lang ang isang machine na maaari mong sirain kung magiging maayos talaga ang proseso ng pagsira rito.

Kung kailangan mo ng ilang hiwalay na environment nang hindi nagbabayad para sa ilang server, maaaring mag-host ang isang mas malaking VPS ng mga guest VM nang direkta. Ipinapaliwanag ng Nested virtualisation sa isang VPS kung paano ito gumagana, pati kung paano tingnan kung pinapayagan ito ng provider mo.

Kapag talagang sapat ang laptop na may wastong pag-iingat

Maging tapat tungkol dito. Kapag sobra ang pagsasabi tungkol sa isolation, maaaring tumigil ang mga tao sa pakikinig.

Kung sinusuri mo ang bawat command bago ito tumakbo, sapat na ang laptop. Tunay na control ang permission prompt, at ipinapakita ng ligtas na pagpapatakbo ng Claude Code sa server kung ano talaga ang bina-block ng bawat level nito. Kung iisang repository lang ang ginagamit mo at walang production credentials sa machine, maliit na agad ang blast radius. Kung maikli at mino-monitor ang mga agent session, maikli rin ang exposure window.

Nagbabago ang sagot kapag nilalaktawan mo ang mga prompt. Inaalis ng unattended runs, overnight jobs, at anumang workflow kung saan inaaprubahan mo ang isang plan at umaalis ang human check na nagsasagawa ng containment. Sa ganitong sitwasyon, ang machine na ang kailangang magsagawa nito. Gayundin ang anumang nagpapalawak sa reach ng agent, kabilang ang pagpapatakbo ng coding agent sa VPS sa ilang repository nang sabay-sabay.

Hindi talaga tungkol ang desisyon sa kung gaano mo pinagkakatiwalaan ang model. Tungkol ito sa kung ano ang nasa tabi nito kapag nagkamali ang model.

FAQ

Sapat na ba ang container bilang isolation para sa coding agent?

Para sa karamihan ng gawain, oo, sa ilalim ng dalawang kondisyon. Hindi dapat tumakbo ang container gamit ang --privileged, at hindi dapat naka-mount rito ang /var/run/docker.sock, dahil alinman sa mga ito ay nagbibigay sa proseso ng daan patungo sa root ng host. Ibinabahagi ng container ang kernel ng host, kaya mas mahina ang boundary nito kaysa sa virtual machine. Kung nagpapatakbo ang agent ng untrusted code na kinuha mula sa internet, mas mainam ang aktuwal na VM o hiwalay na server.

Kailangan ba ng agent ang sudo sa server?

Hindi. Mawawala ang isolation na binuo mo kapag binigyan mo ito ng sudo, dahil nababasa ng root ang lahat ng ibang account sa machine. Gumawa ng agent user na walang sudo at bigyan ito ng write access sa sarili lamang nitong work directory. Kung talagang kailangan ng task ang pag-install ng package, bigyan ang agent ng buong machine na pagmamay-ari nito sa halip na root access sa machine na ibinabahagi nito.

Paano ko pahihintulutan ang agent na mag-push sa git nang hindi inilalagay ang aking SSH key sa machine?

I-forward ang iyong SSH agent gamit ang ssh -A kapag kumokonekta ka. Dumadaan ang mga signature request sa connection habang nananatili ang private key sa iyong laptop, kaya nag-a-authenticate ang ssh -T git@github.com at gumagana ang git push nang walang private key sa server. Ang limitasyon ay maaaring gamitin ng root sa server na iyon ang forwarded socket habang nakakonekta ka, kaya gumamit ng repository-scoped deploy key sa anumang machine na ibinabahagi mo sa ibang tao.

Anong laki ng VPS ang kailangan ng agent?

Ang gawain ng agent ay pangunahing pag-edit ng files, pagpapatakbo ng builds, at pagpapatakbo ng tests, kaya i-size ang machine batay sa build, hindi sa model. Tumatakbo ang hosted model sa hardware ng provider, na nagdaragdag ng network traffic at halos walang local load. Magsimula sa 2 GB RAM para sa scripting work at lumipat sa 8 GB kung nagbu-build ng containers ang repository o nagko-compile ng anumang malaki.

Gaano kadalas kong dapat i-destroy at i-rebuild ang machine?

Mag-rebuild kapag hindi na maipaliwanag ang state, at kahit kailan kapag maaaring na-expose ang credential sa machine. Sapat ang fresh checkout sa pagitan ng mga task para sa pang-araw-araw na drift, at binibigyan ka ng snapshot na kinuha bago ang unang agent run ng malinis na system image na maaari mong balikan. Kung parang magastos ang pagre-rebuild, senyales iyon na may mahalagang data o state na nananatili sa machine na itinuring mong disposable.