Berikan Coding Agent VM Sekali Pakai

Mengapa VM sekali pakai lebih aman daripada laptop Anda

Berikan VM sekali pakai kepada coding agent. Dampak terburuk yang dapat ditimbulkannya adalah menghancurkan mesin yang dapat Anda bangun ulang dalam sepuluh menit. Agent tetap memperoleh akses root, tetap dapat menginstal paket, dan tetap dapat menjalankan test suite tanpa meminta izin pada setiap langkah. Perbedaannya terletak pada lokasi dampaknya. Pada laptop, agent berbagi home directory dengan kunci SSH, profil browser, file .env, dan semua repository lain yang pernah Anda clone. Pada server sementara, agent hanya memiliki shell, checkout, dan tidak memiliki hal lain yang layak diambil.

Itulah keseluruhan argumennya. Argumen ini membahas ketidakseimbangan dampak, bukan probabilitas. Agent yang berhati-hati pada laptop yang dikelola dengan baik hampir selalu aman. Namun, ketika terjadi kesalahan, biayanya bukan sekadar commit yang buruk. Anda harus memulihkan sistem dari backup, jika memilikinya.

Tentukan radius dampak sebelum memperdebatkannya

Radius dampak adalah kumpulan hal yang dapat dijangkau oleh suatu proses. Untuk agent yang berjalan sebagai pengguna biasa Anda pada mesin biasa Anda, kumpulan tersebut lebih besar daripada yang dibayangkan kebanyakan orang.

Kumpulan ini mencakup ~/.ssh/id_ed25519, yang biasanya tidak terenkripsi karena Anda bosan mengetik passphrase. Kumpulan ini juga mencakup ~/.aws/credentials dan ~/.config/gh/hosts.yml, yang memang dirancang sebagai teks biasa. Kumpulan ini mencakup setiap repository saudara di bawah ~/code, termasuk repository yang memiliki connection string production dalam file env lokal. Kumpulan ini juga mencakup shell history Anda, yang menyimpan token yang pernah Anda tempelkan. Kumpulan ini bahkan mencakup jaringan tempat laptop Anda terhubung, yang sering kali merupakan jaringan rumah atau kantor dengan service tanpa autentikasi.

