Kodlama ajanları için atılabilir VM kurulumu

Atılabilir bir VM neden dizüstü bilgisayardan daha güvenlidir?

Bir kodlama aracısına atılabilir bir VM verildiğinde, yapabileceği en kötü şey on dakika içinde yeniden oluşturabileceğiniz bir makineyi yok etmektir. Aracı hâlâ root erişimine sahip olur, hâlâ paketleri kurar ve her adım için izin istemeden test paketini çalıştırır. Fark, zararın nereye ulaştığıdır. Bir dizüstü bilgisayarda aracı; SSH anahtarlarınızın, tarayıcı profilinizin, .env dosyalarınızın ve daha önce klonladığınız tüm diğer depoların bulunduğu home dizinini sizinle paylaşır. Atılabilir bir sunucuda ise bir kabuğa, bir checkout'a ve ele geçirilmeye değer başka hiçbir şeye sahip değildir.

Bütün gerekçe budur ve olasılıktan çok asimetriyle ilgilidir. Dikkatli bir dizüstü bilgisayarda çalışan dikkatli bir aracı neredeyse her zaman sorunsuzdur. Sorun çıktığı tek seferde maliyet kötü bir commit değildir. Yedek varsa, yedekten geri yükleme işlemidir.

Tartışmadan önce etki alanını belirleyin

Etki alanı, bir işlemin erişebileceği şeyler kümesidir. Normal makinenizde normal kullanıcı olarak çalışan bir aracı için bu küme, çoğu kişinin düşündüğünden daha geniştir.

Bu küme, genellikle şifrelenmemiş olan ~/.ssh/id_ed25519 değerini içerir; çünkü parolayı girmekten yorulmuşsunuzdur. Tasarımları gereği düz metin olan ~/.aws/credentials ve ~/.config/gh/hosts.yml değerlerini içerir. ~/code altındaki tüm kardeş depoları da içerir; bunlara yerel bir env dosyasında üretim bağlantı dizeleri bulunan depolar dahildir. Bir kez yapıştırdığınız belirteçleri barındıran kabuk geçmişinizi de içerir. Ayrıca dizüstü bilgisayarınızın bağlı olduğu ağı da içerir; bu ağ çoğu zaman kimlik doğrulaması olmayan hizmetlerin bulunduğu bir ev veya ofis ağıdır.

Bunların hiçbiri kötü niyetli bir aracı gerektirmez. Kendinden emin şekilde verilen tek bir hatalı komut yeterlidir. Ayarlanmamış bir değişkenin / değerine genişlemesine neden olan rm -rf, yanlış dizinde çalıştırılan bir git clean -xfd, yerel veritabanınızı da silen bir docker system prune -af --volumes veya bir home dizininde çalıştırılan yardımcı bir chmod -R 777 buna örnektir. Aracılar, bu komutları herkese öğreten internetle aynı veriler kullanılarak eğitilir.

Sizi koruyan mekanizma, aracının muhakemesi değildir. Hasarın meydana geldiği makinenin, kaybetmeyi göze aldığınız bir makine olmasıdır.

Maliyet hesabı sıkıcıdır; amaç da budur

Küçük bir VPS ayda birkaç dolara mal olur. Bir geliştirici dizüstü bilgisayarını kurtarmak bir gün sürer. Bu, hemen fark edilmesi ve yedeğinizin bulunması durumundaki iyi senaryodur.

Hesabı kendi değerlerinizle yapın. Saatlik ücretinizi alın ve bir işletim sistemini yeniden kurmak, bir home directory'yi geri yüklemek, bir SSH key'i döndürmek, bir personal access token'ı döndürmek ve yirmi repository'yi yeniden clone etmek için gereken saatlerle çarpın. Bunu sağlayıcınızın sunduğu en küçük sunucunun on iki aylık maliyetiyle karşılaştırın. Başabaş noktası birkaç yılda birden az olay düzeyindedir. Bu eşiği aşmak için olayın felaket niteliğinde olması gerekmez. Yerel ortamın bozulması nedeniyle kaybedilen tek bir öğleden sonra bile bir yıllık maliyeti karşılar.

