Disposable VM para sa Coding Agents, Mas Ligtas

Bakit mas mainam ang disposable VM kaysa sa laptop mo

Bigyan ang isang coding agent ng disposable VM, at ang pinakamasamang maaari nitong gawin ay sirain ang isang machine na kaya mong i-rebuild sa loob ng ten minutes. May root access pa rin ang agent, nag-i-install pa rin ito ng packages, at pinapatakbo pa rin nito ang test suite nang hindi humihingi ng pahintulot sa bawat hakbang. Ang pinagkaiba ay kung saan napupunta ang pinsala. Sa laptop, nakikibahagi ang agent sa isang home directory na naglalaman ng iyong SSH keys, browser profile, mga .env file, at lahat ng repository na na-clone mo. Sa isang throwaway server, mayroon lamang itong shell, checkout, at wala nang ibang mahalagang makuha.

Iyan ang buong punto. Tungkol ito sa asymmetry, hindi sa probability. Halos palaging maayos ang isang maingat na agent sa isang maingat na laptop. Kapag nagkamali ito kahit isang beses, hindi lang isang masamang commit ang kapalit. Kailangan mong mag-restore mula sa backup, kung mayroon ka nito.

Tukuyin muna ang saklaw ng posibleng pinsala bago ito pagtalunan

Ang blast radius ay ang kabuuan ng mga bagay na maaaring maabot ng isang proseso. Para sa isang agent na tumatakbo bilang normal mong user sa karaniwan mong machine, mas malawak ang saklaw na ito kaysa sa inaakala ng karamihan.

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

Wala sa mga ito ang nangangailangan ng malicious agent. Kailangan lang nito ng isang command na buong kumpiyansang 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 pati ang local database mo, o isang kapaki-pakinabang na chmod -R 777 sa home directory. Sinasanay ang mga agent gamit ang parehong internet na nagturo sa mga command na iyon sa iba.

Hindi ang pagpapasya ng agent ang mekanismong nagpoprotekta sa iyo. Ang nagpoprotekta sa iyo ay ang machine na naglalaman ng pinsala—isang machine na handa mong mawala.

Nakakabagot ang cost math, at iyon ang punto

Ilang dolyar bawat buwan ang halaga ng isang maliit na VPS. Isang araw naman ang kailangan para mabawi ang developer laptop, at iyon na ang magandang senaryo: napansin mo agad ang problema at mayroon kang backup.

Kuwentahin ito gamit ang sarili mong mga numero. Kunin ang iyong hourly rate at i-multiply ito sa bilang ng oras na kailangan 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 halaga ng pinakamaliit na server na iniaalok ng iyong provider sa loob ng labindalawang buwan. Mas mababa sa isang insidente kada ilang taon ang break-even point, at hindi kailangang maging malubha ang insidente para lumampas dito. Sapat na ang isang buong hapon na nawala dahil sa sirang local environment para mabawi ang gastos sa isang taon.

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

Ang kalagayan noong Hulyo 2026

May tatlong tapat na sagot sa tanong na “saan dapat tumakbo ang agent,” at pare-pareho nilang pinagpapalit ang dalawang bagay: kung gaano katatag ang isolation boundary, at kung gaano karaming setup ang handa mong tanggapin.

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

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 kapag nag-exit ito, at binibigyan ito ng --network none ng ganap na walang network. Magandang default ito para sa build o test run. Dapat malinaw kung ano ang hindi nito ginagawa: nakikibahagi ang container sa host kernel, kaya maaaring makalabas ang isang attacker sa pamamagitan ng kernel bug, at nawawala ang boundary kapag nagdagdag ka ng --privileged o nag-mount ng /var/run/docker.sock upang “makagamit ng Docker” ang agent. 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 totoong kernel boundary, may provider snapshots, at patuloy itong tumatakbo kahit isara mo ang laptop. Ito ang pattern na inilalarawan ng natitirang bahagi ng guide na ito, at ito ang nakakatagal sa mahahabang agent run dahil walang pakialam ang isang job na tumatagal ng apat na oras kung umuwi ka na.