Semua itu tidak memerlukan agent berbahaya. Yang diperlukan hanya satu perintah yang salah tetapi dijalankan dengan yakin. rm -rf "$BUILD_DIR"/* dengan BUILD_DIR yang tidak ditetapkan akan diperluas menjadi /* dan melewati penolakan default GNU rm untuk menghapus / itu sendiri, sebuah git clean -xfd di direktori yang salah, sebuah docker system prune -af --volumes yang ikut menghapus database lokal Anda, atau chmod -R 777 yang dijalankan pada home directory. Agent dilatih menggunakan Internet yang sama, yang juga mengajarkan perintah-perintah tersebut kepada semua orang.

Mekanisme yang melindungi Anda bukan penilaian agent. Perlindungan itu berasal dari fakta bahwa mesin yang menanggung dampak adalah mesin yang rela Anda kehilangan.

Perhitungan biayanya membosankan. Itu memang intinya.

VPS kecil berbiaya beberapa dolar per bulan. Memulihkan laptop developer memerlukan waktu satu hari, dan itu adalah skenario yang baik: Anda langsung menyadarinya dan memiliki backup.

Hitung dengan angka Anda sendiri. Kalikan tarif per jam Anda dengan waktu yang diperlukan untuk menginstal ulang sistem operasi, memulihkan home directory, merotasi SSH key, merotasi personal access token, dan melakukan clone ulang dua puluh repository. Bandingkan hasilnya dengan biaya server terkecil yang dijual provider Anda selama dua belas bulan. Titik impasnya berada di bawah satu insiden dalam beberapa tahun. Insiden tersebut juga tidak harus bersifat katastrofik agar melewati batas itu. Satu sore yang hilang karena lingkungan lokal yang rusak sudah cukup untuk membayar biaya satu tahun.

Bagian kedua dari perhitungannya adalah snapshot. Snapshot sebelum menjalankan tindakan berisiko mengubah hasil buruk dari "pulihkan seluruh lingkungan kerja saya" menjadi "lakukan rollback dan coba prompt lain". Opsi tersebut tidak tersedia pada laptop yang Anda gunakan untuk mengetik ini, karena Anda tidak dapat membuat snapshot mesin saat mesin itu digunakan sebagai meja kerja.

Kondisi per Oktober 2026

Ada tiga jawaban yang tepat untuk pertanyaan “di mana agent sebaiknya dijalankan”, dan semuanya mempertimbangkan dua hal yang sama: seberapa kuat isolasinya dan seberapa banyak konfigurasi yang dapat Anda toleransi.

Micro VM lokal. Tool dalam kategori ini menjalankan virtual machine sungguhan pada hardware Anda sendiri, me-mount repository ke dalamnya, dan memberi agent akses root di dalam VM. clawk adalah contoh saat ini, dan tujuan utamanya persis seperti tesis artikel ini: berikan coding agent Linux VM yang dapat dibuang, bukan laptop Anda. Per Oktober 2026, tool ini menargetkan macOS 14 dan versi lebih baru pada Apple silicon, dengan dukungan Linux eksperimental melalui Firecracker, dan dapat diinstal dengan brew install clawkwork/tap/clawk. Jalankan clawk di dalam repository untuk menjalankan sandbox dan menghubungkan agent, clawk down untuk menghentikannya, dan clawk destroy untuk menghapusnya. Batas isolasinya adalah hypervisor, yang kuat. Keterbatasannya, VM berjalan pada mesin yang Anda bawa, sehingga menggunakan memori Anda dan berhenti saat Anda menutup laptop.

Container. Docker adalah pilihan yang sudah terpasang pada kebanyakan orang, dan memang berguna.

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

--rm menghapus container saat keluar dan --network none tidak memberinya akses jaringan sama sekali. Ini merupakan default yang baik untuk build atau pengujian. Pahami hal yang tidak dilakukan pendekatan ini: container menggunakan kernel host secara bersama, sehingga bug pada kernel dapat menjadi jalan keluar, dan batas isolasinya hilang begitu Anda menambahkan --privileged atau me-mount /var/run/docker.sock agar agent dapat “menggunakan Docker”. Me-mount Docker socket ke dalam container setara dengan memberikan akses root pada host kepada container tersebut.

VPS biasa yang dapat dibangun ulang. Tidak memerlukan tool baru, memiliki batas kernel yang nyata, mendukung snapshot dari provider, dan tetap berjalan saat Anda mematikan laptop. Inilah pola yang dijelaskan di bagian lain panduan ini. Pola ini juga bertahan untuk proses agent yang berjalan lama, karena job yang memerlukan waktu empat jam tidak terpengaruh oleh Anda pulang.

Pola VPS: berikan agent akun pengguna sendiri

Mulai dari server yang sudah diperkuat keamanannya. sepuluh menit pertama pada VPS baru mencakup hal-hal yang tidak spesifik untuk agent: pembaruan, login non-root, SSH yang hanya menggunakan key, dan firewall.

Selanjutnya, buat akun yang hanya digunakan oleh agent. Dengan demikian, kesalahan di dalam akun tersebut tidak dapat memengaruhi bagian lain pada 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 berarti tidak ada password yang dapat ditebak. Anda mengakses akun tersebut dengan sudo -u agent atau SSH key. Perhatikan bahwa agent sengaja tidak menjadi anggota grup sudo. Agent dengan sudo memiliki akses root. Akun root dapat membaca file milik semua pengguna lain, sehingga pemisahan yang baru saja Anda buat hanya bersifat dekoratif. Jika agent memang perlu menginstal package, itu menjadi alasan untuk menggunakan server khusus miliknya, bukan alasan untuk memberinya sudo pada server bersama. Aturan umumnya dijelaskan dalam prinsip hak akses minimum untuk pengguna Linux pada VPS.

Periksa batas pemisahan tersebut sebelum mempercayainya. Sebagai pengguna agent, coba tampilkan isi direktori home akun Anda sendiri:

sudo -u agent ls /home/you

Anda seharusnya melihat ls: cannot open directory '/home/you': Permission denied. Jika yang terlihat adalah daftar file, direktori home Anda dapat dibaca oleh pengguna lain. Agent dapat membaca semua file di dalamnya yang tidak dibatasi secara terpisah, seperti file .env yang dapat dibaca semua pengguna. Perbaiki dengan sudo chmod 700 /home/you. SSH private key Anda tidak dilindungi oleh pengujian ini. ssh mengabaikan file private key yang dapat diakses pengguna lain. Jadi, key apa pun yang benar-benar dapat Anda gunakan sudah tidak dapat dibaca oleh agent, terlepas dari mode direktori home Anda.

Jangan simpan kredensial di mesin sama sekali

Tujuan menggunakan mesin sekali pakai menjadi sia-sia jika Anda menyalin secret produksi ke mesin tersebut. Aturannya sederhana: tidak boleh ada apa pun di mesin itu yang merupakan kredensial yang akan mengganggu Anda jika harus dirotasi sore ini.

Untuk git, teruskan SSH agent alih-alih menyalin key. Private key tetap berada di laptop Anda dan hanya permintaan tanda tangan yang melewati koneksi.

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

Perintah kedua harus menghasilkan Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Itu membuktikan bahwa git push dapat digunakan tanpa file key di server. Setelah itu, jalankan ls -la ~/.ssh di mesin tersebut dan pastikan tidak ada private key di dalamnya.

Agent forwarding memiliki satu risiko nyata yang harus dijelaskan secara langsung: selama Anda terhubung, siapa pun yang memiliki akses root di server tersebut dapat menggunakan socket yang diteruskan untuk melakukan autentikasi sebagai Anda. Pada server yang hanya memiliki Anda sebagai pengguna lain, ini merupakan kompromi yang dapat diterima. Pada mesin bersama, hal ini tidak dapat diterima, dan deploy key yang dibatasi untuk satu repository merupakan pilihan yang lebih baik. Pilihan tersebut dibahas dalam Dasar-dasar manajemen SSH key.

Untuk API key, berikan agent key tersendiri dengan batas pengeluaran tersendiri. Simpan key tersebut dalam file yang dimiliki pengguna agent dengan mode 600. Saat mesin dihancurkan, cabut key tersebut alih-alih bertanya-tanya apakah key itu telah bocor. Memantau pengeluaran model per key juga membuat angka dalam Pengendalian biaya AI agent pada VPS tetap dapat diprediksi.

Batasi akses agent ke jaringan

Isolasi filesystem hanya mencakup separuh batasan. Separuh lainnya adalah egress, yaitu tujuan yang boleh diakses proses. Linux dapat memfilter trafik keluar berdasarkan user yang membuatnya. Pendekatan ini sesuai dengan pola tersebut.

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

Aturan dibaca secara berurutan. Karena itu, REJECT terakhir akan menangani semua trafik yang tidak diizinkan oleh baris sebelumnya. Uji sebagai agent:

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

Perintah tersebut seharusnya langsung gagal dengan error curl: (7) Failed to connect to example.com. Teks pesannya dapat berbeda, bergantung pada versi curl, karena aturan penolakan memberikan respons segera dan tidak membiarkan koneksi menggantung. Permintaan HTTPS ke host yang sama seharusnya tetap berhasil.

Ada 2 batasan yang perlu diperhatikan. Pertama, aturan ini hilang setelah reboot berikutnya jika tidak disimpan menggunakan sudo apt install -y iptables-persistent, lalu sudo netfilter-persistent save. Kedua, aturan ini memfilter port dan alamat, bukan nama. Aturan yang mengizinkan port 443 berlaku untuk semua host HTTPS di internet. Aturan tersebut cukup untuk mengakses model API, tetapi juga cukup untuk mengakses pastebin. Allow-list domain yang sebenarnya memerlukan trafik melewati proxy yang membaca hostname tujuan. Konfigurasi ini lebih kompleks daripada yang biasanya diinginkan pada setup pengembang tunggal. Nyatakan hanya perlindungan yang benar-benar Anda miliki: kontrol egress pada tingkat port, di mesin yang sejak awal siap Anda kehilangan.

Kembalikan ke keadaan bersih di antara tugas

Keadaan bersih untuk setiap tugas merupakan manfaat yang sering diremehkan. Agent yang menghabiskan tiga jam untuk tiket sebelumnya dapat meninggalkan paket yang terpasang, migrasi yang hanya diterapkan sebagian, node_modules yang sudah kedaluwarsa, serta working tree git dengan perubahan yang belum ditinjau siapa pun. Tugas berikutnya mewarisi semuanya, dan Anda menghabiskan anggaran peninjauan untuk menentukan kekacauan mana yang berasal dari eksekusi tertentu. Agent yang cakupannya lebih sempit meninggalkan lebih sedikit hal sejak awal. Karena itu, memasangkan mesin disposable dengan skill yang mendorong agent untuk membuat perubahan terkecil yang berhasil menjaga diff dan keadaan sisa tetap cukup kecil untuk ditinjau.

Cara yang murah adalah membuat checkout baru untuk setiap tugas.

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

Cara yang lebih kuat adalah membuat snapshot dari provider satu kali, segera setelah mesin disiapkan dan sebelum agent menyentuhnya. Memulihkan snapshot tersebut mengembalikan seluruh sistem, termasuk paket, ke keadaan yang diketahui. Sebagian besar provider menyediakan fitur ini di control panel atau melalui API, bukan sebagai command pada mesin. Karena itu, langkah persisnya bergantung pada provider Anda. Lakukan snapshot ketika mesin masih belum memiliki perubahan yang tidak perlu.

Simpan semua hal penting di luar mesin disposable. Biasanya, ini berarti melakukan push branch dan tidak menimbunnya secara lokal. Jika mesin tersebut menyimpan sesuatu yang akan Anda perlukan, lakukan backup dengan benar menggunakan backup restic pada VPS. Mesin yang dapat Anda hancurkan hanya berguna jika penghancurannya benar-benar tidak menimbulkan masalah.

Jika Anda ingin memiliki beberapa environment yang terisolasi tanpa membayar beberapa server, satu VPS yang lebih besar dapat menjalankan guest VM secara langsung. Nested virtualisation pada VPS menjelaskan cara kerjanya, termasuk cara memeriksa apakah provider Anda mengizinkannya. Isolasi memiliki dua sisi dalam kasus ini. Jika Anda lebih memilih dua agent berkoordinasi pada mesin yang sama daripada terisolasi sepenuhnya, satu sesi Claude Code dapat mengirim teks langsung ke sesi lain sehingga setiap handoff tidak perlu selalu melalui Anda.

Kapan laptop dengan pengamanan yang tepat benar-benar memadai

Jelaskan hal ini secara jujur. Klaim berlebihan tentang isolasi membuat orang berhenti memperhatikan.

Jika Anda meninjau setiap perintah sebelum dijalankan, laptop sudah memadai. Prompt izin merupakan kontrol yang nyata, dan menjalankan Claude Code dengan aman di server menjelaskan apa saja yang sebenarnya diblokir oleh setiap tingkat izin. Jika pekerjaan Anda hanya menggunakan satu repositori dan tidak ada kredensial produksi di mana pun pada mesin tersebut, dampak potensialnya sudah kecil. Jika sesi agent Anda singkat dan diawasi, jendela paparan risikonya juga singkat.

Jawabannya berubah saat Anda melewati prompt. Hal ini perlu dipertimbangkan sekarang karena auto mode menjadi default Claude Code dan instalasi baru tidak lagi meminta konfirmasi sebelum mengedit file atau menjalankan perintah. Eksekusi tanpa pengawasan, pekerjaan semalaman, dan alur kerja apa pun yang membuat Anda menyetujui rencana lalu meninggalkannya akan menghilangkan pemeriksaan manusia yang sebelumnya membatasi dampak. Pada saat itulah mesin harus melakukan pembatasan tersebut. Hal yang sama berlaku untuk segala sesuatu yang memperluas jangkauan agent, termasuk menjalankan coding agent pada VPS di beberapa repositori sekaligus.

Keputusan ini sebenarnya bukan tentang seberapa besar Anda memercayai model. Keputusan ini tentang apa yang berada di sampingnya saat model melakukan kesalahan.

FAQ

Apakah container memberikan isolasi yang cukup untuk coding agent?

Untuk sebagian besar pekerjaan, ya, dengan dua syarat. Container tidak boleh dijalankan dengan --privileged dan tidak boleh memasang /var/run/docker.sock ke dalamnya, karena salah satunya memberikan proses jalur untuk memperoleh akses root pada host. Container menggunakan kernel host yang sama, sehingga batas isolasinya lebih lemah daripada virtual machine. Jika agent menjalankan kode tidak tepercaya yang diambil dari internet, gunakan VM sungguhan atau server terpisah.

Apakah agent memerlukan sudo pada server?

Tidak. Memberikan sudo akan membatalkan isolasi yang telah Anda buat, karena root dapat membaca akun lain pada server. Buat user agent tanpa sudo dan berikan akses tulis hanya ke direktori kerjanya sendiri. Jika tugas benar-benar memerlukan instalasi package, berikan agent satu mesin yang dikuasainya, bukan akses root pada mesin yang digunakan bersama.

Bagaimana cara agar agent dapat melakukan push ke git tanpa menaruh SSH key saya di server?

Forward SSH agent Anda dengan ssh -A saat terhubung. Permintaan tanda tangan dikirim melalui koneksi, sedangkan private key tetap berada di laptop Anda. Dengan demikian, ssh -T git@github.com dapat melakukan autentikasi dan git push dapat bekerja tanpa private key di server. Namun, root pada server tersebut dapat menggunakan socket yang di-forward selama Anda terhubung. Karena itu, gunakan deploy key yang dibatasi pada repository di mesin yang digunakan bersama orang lain.

Berapa ukuran VPS yang diperlukan agent?

Pekerjaan agent sebagian besar terdiri atas pengeditan file, menjalankan build, dan menjalankan test. Karena itu, tentukan ukuran mesin berdasarkan kebutuhan build, bukan berdasarkan model. Model hosted berjalan pada hardware milik provider, sehingga menambah network traffic dan hampir tidak menambah beban lokal. Agent itu sendiri tetap menetapkan kebutuhan minimum. Per 20 October 2026, persyaratan sistem Claude Code mencantumkan 4 GB RAM sebagai minimum. Mulai dengan 4 GB, bahkan untuk pekerjaan scripting, lalu tingkatkan menjadi 8 GB jika repository melakukan build container atau mengompilasi sesuatu yang cukup besar.

Seberapa sering saya harus menghancurkan dan membangun ulang mesin?

Bangun ulang mesin ketika kondisinya tidak lagi dapat dijelaskan, dan setidaknya setiap kali ada kemungkinan credential pada mesin telah terekspos. Checkout baru di antara tugas dapat menangani perubahan konfigurasi sehari-hari. Snapshot yang diambil sebelum agent dijalankan untuk pertama kali memberi Anda system image bersih yang dapat digunakan untuk memulihkan mesin. Jika pembangunan ulang terasa mahal, itu menandakan ada sesuatu yang penting tersimpan pada mesin yang Anda anggap disposable.