Hesabın ikinci kısmı snapshot'lardır. Riskli bir çalıştırmadan önce alınan bir snapshot, kötü bir sonucu "hayatımı geri yükle" durumundan "geri al ve farklı bir prompt dene" durumuna dönüştürür. Bunu şu anda yazı yazmak için kullandığınız dizüstü bilgisayarda yapamazsınız. Çünkü onu çalışma masanız olarak kullanırken makinenin snapshot'ını alamazsınız.

Temmuz 2026 itibarıyla görünüm

“Aracı nerede çalıştırmalıyım?” sorusunun üç dürüst yanıtı vardır. Bu seçenekler aynı iki unsur arasında denge kurar: sınırın ne kadar güçlü olduğu ve ne kadar kurulum işlemini kabul ettiğiniz.

Yerel bir mikro VM. Bu kategorideki araçlar kendi donanımınızda gerçek bir sanal makineyi başlatır, deponuzu bu makineye bağlar ve aracın içinde root hesabına sahip olmasını sağlar. clawk bunun güncel örneğidir. Temel yaklaşımı, kodlama aracına dizüstü bilgisayarınız yerine kullanımdan sonra atılabilecek bir Linux VM sağlamaktır. Temmuz 2026 itibarıyla Apple silicon kullanan macOS 14 ve sonraki sürümleri hedefler. Ayrıca Firecracker üzerinden deneysel Linux desteği sunar ve brew install clawkwork/tap/clawk ile yüklenir. Bir depo içinde clawk çalıştırılarak sandbox başlatılır ve bir araca bağlanılır. Durdurmak için clawk down, kaldırmak için clawk destroy çalıştırılır. Sınır, güçlü bir sınır sağlayan hypervisor katmanıdır. Sınırlama, VM'nin yanınızda taşıdığınız makinede çalışmasıdır. Bu nedenle belleğiniz için rekabet eder ve kapağı kapattığınızda durur.

Bir container. Docker, çoğu kişinin zaten yüklü olarak bulundurduğu seçenektir ve gerçekten kullanışlıdır.

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

--rm çıkışta container'ı siler. --network none ise container'a hiç ağ erişimi vermez. Bu, derleme veya test çalıştırması için iyi bir varsayılandır. Ancak bunun ne yapmadığı açıkça bilinmelidir: Bir container, host kernel'ını paylaşır. Bu nedenle kernel'daki bir hata dışarı çıkış yolu sağlayabilir. Ayrıca --privileged eklendiğinde veya aracın “Docker kullanabilmesi” için /var/run/docker.sock bağlandığında sınır ortadan kalkar. Docker socket'ini bir container'a bağlamak, o container'a host üzerinde root yetkisi vermekle eşdeğerdir.

Yeniden oluşturabileceğiniz düz bir VPS. Yeni bir araç gerektirmez. Gerçek bir kernel sınırı ve sağlayıcı snapshot'ları sunar. Dizüstü bilgisayarınızı kapattığınızda çalışmaya devam eder. Bu kılavuzun geri kalanında açıklanan yöntem budur. Uzun süre çalışan aracılar için de en uygun seçenektir. Dört saat süren bir iş, eve gitmiş olmanızı önemsemez.

VPS modeli: aracı kendi kullanıcısını verin

Güvenliği sıkılaştırılmış bir sistemle başlayın. yeni bir VPS'te ilk on dakika, araca özgü olmayan işlemleri kapsar: güncellemeler, root olmayan oturum açma, yalnızca anahtar ile SSH ve güvenlik duvarı.

