Kodlama ajanları için geçici sanal makine kullanımı

Neden geçici bir sanal makine dizüstü bilgisayarınızdan daha güvenlidir

Bir kodlama aracına geçici bir sanal makine verdiğinizde, yapabileceği en kötü şey on dakikada yeniden oluşturabileceğiniz bir makineyi yok etmektir. Araç yine root yetkilerine sahip olur, paketleri yükler ve her adım için izin istemeden test paketini çalıştırır. Aradaki fark, hasarın nereye verildiğidir. Bir dizüstü bilgisayarda araç; SSH anahtarlarınız, tarayıcı profiliniz, .env dosyalarınız ve şimdiye kadar klonladığınız diğer tüm depolarla aynı ev dizinini paylaşır. Kullan-at bir sunucuda ise sadece bir kabuğa, bir checkout işlemine ve çalınmaya değer başka hiçbir şeye sahip değildir.

Tüm mesele budur ve bu, olasılıktan ziyade asimetri ile ilgili bir argümandır. Dikkatli bir araç, dikkatli bir dizüstü bilgisayarda neredeyse her zaman sorunsuz çalışır. Sorun çıkardığı o tek seferde ise maliyet, hatalı bir commit değildir. Eğer yedeğiniz varsa, yedekten geri yükleme yapmaktır.

Tartışmaya başlamadan önce etki alanını tanımlayın

Etki alanı (blast radius), bir sürecin erişebileceği öğeler kümesini ifade eder. Normal kullanıcınızla normal makinenizde çalışan bir aracı için bu küme, çoğu insanın tahmin ettiğinden çok daha geniştir.

Bu küme, parola girmekten yorulduğunuz için genellikle şifrelenmemiş olan ~/.ssh/id_ed25519 öğesini içerir. Tasarımı gereği düz metin olan ~/.aws/credentials ve ~/.config/gh/hosts.yml öğelerini kapsar. ~/code altındaki, içinde yerel bir env dosyasında üretim bağlantı dizgileri bulunanlar da dahil olmak üzere tüm kardeş depoları içerir. Bir kez yapıştırdığınız belirteçleri tutan kabuk geçmişinizi (shell history) kapsar. Ayrıca, dizüstü bilgisayarınızın bağlı olduğu, genellikle kimlik doğrulaması gerektirmeyen servislerin bulunduğu ev veya ofis ağını da içerir.

Bunların hiçbiri kötü niyetli bir aracı gerektirmez. Sadece kendinden emin bir şekilde yanlış girilmiş bir komut yeterlidir. Değişkeni / olarak genişleyen ayarlanmamış bir rm -rf, yanlış dizinde çalıştırılan bir git clean -xfd, yerel veritabanınızı da beraberinde götüren bir docker system prune -af --volumes veya ev dizininde çalıştırılan yardımsever bir chmod -R 777 buna örnektir. Aracılar, bu komutları herkese öğreten aynı internet üzerinde eğitilirler.

Sizi kurtaran mekanizma, aracının muhakeme yeteneği değildir. Hasarı tutan makinenin, kaybetmeyi göze aldığınız bir makine olmasıdır.

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

Küçük bir VPS aylık birkaç dolara mal olur. Bir geliştirici dizüstü bilgisayarını kurtarmak ise bir gün sürer; bu, durumu hemen fark ettiğiniz ve yedeğinizin olduğu iyimser senaryodur.

Hesabı kendi rakamlarınızla yapın. Saatlik ücretinizi alın; bir işletim sistemini yeniden kurmanın, bir ev dizinini geri yüklemenin, bir SSH anahtarını yenilemenin, bir kişisel erişim belirtecini (personal access token) değiştirmenin ve yirmi depoyu yeniden klonlamanın alacağı saatle çarpın. Bu sonucu, servis sağlayıcınızın sattığı en küçük sunucunun on iki aylık maliyetiyle karşılaştırın. Başabaş noktası, birkaç yılda bir gerçekleşecek tek bir olaydan daha düşüktür ve bu olayın eşiği aşması için felaket boyutunda olması gerekmez. Bozulmuş bir yerel ortam nedeniyle kaybedilen tek bir öğleden sonra, yıllık maliyeti zaten karşılar.

