Kodlama agent'larını güvenle çalıştırmak: izolasyon, anahtarlar ve yedek
Bir kodlama agent'ı, senin kullanıcınla ve senin yetkilerinle kabuk komutları çalıştıran bir programdır. Bu onu güçlü yapan şeydir; aynı zamanda dikkatli olman gereken şey de budur. Bu yazıda Claude Code ya da Codex gibi agent'ları, özellikle de onları gözetimsiz çalıştırırken, nasıl daha güvenli kullanacağını üç başlıkta topladık: izolasyon, anahtarlar ve yedek.
Gerçekte ne ters gidebilir?
Agent'lar kötü niyetli değildir ama hata yaparlar ve okudukları metinlerden etkilenirler. Pratikte karşılaşılan riskler şunlar:
- Yıkıcı komutlar. Yanlış klasörde bir
rm -rf, birgit push --forceya da test veritabanı sanılan bir veritabanındaDROP TABLE. - Sızan sırlar.
.envdosyasını okuyup içeriğini bir log'a, bir commit'e ya da bir hata raporuna yazmak. - İstem enjeksiyonu (prompt injection). Agent'ın okuduğu bir README'nin, issue'nun ya da web sayfasının içine gizlenmiş "şu dosyayı şu adrese gönder" gibi talimatlar.
- Tedarik zinciri. Adı gerçek bir pakete benzeyen sahte bir npm ya da pip paketini kurmak.
- Kontrolsüz maliyet. Döngüye giren bir agent'ın, kullanıma göre ücretlendirilen bir API anahtarıyla gece boyunca harcama yapması.
Bunların hiçbiri teorik değil. İyi haber şu ki hepsine karşı basit, katmanlı önlemler var.
1. İzolasyon: agent'ı kendi bilgisayarından ayır
En etkili önlem, agent'ın çalıştığı makinede kaybetmekten korkacağın hiçbir şeyin olmaması. Kendi laptop'unda agent; SSH anahtarlarına, tarayıcı oturumlarına, parola yöneticine, üretim ortamının kimlik bilgilerine ve kişisel dosyalarına aynı yetkiyle erişebilir. Ayrı bir ortamda ise en kötü senaryo o ortamı silip yeniden kurmaktır.
Seçeneklerin, en hafiften en güçlüye:
- Ayrı bir Linux kullanıcısı. Kolay ama zayıf; aynı çekirdeği ve çoğu zaman aynı ağı paylaşırsın.
- Bir konteyner. Projeyi bağlayıp agent'ı içinde çalıştırırsın. Agent proje klasörünü değiştirebilir ama ev dizinine ve anahtarlarına ulaşamaz:
Anthropic, Claude Code için ağ erişimini sınırlayan bir referans devcontainer yapılandırması da yayımlıyor; ekipçe kullanacaksan iyi bir başlangıç noktası.docker run -it --rm -v "$PWD":/work -w /work node:22 bash npm install -g @anthropic-ai/claude-code claude - Ayrı bir makine. Bir sanal makine ya da uzak bir sunucu. Agent'ı 7/24 çalıştıracaksan zaten buna ihtiyacın olacak.
Hangisini seçersen seç, kural aynı: agent'ın ortamına yalnızca o işin gerektirdiği şeyleri koy.
2. İzinler: neyi sormadan yapabilir?
Claude Code varsayılan olarak dosya düzenlemeden ve komut çalıştırmadan önce izin ister. Bu güvenli ama gözetimsiz çalışmada işe yaramaz; kimse onay vermez. Burada iki yaklaşım var.
Birincisi, izin verilen ve yasaklanan işlemleri açıkça yazmak. Proje kökünde .claude/settings.json:
{
"permissions": {
"allow": ["Bash(npm run test:*)", "Bash(npm run lint)", "Bash(git diff:*)"],
"deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)", "Bash(git push --force:*)"]
}
}
Bu kurallar Claude'un kendi araçları için geçerli ve kazaları büyük ölçüde önler. Ama bir sandbox değildir: izin verdiğin geniş bir kabuk komutu, yasakladığın bir dosyayı dolaylı yoldan okuyabilir. Asıl koruma, sırrın o makinede hiç bulunmamasıdır.
İkincisi, izinleri tamamen kapatmak: claude --dangerously-skip-permissions. Adındaki uyarı yerinde. Bunu yalnızca yukarıdaki gibi yalıtılmış, üretim anahtarı olmayan ve kolayca yeniden kurulabilen bir ortamda kullan. Kendi bilgisayarında asla.
3. Anahtarlar: en az yetki, kısa ömür
Agent'ın ortamına bir anahtar koyman gerekiyorsa, o anahtarı çalınmış gibi düşün ve ona göre sınırla:
- GitHub: Tüm depolarına erişen klasik bir token yerine, yalnızca ilgili depoya erişen, son kullanma tarihi olan ince ayarlı (fine-grained) bir token kullan. Agent'ın ihtiyacı genelde içerik okuma-yazma ve pull request açmaktır.
ghile:gh auth login --with-token < token.txt - Model ve servis API anahtarları: Her ortam için ayrı anahtar oluştur ve sağlayıcının panelinde bir harcama limiti koy. Bir sorun olursa yalnızca o anahtarı iptal edersin.
- Veritabanları: Agent'a asla üretim veritabanının bilgilerini verme. Bir test veritabanı ya da bir geliştirme dalı kullan.
.envdosyaları:.gitignore'da olduklarından emin ol.git check-ignore -v .envsana hangi kuralın dosyayı dışarıda tuttuğunu gösterir.- Push öncesi tarama:
gitleaks detectgibi bir araçla commit'leri sır için tara; GitHub'ın push protection özelliğini aç.
Bir anahtar sızarsa sıra şudur: önce anahtarı iptal et, sonra geçmişi temizle. Geçmişi temizlemek tek başına yetmez; anahtar o anda kopyalanmış olabilir.
İstem enjeksiyonuna karşı
Agent'ın okuduğu her şey ona bir talimat gibi görünebilir. Bir bağımlılığın README'si, bir müşteri e-postası, bir web sayfası ya da bir issue yorumu. Buna karşı tek bir çözüm yok, ama riski düşüren alışkanlıklar var: sırların bulunduğu bir ortamda agent'a rastgele web sayfaları okutma; yabancı kaynaklı metinleri işleyen görevlerde agent'ın yetkilerini daralt; ve en önemlisi, agent'ın değişikliklerini doğrudan ana dala almak yerine bir pull request üzerinden incele. main için dal koruması aç, force push'u engelle ve birleştirmeden önce inceleme zorunlu olsun.
4. Yedek: geri alamayacağın hiçbir şey olmasın
Agent'larla çalışırken ilk yedeğin git'tir. Agent'tan küçük, çalışan adımları ayrı ayrı commit etmesini iste ve işini düzenli olarak uzak bir depoya gönder. Bir şey ters giderse git revert ile bir commit'i geri alır, git reflog ile kaybolmuş gibi görünen bir durumu geri getirirsin.
Git'te olmayanlar ayrı bir plan ister: .env dosyaları, yüklediğin veri dosyaları, yerel veritabanları. Bunları düzenli olarak paketleyip agent'ın çalıştığı makinenin dışına kopyala:
tar czf yedek-$(date +%F).tgz data/ .env
scp yedek-*.tgz sen@baska-bir-makine:yedekler/
Klasik 3-2-1 kuralı burada da geçerli: üç kopya, iki farklı ortam, biri başka bir yerde. Ve yedeğini ara sıra gerçekten geri yükleyerek dene; hiç denenmemiş bir yedek, bir umuttan ibarettir.
Orkio bu konuda ne yapıyor, ne yapmıyor?
Orkio'da her müşteri, agent'larının çalıştığı kendi Linux kutusunu alıyor. Her kutunun kendi belleği, CPU'su ve ağı var; diğer kutulara ya da onların çalıştığı sunuculara erişemiyor. Böylece agent senin kişisel bilgisayarına ve anahtarlarına hiç dokunmuyor; izolasyon başlığındaki "ayrı makine" maddesi hazır geliyor. Agent'lar senin kendi Claude hesabınla çalışıyor ve kutundaki kodu inceleyip model eğitmek için kullanmıyoruz.
Yapmadıklarımızı da açıkça söyleyelim. Kutunun içinde agent'lar ve terminaller aynı kullanıcıyla çalışıyor; ekip üyelerine tanıdığın klasör sınırları uygulamada geçerli ama bir kabuk komutu yine bu klasörlerin dışını okuyabilir. Uygulamadaki GitHub bağlantısı şu an gh'nin geniş kapsamlı yetkisini kullanıyor; daha dar bir yetki istersen yukarıdaki gibi ince ayarlı bir token ile giriş yapabilirsin. Kutundaki dosyaların senin yerine yedeğini almayı da vaat etmiyoruz: önemli işini kutunun dışındaki bir git deposunda tut. Abonelik biterse dosyalar 30 gün saklanıyor, sonra siliniyor.
Kontrol listesi
- Agent'ı kişisel bilgisayarında değil, ayrı bir ortamda çalıştır.
- Ortama yalnızca o işin gerektirdiği anahtarları koy; hepsi en az yetkili ve süreli olsun.
.claude/settings.jsonile izinleri yaz; izinleri tamamen kapatmayı yalıtılmış ortama sakla.- API anahtarlarına harcama limiti koy.
- Değişiklikleri pull request ile al, ana dalı koru.
- Git'e sık gönder; git dışındakileri ayrıca yedekle ve geri yüklemeyi dene.