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 hayal ettiğinden çok daha geniştir.

Bu küme, parola girmekten yorulduğunuz için genellikle şifrelenmemiş halde tutulan ~/.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, yerel bir env dosyasında üretim bağlantı dizgileri barındıranlar da dahil olmak üzere tüm kardeş depoları içerir. Bir kez yapıştırdığınız belirteçleri (token) 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 kendine aşırı güvenen hatalı bir komut yeterlidir. BUILD_DIR ayarlanmamış bir rm -rf "$BUILD_DIR"/* komutu (bu komut /* değerine genişler ve GNU rm'in / dizinini silmeyi reddeden varsayılan korumasını aşar), 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 komutu felakete yol açabilir. Aracılar, bu komutları herkese öğreten aynı internet verisiyle eğitilirler.

Sizi kurtaran mekanizma, aracının muhakeme yeteneği değildir. Sizi kurtaran şey, hasarın gerçekleştiği makinenin zaten kaybetmeyi göze aldığınız bir cihaz 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.

Ekim 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 şu anki ö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. Ekim 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. Korumalı alanı (sandbox) başlatmak ve bir ajan eklemek 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 (hypervisor) ve bu oldukça güçlüdür. Sınırlaması ise VM'in yanınızda taşıdığınız makinede yaşamasıdır; bu nedenle belleğiniz için rekabet eder ve kapağı kapattığınızda durur.

Bir konteyner. Docker, çoğu insanın halihazırda kurulu olan çözümüdü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 konteyneri 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 konteyner ana makine çekirdeğini (host kernel) paylaşır, bu yüzden bir çekirdek hatası dışarı çıkış yolu olabilir ve --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 konteynere bağlamak, o konteynere 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ı sağlar, sağlayıcı anlık görüntüleri (snapshots) sunar ve dizüstü bilgisayarınızı kapattığınızda çalışmaya devam eder. Bu rehberin geri kalanında açıklanan model budur ve uzun süreli ajan işlemlerine dayanabilen tek modeldir; çünkü dört saat süren bir iş, sizin eve gitmiş olmanızla ilgilenmez.

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

Güvenliği sıkılaştırılmış bir sunucu ile başlayın. Yeni bir VPS üzerinde ilk on dakika rehberi, aracıya özel 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 kullanımı, tahmin edilecek bir parola olmadığı anlamına gelir ve 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 nedenle oluşturduğunuz ayrım sadece göstermeliktir. Eğer aracı gerçekten paket yüklemek zorundaysa, bu durum paylaşımlı bir sunucuda ona sudo vermek yerine, kendisine ait bir sunucu kullanılması gerektiğini gösterir. Genel kurallar VPS üzerinde Linux kullanıcıları için en düşük yetki prensibi içinde yer almaktadır.

Güvenmeden önce sınırları kontrol edin. agent kullanıcısı olarak, kendi hesabınızın ana dizinini listelemeyi deneyin:

sudo -u agent ls /home/you

ls: cannot open directory '/home/you': Permission denied çıktısını görmelisiniz. Eğer bunun yerine bir dosya listesi görüyorsanız, ana dizininiz diğer kullanıcılar tarafından okunabilir durumdadır ve aracı, ayrı olarak kısıtlanmamış her şeyi (örneğin herkesin okuyabildiği bir .env dosyası gibi) okuyabilir. Bunu sudo chmod 700 /home/you ile düzeltin. Bu test, özel SSH anahtarınızı korumayı amaçlamaz; ssh, diğer kullanıcıların erişebildiği bir özel anahtar dosyasını yok sayar. Bu nedenle, sizin için çalışan herhangi bir anahtar, ana dizininizin modu ne olursa olsun zaten agent tarafından okunamaz durumdadır.

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 kimlik bilgileri dışında hiçbir şey 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 iletilir.

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 aracının sunucuda herhangi bir anahtar dosyası olmadan çalışacağını kanıtlar. Daha sonra kutuda ls -la ~/.ssh komutunu çalıştırın ve içinde özel bir 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, ajana kendi harcama limiti olan ve agent kullanıcısının 600 modunda sahip olduğu bir dosyada saklanan ayrı bir anahtar verin. Makine yok edildiğinde, anahtarın sızıp sızmadığını düşünmek yerine o anahtarı iptal edin. Model harcamalarını anahtar bazında görünür tutmak, Bir VPS üzerinde yapay zeka ajanı maliyet kontrolü bölümündeki rakamların öngörülebilir kalmasını sağlayan yöntemdir.

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 son REJECT kuralı, önceki satırların izin vermediği her şeyi yakalar. Bunu ajan kullanıcısı olarak test edin:

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

Bu işlem, bağlantının askıda kalmasına izin vermek yerine reddetme kuralı anında yanıt verdiği için, curl: (7) Failed to connect to example.com hatası ve ardından curl sürümünüze göre değişen bir ifadeyle derhal başarısız olmalıdır. Aynı ana bilgisayara yapılan bir HTTPS isteği yine de başarılı olmalıdır.

İki dürüst sınırlama. Birincisi, bu kurallar sudo apt install -y iptables-persistent ve ardından sudo netfilter-persistent save ile kaydetmediğiniz sürece 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, 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ın güvenli olduğu durumlar

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

Çalıştırılmadan önce her komutu 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 çalıştırma rehberi, bu istemin her seviyesinin neleri engellediğini açıklar. Çalışmanız tek bir depodan oluşuyorsa ve makinede hiçbir üretim kimlik bilgisi (production credential) bulunmuyorsa, olası bir hata durumunda etki alanı zaten küçüktür. Ajan oturumlarınız kısa süreli ve denetim altındaysa, maruz kalma süresi de kısadır.

Auto mode'un Claude Code'da varsayılan olması ve yeni kurulumların dosya düzenlemeden veya komut çalıştırmadan önce artık onay istememesi nedeniyle, bu durumun risklerini şimdiden değerlendirmek gerekir. İstemleri atladığınız anda cevap değişir. Gözetimsiz ç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 VPS üzerinde kodlama ajanı çalıştırmak dahil olmak üzere, ajanın erişim alanını genişleten her türlü senaryo için geçerlidir.

Karar, modele ne kadar güvendiğinizle ilgili değildir. Model hatalı bir işlem yaptığında, yanında neyin durduğuyla ilgilidir.

FAQ

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

Çoğu iş için evet, ancak iki şartla. 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. Container, ana makinenin çekirdeğini paylaştığı için sınırları bir sanal makineye göre daha zayıftır. Eğer ajan internetten çekilen güvenilmeyen 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 yalnızca kendi çalışma dizinine 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 üzerinde işlem yapmasını nasıl sağlarım?

Sunucuya bağlanırken SSH agent'ı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 olmadan çalışır. Buradaki risk, 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ük bir VPS'e ihtiyacı vardır?

Ajanın iş yükü ağırlıklı olarak dosya düzenleme, derleme ve test çalıştırmadan oluşur; bu nedenle makineyi modelin ihtiyaçlarına göre değil, derleme sürecinin ihtiyaçları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. Ajanın kendisi için bir alt sınır mevcuttur: 20 Ekim 2026 itibarıyla, Claude Code sistem gereksinimleri minimum 4 GB RAM önermektedir. Basit betik işleri için bile 4 GB ile başlayın; eğer depo container oluşturuyorsa veya kapsamlı bir derleme yapıyorsa 8 GB'a geçin.

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

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