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 ang blast radius bago ito pagtalunan

Ang blast radius ay ang hanay 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 hanay na ito kaysa sa inaakala ng karamihan.

Kasama rito ang ~/.ssh/id_ed25519, na karaniwang hindi naka-encrypt dahil napagod kang paulit-ulit na ilagay ang passphrase. Kasama rin ang ~/.aws/credentials at ~/.config/gh/hosts.yml, na sadyang plain text. Kasama ang lahat ng sibling repository sa ilalim ng ~/code, kabilang ang mga may production connection string sa isang local env file. Kasama rin ang shell history mo, na maaaring may mga token na minsan mong ni-paste. Kasama rin ang network kung saan nakakonekta ang laptop mo. Kadalasan, home o office network ito na may mga serbisyong walang authentication.

Wala sa mga ito ang nangangailangan ng malisyosong agent. Isang command na mukhang tama pero mali ang kailangan. Isang rm -rf "$BUILD_DIR"/* na walang naka-set na BUILD_DIR, na nagiging /* at nakakalusot sa default na pagtanggi ng GNU rm na burahin mismo ang /. Isang git clean -xfd sa maling directory. Isang docker system prune -af --volumes na kasama nitong nabubura ang local database mo. Isang helpful na chmod -R 777 sa home directory. Sinasanay ang mga agent gamit ang parehong internet na nagturo ng mga command na iyon sa iba.

Hindi ang judgement ng agent ang mekanismong nagliligtas sa iyo. Ang mahalaga ay ang machine na may hawak ng posibleng pinsala ay 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 sitwasyon noong October 2026

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

Isang local micro VM. Ang mga tool sa kategoryang ito ay nagbo-boot ng tunay na 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 punto ng post na ito: bigyan ang coding agent ng disposable Linux VM, hindi ang laptop mo. Noong October 2026, tina-target nito ang macOS 14 at mas bago sa Apple silicon, may experimental Linux support 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 lagi mong dala ang VM, kaya kumokonsumo ito ng memory at humihinto kapag isinara mo ang laptop.

Isang container. Ang Docker ang sagot na karaniwang naka-install na sa karamihan, at tunay itong kapaki-pakinabang.

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 walang network na ibinibigay rito ng --network none. Magandang default ito para sa build o test run. Dapat malinaw kung ano ang hindi nito ginagawa: ibinabahagi ng container ang host kernel, kaya maaaring makalabas sa boundary sa pamamagitan ng kernel bug, at nawawala ang boundary kapag nagdagdag ka ng --privileged o nag-mount ng /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 laptop. Ito ang pattern na inilalarawan ng natitirang bahagi ng gabay na ito, at ito ang nananatiling gumagana para 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. Saklaw ng unang sampung minuto sa bagong VPS ang mga bahaging hindi partikular sa agent: updates, non-root login, SSH na key-only, at firewall.

Pagkatapos, gumawa ng account na para lamang sa agent. Sa ganitong paraan, hindi maaapektuhan ng pagkakamali sa loob nito 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 ~'

--disabled-password ibig sabihin, walang password na maaaring hulaan, at ina-access mo ang account gamit ang sudo -u agent o SSH key. Tandaan na sadyang hindi kabilang ang agent sa grupong sudo. Kapag may sudo ang isang agent, mayroon itong root access. Maaaring basahin ng root ang mga file ng lahat ng ibang user, kaya magiging pormalidad lamang ang separation na ginawa mo. Kung tunay na kailangang mag-install ng packages ang agent, dahilan iyon para gumamit ng isang buong server na pagmamay-ari nito, hindi para bigyan ito ng sudo sa isang shared server. Nasa least privilege para sa mga Linux user sa isang VPS ang pangkalahatang mga panuntunan.

Suriin ang boundary bago mo ito pagkatiwalaan. Bilang user na agent, subukang ilista ang home directory ng sarili nitong account:

sudo -u agent ls /home/you

Dapat mong makita ang ls: cannot open directory '/home/you': Permission denied. Kung file listing ang makita mo, nababasa ng ibang user ang iyong home directory. Dahil dito, maaaring mabasa ng agent ang anumang file rito na hindi hiwalay na naka-lock down, gaya ng world-readable na .env file. Ayusin ito gamit ang sudo chmod 700 /home/you. Hindi pinoprotektahan ng test na ito ang iyong private SSH key: binabalewala ng ssh ang private key file na maa-access ng ibang user. Kaya ang anumang key na aktuwal na gumagana para sa iyo ay hindi na mababasa ng agent, anuman ang mode ng iyong home directory.

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 ang maaabot ng agent sa network

Kalahati lamang ng boundary ang filesystem isolation. Ang kabilang kalahati ay egress: kung kanino maaaring makipag-ugnayan ang process. Maaaring i-filter ng Linux ang outbound traffic batay sa user na lumikha nito, kaya eksaktong akma 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. I-test ito bilang agent:

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

Dapat itong agad mag-fail na may curl: (7) Failed to connect to example.com error. Susundan ito ng wording na nag-iiba depende sa iyong curl version, dahil agad sumasagot ang reject rule sa halip na hayaang mag-hang ang connection. Dapat gumana pa rin ang HTTPS request sa parehong host.

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, ports at addresses ang bina-filter nito, hindi names. Ang rule na nagpapahintulot sa port 443 ay nagpapahintulot sa lahat ng HTTPS host sa internet. Sapat ito para maabot ang model API, pero sapat din para maabot ang isang pastebin. Para sa tunay na domain allow-list, kailangang dumaan ang traffic sa isang proxy na nagbabasa ng hiniling na hostname. Mas marami itong kailangang i-configure kaysa sa karaniwang gusto ng single-developer setup. Sabihin lamang ang aktuwal na saklaw: port-level egress control sa isang machine na handa mong 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 ang pag-iingat at ayos lang talaga ang laptop

Maging tapat dito, dahil kapag pinalabis ang sinasabing proteksiyon ng isolation, titigil makinig ang mga tao.

Kung sinusuri mo ang bawat command bago ito tumakbo, ayos lang 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 pinagtatrabahuhan mo at walang production credentials sa machine, maliit na agad ang blast radius. Kung maikli at mino-monitor ang mga agent session mo, maikli rin ang exposure window.

Nagbabago ang sagot kapag nilalaktawan mo ang mga prompt. Mahalaga itong pag-isipan ngayon dahil default na ang auto mode sa Claude Code at hindi ka na tinatanong ng bagong install bago ito 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 ka ang human check na nagsisilbing containment. Sa puntong iyon, kailangang machine na ang gumawa nito. Ganoon din sa anumang nagpapalawak sa abot ng agent, kabilang ang pagpapatakbo ng coding agent sa VPS sa ilang repository nang sabay-sabay.

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

FAQ

Sapat na bang isolation ang isang container para sa coding agent?

Para sa karamihan ng trabaho, oo, basta may 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 daan papunta sa root sa host. Ibinabahagi ng container ang host kernel, kaya mas mahina ang boundary nito kaysa sa virtual machine. Kung nagpapatakbo ang agent ng untrusted code na kinuha mula sa internet, mas piliin ang isang tunay na VM o hiwalay na server.

Kailangan ba ng agent ang sudo sa server?

Hindi, at binabawi ng pagbibigay rito ng sudo ang isolation na ginawa mo, dahil nababasa ng root ang bawat ibang account sa machine. Gawin ang agent user nang walang sudo at bigyan ito ng write access lamang sa sarili nitong work directory. Kung talagang kailangan ng task ang package installation, 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 para mag-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?

Karamihan sa gawain ng agent ay pag-edit ng files, pagpapatakbo ng builds, at pagpapatakbo ng tests, 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. May minimum requirement pa rin ang agent mismo: noong October 20, 2026, nakalista sa system requirements ng Claude Code ang 4 GB na RAM bilang minimum. Magsimula sa 4 GB kahit para sa scripting work at lumipat sa 8 GB kung nagbu-build ang repository ng containers o nagco-compile ng anumang substantial.

Gaano kadalas dapat sirain at i-rebuild ang machine?

Mag-rebuild kapag hindi na maipaliwanag ang state, at hindi bababa sa tuwing maaaring 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 pakiramdam mo ay magastos ang pagre-rebuild, senyales iyon na may mahalagang bagay na nasa machine na tinawag mong disposable.