Aracın yalnızca kendisi için kullanılan bir hesap oluşturun. Böylece hesap içindeki bir hata, sunucudaki başka hiçbir şeye erişemez.

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, tahmin edilecek parola olmadığı ve hesaba sudo -u agent veya bir SSH anahtarı ile erişildiği anlamına gelir. agent öğesinin kasıtlı olarak sudo grubunda olmadığını unutmayın. sudo kullanan bir aracın root yetkisi vardır. root, diğer tüm kullanıcıların dosyalarını okuyabilir. Bu nedenle az önce oluşturulan ayrım göstermelik kalır. Aracın gerçekten paket yüklemesi gerekiyorsa, bunun gerekçesi paylaşılan bir sunucuda ona sudo vermek değil, sahip olduğu ayrı bir sunucu kullanmaktır. Genel kurallar VPS'te Linux kullanıcıları için en az ayrıcalık bölümünde açıklanır.

Güvenmeden önce sınırı kontrol edin. agent kullanıcısı olarak kendi hesabınıza ait bir dosyayı okumayı deneyin:

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

cat: /home/you/.ssh/id_ed25519: Permission denied görmeniz gerekir. Bunun yerine anahtar materyali görüyorsanız, giriş dizininizin izinleri 755'tir ve yalıtım henüz gerçek değildir. sudo chmod 700 /home/you ile düzeltin.

Kimlik bilgilerini makineden tamamen uzak tutma

Üretim ortamına ait gizli bilgileri geçici bir makineye kopyalarsanız, bu makinenin geçici olmasının amacı ortadan kalkar. Kural basittir: Bu makinede, bugün öğleden sonra döndürmek istemeyeceğiniz hiçbir kimlik bilgisi bulunmamalıdır.

git için bir anahtarı kopyalamak yerine SSH agent yönlendirmesini kullanın. Özel anahtar dizüstü bilgisayarınızda kalır ve bağlantı üzerinden yalnızca imza istekleri gönderilir.

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

İkinci komut Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. yanıtını vermelidir. Bu, git push işleminin sunucuda anahtar dosyası bulunmadan çalışacağını kanıtlar. Ardından makinede ls -la ~/.ssh komutunu çalıştırın ve içinde özel anahtar bulunmadığını doğrulayın.

Agent yönlendirmenin gerçek bir sakıncası vardır ve bu açıkça belirtilmelidir: Bağlı olduğunuz sırada, bu sunucuda root yetkisine sahip herkes, yönlendirilen soketi kullanarak sizin kimliğinizle kimlik doğrulaması yapabilir. Sunucudaki diğer tek kullanıcı sizseniz bu kabul edilebilir bir ödündür. Paylaşılan bir makinede ise kabul edilemez; tek bir repository ile sınırlı bir deploy key daha doğru çözümdür. Seçenekler SSH anahtarı yönetiminin temelleri bölümünde açıklanmıştır.

API anahtarları için agent'a kendi harcama sınırına sahip ayrı bir anahtar verin. Bu anahtarı, agent kullanıcısının sahibi olduğu ve mode 600 izinlerine sahip bir dosyada saklayın. Makine yok edildiğinde, anahtarın sızıp sızmadığını düşünmek yerine bu anahtarı iptal edin. Model harcamasını anahtar bazında görünür tutmak, VPS üzerinde AI agent maliyet denetimi bölümündeki sayıların öngörülebilir kalmasını da sağlar.

Aracının ağda erişebileceği alanı sınırlama

Dosya sistemi yalıtımı sınırın yarısıdır. Diğer yarısı çıkış trafiğidir: işlemin hangi hedeflerle iletişim kurmasına izin verildiği. Linux, giden trafiği oluşturan kullanıcıya göre filtreleyebilir. Bu, tam olarak bu modele uyar.

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

Kurallar sırayla okunur. Bu nedenle son REJECT, önceki satırların izin vermediği her şeyi yakalar. Bunu aracı olarak test edin:

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