Hesabın ikinci kısmı anlık görüntülerdir (snapshots). Riskli bir işlemden önce alınan bir anlık görüntü, kötü bir sonucu "hayatımı geri yüklemeliyim" durumundan "geri al ve farklı bir komut dene" durumuna dönüştürür. Şu an üzerinde yazı yazdığınız dizüstü bilgisayarda bu seçenek mevcut değildir, çünkü bir makineyi çalışma masanız olarak kullanırken onun anlık görüntüsünü alamazsınız.

Temmuz 2026 itibarıyla mevcut durum

"Ajan nerede çalışmalı" sorusuna verilebilecek üç dürüst yanıt vardır ve bu yanıtlar aynı iki unsur arasında bir denge kurar: sınırın ne kadar güçlü olduğu ve ne kadar kurulum zahmetine katlanabileceğiniz.

Yerel bir mikro VM. Bu kategorideki araçlar, kendi donanımınız üzerinde gerçek bir sanal makine başlatır, deponuzu (repository) içine bağlar ve ajana içeride root yetkisi verir. clawk güncel örnektir ve sunduğu çözüm tam olarak bu yazının tezidir: kodlama ajanlarına dizüstü bilgisayarınızı değil, tek kullanımlık bir Linux VM verin. Temmuz 2026 itibarıyla Apple silikon üzerinde macOS 14 ve üzerini hedefler, Firecracker aracılığıyla deneysel Linux desteği sunar ve brew install clawkwork/tap/clawk ile kurulur. Sandbox'ı başlatıp bir ajan bağlamak için depo içinde clawk, durdurmak için clawk down ve kaldırmak için clawk destroy komutlarını çalıştırırsınız. Sınır bir hipervizördür ve oldukça güçlüdür. Kısıtlaması ise VM'in taşıdığınız makinede yaşamasıdır; bu nedenle belleğinizi tüketir ve kapağı kapattığınızda durur.

Bir container. Docker, çoğu insanın halihazırda kurulu olduğu çözümdür 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 ve --network none ona hiçbir ağ erişimi vermez; bu, bir derleme veya test çalıştırması için iyi bir varsayılandır. Bunun ne yapmadığı konusunda net olun: bir container ana makine çekirdeğini (host kernel) paylaşır, bu yüzden bir çekirdek hatası dışarı çıkış yoludur. Ayrıca --privileged eklediğinizde veya ajanın "Docker kullanabilmesi" için /var/run/docker.sock bağladığınızda sınır ortadan kalkar. Docker soketini bir container içine bağlamak, o container'a ana makine üzerinde root yetkisi vermekle eşdeğerdir.

Yeniden oluşturulabilir basit bir VPS. Yeni bir araç gerektirmez, gerçek bir çekirdek sınırı sunar, sağlayıcı snapshot'ları ile çalışır ve dizüstü bilgisayarınızı kapattığınızda çalışmaya devam eder. Bu rehberin geri kalanında açıklanan yöntem budur ve uzun süreli ajan işlemlerinde hayatta kalan tek yöntemdir; çünkü dört saat süren bir iş, sizin eve gitmiş olmanızla ilgilenmez.

VPS modeli: aracıya kendi kullanıcısını atama

Sıkılaştırılmış bir sunucu ile başlayın. Yeni bir VPS üzerinde ilk on dakika rehberi, aracıya özgü olmayan güncellemeler, root olmayan bir kullanıcı girişi, sadece anahtar tabanlı SSH ve güvenlik duvarı gibi temel adımları kapsar.