Ang VPS pattern: bigyan ang agent ng sarili nitong user

Magsimula sa isang hardened na server. Sinasaklaw ng unang sampung minuto sa bagong VPS ang mga bahaging hindi partikular sa agent: mga update, 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 ibang 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, at ina-access mo ang account gamit ang sudo -u agent o SSH key. Tandaan na sadyang wala ang agent sa grupong sudo. Ang agent na may sudo ay may root access. Maaaring basahin ng root ang mga file ng lahat ng ibang user, kaya magiging pormalidad lamang ang separation na ginawa mo. Kung talagang kailangang mag-install ng packages ang agent, dahilan iyon para bigyan ito ng buong server na pagmamay-ari nito, hindi para ibigay ang sudo sa isang shared server. Nasa least privilege para sa Linux users sa isang VPS ang pangkalahatang mga tuntunin.

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 saysay ng disposable machine kapag kinopya mo rito ang production secrets. Simple ang tuntunin: walang dapat nasa machine na iyon na credential na mamasamain mong i-rotate ngayong hapon.

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

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

Dapat ang sagot ng ikalawang command ay 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. Pagkatapos, patakbuhin ang ls -la ~/.ssh sa machine 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 access sa server ang forwarded socket upang mag-authenticate bilang ikaw. Kung ikaw lamang ang ibang user sa server, katanggap-tanggap ang trade-off na ito. Sa shared machine, hindi ito katanggap-tanggap. Mas mainam doon ang deploy key na limitado sa isang repository. Saklaw ng Mga pangunahing kaalaman sa pamamahala ng SSH key ang mga pagpipilian.

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

Limitahan kung ano ang maaaring ma-access ng agent sa network

Kalahati lamang ng boundary ang filesystem isolation. Ang kalahati naman ay egress: kung ano ang maaaring kausapin ng process. 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 nang sunod-sunod ang mga rule, 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.

Dalawang limitasyong dapat malinaw. 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 sini-filter nito, hindi mga pangalan. Ang rule na nagpapahintulot sa port 443 ay nagpapahintulot sa lahat ng HTTPS host sa internet. Sapat ito para ma-access ang model API, pero sapat din para ma-access ang isang pastebin. Para sa tunay na domain allow-list, kailangang dumaan ang traffic sa isang proxy na nagbabasa ng hinihinging hostname. Mas marami itong kailangang i-configure kaysa sa karaniwang nais ng single-developer setup. Sabihin lamang kung ano talaga ang mayroon ka: port-level egress control sa isang machine na nakahanda kang mawala.

Malinis na estado sa pagitan ng mga task

Mahalaga ang malinis na estado sa bawat task, kahit madalas itong hindi napapansin. Ang agent na gumugol ng tatlong oras sa nakaraang ticket ay maaaring mag-iwan ng mga naka-install na package, mga migration na bahagyang nailapat, stale na node_modules, at git working tree na may mga pagbabagong hindi nasuri ng iba. Aariin ng susunod na task ang lahat ng ito, at mauubos ang review budget mo sa pagtukoy kung aling problema ang kabilang sa bawat run. Mas kaunti ang iniiwang kalat ng mas makitid ang saklaw na agent, kaya ang pagsasama ng disposable machine sa skill na nagtutulak sa agent na gawin ang pinakamaliit na gumaganang pagbabago ay nagpapanatiling sapat na maliit para sa review ang diff at natitirang estado.

Ang pinakamurang 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 galawin ng anumang agent. Kapag ni-restore ang snapshot na iyon, ibinabalik ang buong system, kasama ang mga package, sa isang kilalang estado. Karamihan sa provider ay naglalantad ng feature na ito sa control panel o sa pamamagitan ng API, hindi bilang command sa mismong box, kaya nakadepende sa provider mo ang eksaktong mga hakbang. Ang mahalaga ay kunin ang snapshot habang simple at walang kakaibang laman ang machine.