Bu işlem curl: (7) Failed to connect to example.com port 80: Connection refused ile başarısız olmalıdır. Bunun nedeni, reject kuralının bağlantının zaman aşımına uğramasını beklemek yerine hemen yanıt vermesidir. Aynı host'a yönelik bir HTTPS isteği yine de başarılı olmalıdır.

İki önemli sınırlama vardır. İlk olarak, bu kurallar kaydedilmedikçe bir sonraki yeniden başlatmada kaybolur. Kuralları sudo apt install -y iptables-persistent ve ardından sudo netfilter-persistent save ile kaydedin. İkinci olarak, bu yöntem adları değil, portları ve adresleri filtreler. 443 portuna izin veren bir kural, internetteki tüm HTTPS host'larına izin verir. Bu, model API'sine erişmek için yeterlidir; aynı zamanda bir pastebin'e erişmek için de yeterlidir. Gerçek bir domain allow-list için trafiğin, istenen hostname'i okuyabilen bir proxy üzerinden geçirilmesi gerekir. Bu, çoğu tek geliştiricili kurulumun tercih etmeyeceği kadar fazla ek bileşen gerektirir. Yalnızca gerçekten sahip olduğunuz kontrolü iddia edin: kaybetmeye hazırlıklı olduğunuz bir makinede port düzeyinde çıkış trafiği denetimi.

Görevler arasında temiz duruma sıfırlama

Her görev için temiz bir durumun sağlanması, yeterince önemsenmeyen bir avantajdır. Bir önceki bileti üç saat boyunca ele alan bir agent; yüklenmiş paketler, kısmen uygulanmış migration'lar, eski bir node_modules ve kimsenin incelemediği değişiklikler içeren bir git çalışma ağacı bırakmış olabilir. Sonraki görev bunların tamamını devralır ve inceleme sürenizi hangi karmaşanın hangi çalıştırmaya ait olduğunu belirlemeye harcarsınız.

En düşük maliyetli yöntem, her görev için yeni bir checkout oluşturmaktır.

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

Daha sağlam yöntem, makine kurulduktan hemen sonra ve herhangi bir agent makineye erişmeden önce bir provider snapshot'ı almaktır. Bu snapshot'ın geri yüklenmesi, paketler dahil tüm sistemi bilinen bir duruma döndürür. Çoğu provider bu işlemi makine üzerinde bir komut olarak değil, control panel veya API üzerinden sunar. Bu nedenle kesin adımlar provider'a göre değişir. Önemli olan, makine henüz hiçbir değişiklik içermiyorken snapshot almaktır.

Önem verdiğiniz her şeyi disposable makinenin dışında tutun. Bu çoğunlukla branch'leri yerel olarak biriktirmek yerine push etmek anlamına gelir. Makinede kaybetmek istemeyeceğiniz bir şey bulunursa VPS üzerinde restic yedekleri ile uygun şekilde yedekleyin. Yok edebileceğiniz bir makine, yalnızca onu yok etmek gerçekten sorunsuzsa işe yarar.

Birden fazla server için ödeme yapmadan birkaç yalıtılmış ortam istiyorsanız, daha büyük bir VPS doğrudan guest VM'leri barındırabilir. VPS üzerinde iç içe sanallaştırma, provider'ınızın buna izin verip vermediğini nasıl denetleyeceğiniz dahil olmak üzere bunun nasıl çalıştığını açıklar.

Bir dizüstü bilgisayarın gerçekten yeterli olduğu durumlar

Bu konuda dürüst olunmalıdır. İzolasyonu olduğundan fazla göstermek, insanların dinlemeyi bırakmasına neden olur.

Her komut çalıştırılmadan önce inceleniyorsa bir dizüstü bilgisayar yeterlidir. İzin istemi gerçek bir denetimdir ve Claude Code'u bir sunucuda güvenli şekilde çalıştırma başlıklı bölümde, her izin düzeyinin gerçekte neleri engellediği açıklanmaktadır. Çalışma, makinede hiçbir production kimlik bilgisi bulunmayan tek bir repository ile sınırlıysa etki alanı zaten küçüktür. Agent oturumları kısa ve gözetimli ise maruz kalma süresi de kısadır.