Ardından, sadece aracı için var olan bir hesap oluşturun; böylece bu hesap içindeki bir hata, sunucudaki diğer hiçbir şeye zarar veremez.

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 bir parola olmadığı anlamına gelir; hesaba sudo -u agent veya bir SSH anahtarı ile erişirsiniz. agent kullanıcısının kasten sudo grubuna dahil edilmediğine dikkat edin. sudo yetkisine sahip bir aracı root haklarına sahiptir ve root kullanıcısı diğer tüm kullanıcıların dosyalarını okuyabilir; bu durumda oluşturduğunuz yalıtım sadece göstermeliktir. Eğer aracının paket yüklemesi gerekiyorsa, bu durum paylaşımlı bir sunucuda sudo yetkisi vermek yerine, aracının sahip olduğu ayrı bir sunucu kullanılması gerektiğini gösterir. Genel kurallar VPS üzerinde Linux kullanıcıları için en düşük yetki prensibi içerisinde yer almaktadır.

Güvenmeden önce sınırları 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 çıktısını görmelisiniz. Eğer bunun yerine anahtar içeriğini görüyorsanız, ev dizininiz 755 modundadır ve yalıtım henüz gerçekleşmemiştir. Bunu sudo chmod 700 /home/you komutu ile düzeltin.

Kimlik bilgilerini makineden tamamen uzak tutun

Tek kullanımlık bir makinenin amacı, üretim sırlarınızı üzerine kopyaladığınızda boşa çıkar. Kural basittir: O kutuda, bu öğleden sonra değiştirmeyi sorun etmeyeceğiniz hiçbir kimlik bilgisi bulunmamalıdır.

Git için, bir anahtarı kopyalamak yerine SSH agent'ınızı yönlendirin. Özel anahtar dizüstü bilgisayarınızda kalır ve bağlantı üzerinden yalnızca imza istekleri geçer.

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 komutunun sunucuda hiçbir anahtar dosyası olmadan çalışacağını kanıtlar. Daha sonra kutuda ls -la ~/.ssh komutunu çalıştırın ve içinde özel anahtar bulunmadığını doğrulayın.

Agent yönlendirmenin tek bir gerçek sakıncası vardır, bunu açıkça belirtmek gerekir: Bağlı olduğunuz süre boyunca, o sunucuda root yetkisine sahip herkes yönlendirilen soketi kullanarak sizin adınıza kimlik doğrulaması yapabilir. Tek kullanıcısının siz olduğunuz bir sunucuda bu kabul edilebilir bir takastır. Paylaşımlı bir kutuda ise durum böyle değildir; tek bir depoya (repository) kısıtlanmış bir deploy key daha iyi bir çözümdür. Seçenekler SSH anahtar yönetimi temelleri bölümünde ele alınmıştır.

API anahtarları için, agent'a kendi harcama limitine sahip, agent kullanıcısının sahip olduğu ve 600 modunda saklanan bir dosya içinde kendi anahtarını verin. Makine yok edildiğinde, anahtarın sızıp sızmadığını merak etmek yerine o anahtarı iptal edin. Model harcamalarını anahtar bazında görünür tutmak, VPS üzerinde yapay zeka ajanı maliyet kontrolü içindeki rakamların öngörülebilir kalmasını sağlar.

Ajanın ağ üzerinde erişebileceği alanları sınırlandırma

Dosya sistemi izolasyonu sınırın yarısıdır. Diğer yarısı ise çıkış trafiğidir (egress): sürecin kiminle konuşmasına izin verildiği. Linux, giden trafiği onu oluşturan kullanıcıya göre filtreleyebilir; bu da 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 sondaki REJECT önceki satırların izin vermediği her şeyi yakalar. Bunu ajan 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 hatasıyla başarısız olmalıdır, çünkü reddetme kuralı bağlantının askıda kalmasına izin vermek yerine hemen yanıt verir. Aynı ana bilgisayara yapılan bir HTTPS isteği yine de başarılı olmalıdır.

İki dürüst sınırlama mevcuttur. Birincisi, sudo apt install -y iptables-persistent ve ardından sudo netfilter-persistent save ile kaydetmediğiniz sürece bu kurallar bir sonraki yeniden başlatmada kaybolur. İkincisi, bu yöntem isimleri değil, portları ve adresleri filtreler. 443 numaralı porta izin veren bir kural, internetteki her HTTPS ana bilgisayarına izin verir; bu da model API'sine ulaşmak için yeterlidir ancak aynı zamanda bir pastebin'e ulaşmak için de yeterlidir. Gerçek bir alan adı izin listesi, trafiğin istenen ana bilgisayar adını okuyan bir proxy üzerinden geçmesini gerektirir; bu da çoğu tek geliştiricili kurulumun istediğinden daha fazla altyapı demektir. Sadece sahip olduğunuz şeyi iddia edin: kaybetmeye hazır olduğunuz bir makinede port seviyesinde çıkış trafiği kontrolü.