Itago sa labas ng disposable machine ang anumang mahalaga sa iyo. Karaniwan, nangangahulugan ito ng pag-push ng mga branch sa halip na pag-iimbak ng mga ito nang lokal. Kung may mapunta man sa box na mami-miss mo kapag nawala, i-back up ito nang maayos gamit ang restic backups sa isang VPS. Kapaki-pakinabang lamang ang isang machine na maaari mong sirain kung ang pagsira rito ay talagang walang aberya.

Kung gusto mo ng ilang isolated environment nang hindi nagbabayad para sa ilang server, maaaring mag-host ang isang mas malaking VPS ng guest VM nang direkta. Tinutukoy ng Nested virtualisation sa isang VPS kung paano ito gumagana, pati kung paano tingnan kung pinapayagan ito ng provider mo. Parehong may epekto ang isolation sa magkabilang direksiyon. Kung mas gusto mong mag-coordinate ang dalawang agent sa iisang box kaysa manatiling hiwalay sa isa't isa, maaaring magpadala ng text ang isang Claude Code session nang direkta sa isa pa sa halip na ipaubaya sa iyo ang bawat handoff.

Kapag sapat na ang isang laptop na maingat na ginagamit

Maging tapat dito. Kapag pinalabis ang sinasabing proteksiyon ng isolation, tumitigil 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 ipinapaliwanag ng ligtas na pagpapatakbo ng Claude Code sa server kung ano talaga ang bina-block ng bawat antas nito. Kung iisang repository lang ang ginagamit mo at walang production credentials sa machine, maliit na agad ang posibleng lawak ng pinsala. Kung maikli at sinusubaybayan ang mga session ng agent, maikli rin ang exposure window.

Nagbabago ang sagot kapag nilalaktawan mo ang mga prompt. Mahalagang pag-isipan ito ngayon dahil magiging default ang auto mode ng Claude Code sa 14 August 2026, at hindi na magtatanong ang bagong installation bago mag-edit ng files o magpatakbo ng commands. Inaalis ng unattended runs, overnight jobs, at anumang workflow kung saan inaaprubahan mo ang plan at pagkatapos ay umaalis ang human check na nagsisilbing containment. Sa ganitong sitwasyon, kailangang ang machine na ang gumawa nito. Ganoon din sa anumang nagpapalawak sa abot ng agent, kabilang ang pagpapatakbo ng coding agent sa isang VPS sa maraming repository nang sabay-sabay.

Hindi talaga tungkol sa kung gaano mo pinagkakatiwalaan ang model ang desisyon. Ang mahalaga ay 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 trabaho, oo, sa dalawang kondisyon. Hindi dapat tumakbo ang container gamit ang --privileged, at hindi dapat naka-mount dito ang /var/run/docker.sock, dahil ang alinman sa mga ito ay nagbibigay sa proseso ng path patungo sa root sa 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 tunay na VM o hiwalay na server.

Kailangan ba ng agent ang sudo sa server?

Hindi, at mawawala ang isolation na binuo mo kapag binigyan mo ito ng sudo, dahil mababasa ng root ang account ng bawat ibang user sa machine. Gumawa ng agent user na walang sudo at bigyan ito ng write access sa sarili nitong work directory lamang. 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 pinaghahatian nito.

Paano ko mapapagamit sa agent ang git push nang hindi inilalagay ang SSH key ko sa machine?

I-forward ang SSH agent mo gamit ang ssh -A kapag kumokonekta ka. Dumadaan ang mga signature request sa connection habang nananatili ang private key sa laptop mo, kaya nag-a-authenticate ang ssh -T git@github.com at gumagana ang git push nang walang private key sa server. Ang dapat tandaan 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 pinaghahatian mo ng ibang tao.

Anong laki ng VPS ang kailangan ng agent?

Kadalasang pag-edit ng file, pagpapatakbo ng build, at pagpapatakbo ng test ang trabaho ng agent, kaya i-size ang machine batay sa build at hindi sa model. Tumatakbo ang hosted model sa hardware ng provider, kaya nagdaragdag ito ng network traffic at halos walang local load. Magsimula sa 2 GB RAM para sa scripting work at mag-upgrade sa 8 GB kung nagbu-build ng container ang repository o nagko-compile ng anumang malaki.

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

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