İstemler atlandığı anda durum değişir. Gözetimsiz çalıştırmalar, gece boyunca çalışan işler ve planı onaylayıp başından ayrılınan tüm iş akışları, sınırlamayı sağlayan insan denetimini ortadan kaldırır. Bu noktada denetimi makinenin sağlaması gerekir. Aynı durum, agent'ın erişim alanını genişleten işlemler için de geçerlidir. Buna aynı anda birden fazla repository üzerinde bir coding agent'ı VPS üzerinde çalıştırma da dahildir.

Karar, modelin ne kadar güvenilir olduğuyla ilgili değildir. Asıl konu, model hata yaptığında yanında hangi korumaların bulunduğudur.

FAQ

Bir container, coding agent için yeterli yalıtım sağlar mı?

Çoğu iş için evet; ancak iki koşul vardır. Container --privileged ile çalıştırılmamalı ve /var/run/docker.sock container içine bağlanmamalıdır. Bunlardan herhangi biri, sürecin ana makinedeki root hesabına ulaşmasını sağlar. Container, ana makinenin kernel'ını paylaşır. Bu nedenle sınır, bir sanal makineye göre daha zayıftır. Agent internetten alınan güvenilmeyen kodu çalıştırıyorsa gerçek bir VM veya ayrı bir sunucu tercih edilmelidir.

Agent'ın sunucuda sudo yetkisine ihtiyacı var mı?

Hayır. Sudo yetkisi vermek oluşturulan yalıtımı ortadan kaldırır. Çünkü root, makinedeki diğer tüm hesapları okuyabilir. Agent kullanıcısı sudo olmadan oluşturulmalı ve yalnızca kendi çalışma dizinine yazma erişimi verilmelidir. Görev gerçekten paket kurulumu gerektiriyorsa agent'a, paylaşılan bir makinede root yetkisi vermek yerine sahip olduğu ayrı bir makine tahsis edilmelidir.

SSH key'imi makineye koymadan agent'ın git'e push yapmasını nasıl sağlarım?

Bağlanırken SSH agent'ınızı ssh -A ile iletin. İmza istekleri bağlantı üzerinden gönderilirken private key dizüstü bilgisayarınızda kalır. Böylece ssh -T git@github.com kimlik doğrulaması yapar ve git push, sunucuda private key olmadan çalışır. Ancak siz bağlıyken sunucudaki root, iletilen socket'i kullanabilir. Bu nedenle başkalarıyla paylaşılan makinelerde repository kapsamlı bir deploy key kullanılmalıdır.

Agent'ın ne büyüklükte bir VPS'e ihtiyacı vardır?

Agent çalışmaları çoğunlukla dosyaları düzenleme, build çalıştırma ve test çalıştırmadan oluşur. Bu nedenle makine, model için değil build için boyutlandırılmalıdır. Hosted model, sağlayıcının donanımında çalışır. Bu durum network traffic oluşturur ve yerel yükü neredeyse hiç artırmaz. Betik çalışmaları için 2 GB RAM ile başlanmalı; repository container'lar oluşturuyor veya kapsamlı derleme yapıyorsa 8 GB RAM'e geçilmelidir.

Makine ne sıklıkla silinip yeniden oluşturulmalıdır?

Durum açıklanamaz hâle geldiğinde ve en azından makinedeki bir credential'ın açığa çıkmış olabileceği her durumda yeniden oluşturulmalıdır. Görevler arasında temiz bir checkout almak, günlük değişimleri yönetmek için yeterlidir. İlk agent çalıştırılmadan önce alınan bir snapshot ise geri dönülebilecek temiz bir sistem imajı sağlar. Yeniden oluşturma pahalı görünüyorsa bu, disposable olarak adlandırılan bir makinede önemli bir şeyin tutulduğunun göstergesidir.