Görevler arasında temiz duruma dönme

Görev başına temiz durum, değeri yeterince bilinmeyen bir avantajdır. Son bilet üzerinde üç saat harcayan bir aracı; yüklenmiş paketler, yarım kalmış migrasyonlar, güncelliğini yitirmiş bir node_modules ve kimsenin incelemediği değişiklikler içeren bir git çalışma ağacı bırakır. Bir sonraki görev bunların tamamını devralır ve siz inceleme bütçenizi hangi karmaşanın hangi çalıştırmaya ait olduğunu çözmek için harcarsınız. Daha dar kapsamlı bir aracı, en başta daha az kalıntı bırakır; bu nedenle tek kullanımlık bir makineyi aracıyı çalışan en küçük değişikliğe yönlendiren bir yetenek ile eşleştirmek, hem diff dosyasını hem de geriye kalan durumu incelenebilecek kadar küçük tutar.

Bunun düşük maliyetli yolu, her görev için temiz bir checkout yapmaktır.

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

Daha güçlü olan yöntem ise, makine kurulduktan hemen sonra ve herhangi bir aracı dokunmadan önce alınan bir sağlayıcı snapshot'ıdır. Bu snapshot'ı geri yüklemek, paketler dahil tüm sistemi bilinen bir duruma döndürür. Çoğu sağlayıcı bunu makine içinden bir komut yerine kontrol paneli veya API üzerinden sunar, bu nedenle izlenecek adımlar sağlayıcınıza özeldir. Buradaki disiplin, makine henüz "sıkıcı" durumdayken snapshot almaktır.

Önem verdiğiniz her şeyi tek kullanımlık makinenin dışında tutun; bu da temelde dalları yerelde biriktirmek yerine push etmek anlamına gelir. Eğer makine yine de kaybetmek istemeyeceğiniz bir şey barındırıyorsa, bunu bir VPS üzerinde restic yedekleri ile düzgün bir şekilde yedekleyin. Yok edebileceğiniz bir makine, ancak onu yok etmek gerçekten önemsiz bir işlemse kullanışlıdır.

Birden fazla sunucu için ödeme yapmadan birkaç izole ortam istiyorsanız, daha büyük bir VPS doğrudan konuk sanal makineleri barındırabilir. VPS üzerinde iç içe sanallaştırma, bunun nasıl çalıştığını ve sağlayıcınızın buna izin verip vermediğini nasıl kontrol edeceğinizi açıklar. İzolasyon burada iki yönlü çalışır; aynı makinedeki iki aracının birbirinden tamamen yalıtılmış şekilde durması yerine koordineli çalışmasını tercih ederseniz, bir Claude Code oturumu her devri sizin üzerinizden yönlendirmek yerine doğrudan diğerine metin gönderebilir.

Dizüstü bilgisayar kullanımı ne zaman gerçekten güvenlidir

Bu konuda dürüst olun; çünkü izolasyonun önemini abartmak, insanların sizi dinlemeyi bırakmasına neden olur.

Her komutu çalıştırılmadan önce gözden geçiriyorsanız, dizüstü bilgisayar kullanımı güvenlidir. İzin istemi gerçek bir denetim mekanizmasıdır ve Claude Code'u bir sunucuda güvenli şekilde çalıştırmak bölümü, her izin seviyesinin aslında neleri engellediğini açıklar. Çalışmanız, makinede hiçbir üretim kimlik bilgisi barındırmayan tek bir depodan (repository) ibaretse, olası etki alanı zaten küçüktür. Agent oturumlarınız kısa süreli ve denetim altındaysa, maruz kalma süresi de kısadır.

14 Ağustos 2026 itibarıyla Claude Code'da otomatik modun varsayılan hale gelmesi ve yeni kurulumların artık dosya düzenlemeden veya komut çalıştırmadan önce onay istememesi nedeniyle, istemleri atladığınız anda durum değişir; bu durum üzerinde şimdiden düşünmekte fayda var. Denetimsiz çalıştırmalar, gece boyunca süren işlemler ve bir planı onaylayıp başından ayrıldığınız tüm iş akışları, izolasyonu sağlayan insan denetimini ortadan kaldırır. İşte o noktada, bu denetimi makinenin yapması gerekir. Aynı durum, bir kodlama agent'ını VPS üzerinde çalıştırmak dahil olmak üzere, agent'ın erişim alanını genişleten her türlü senaryo için geçerlidir.

Karar, aslında modele ne kadar güvendiğinizle ilgili değildir. Karar, model hatalı olduğunda onun yanında nelerin durduğuyla ilgilidir.

FAQ

Bir kodlama ajanı için container izolasyonu yeterli midir?

Çoğu iş için evet, ancak iki koşulla. Container --privileged ile çalıştırılmamalı ve içine /var/run/docker.sock mount edilmemelidir; çünkü her ikisi de sürece ana makinede root yetkisine giden bir yol sağlar. Bir container, ana makine çekirdeğini paylaştığı için sınırları bir sanal makineye göre daha zayıftır. Eğer ajan internetten çekilen güvenilmez kodları çalıştırıyorsa, gerçek bir sanal makine veya ayrı bir sunucu tercih edilmelidir.

Ajanın sunucuda sudo yetkisine ihtiyacı var mı?

Hayır; sudo yetkisi vermek, oluşturduğunuz izolasyonu geçersiz kılar çünkü root kullanıcısı sunucudaki diğer tüm hesapları okuyabilir. Ajan kullanıcısını sudo yetkisi olmadan oluşturun ve ona yalnızca kendi çalışma dizini üzerinde yazma erişimi verin. Eğer görev gerçekten paket kurulumu gerektiriyorsa, ajana paylaşımlı bir makinede root yetkisi vermek yerine, tamamen kendisine ait bir makine tahsis edin.

SSH anahtarımı sunucuya koymadan ajanın git push yapmasını nasıl sağlarım?

Sunucuya bağlandığınızda SSH ajansınızı ssh -A ile yönlendirin. İmza istekleri bağlantı üzerinden iletilirken özel anahtar dizüstü bilgisayarınızda kalır; böylece ssh -T git@github.com kimlik doğrulaması yapar ve git push özel anahtar sunucuda bulunmadan çalışır. Buradaki kısıt, siz bağlıyken sunucudaki root kullanıcısının yönlendirilen soketi kullanabilmesidir; bu nedenle başkalarıyla paylaştığınız makinelerde depo kapsamlı (repository-scoped) bir deploy key kullanın.

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

Ajanın işi çoğunlukla dosya düzenlemek, derleme yapmak ve test çalıştırmaktır; bu nedenle makineyi modele göre değil, derleme ihtiyacına göre boyutlandırın. Barındırılan bir model, sağlayıcının donanımı üzerinde çalışır; bu durum ağ trafiğini artırır ancak yerel yükü neredeyse hiç etkilemez. Betik işleri için 2 GB RAM ile başlayın; eğer depo container oluşturuyorsa veya kapsamlı bir derleme yapıyorsa 8 GB RAM'e geçin.

Makineyi ne sıklıkla yok edip yeniden kurmalıyım?

Sistem durumu açıklanamaz hale geldiğinde ve en azından makinedeki bir kimlik bilgisinin açığa çıkmış olabileceği her durumda yeniden kurulum yapın. Görevler arasında temiz bir checkout yapmak günlük sapmaları yönetmenizi sağlar; ilk ajan çalıştırılmadan önce alınan bir snapshot ise geri dönebileceğiniz temiz bir sistem imajı sunar. Eğer yeniden kurulum yapmak zahmetli geliyorsa, bu durum "tek kullanımlık" olarak adlandırdığınız bir makinede önemli bir şeylerin barındığının işaretidir.