Coding Ajanlara Sandbox VM: Clawk Notu
AgentSpace’te worker ajanlar headless Claude CLI ile koşuyor: lider sprint’i böler, worker terminalde iş görür, kimse her adımda onay tuşuna basmaz. Böyle bir mimaride soru hep aynı yere çıkar: ajan bir komutu çalıştırmadan önce kim, ne genişlikte bir yetkiyle onaylıyor? Ajanı geniş yetkiyle açıp kendi dosya sistemini, ssh anahtarlarını ve ağını paylaştırıyorsan, “iyi çalıştı” ile “bir şey silindi” arasındaki fark tek bir yanlış komuta kalır. Çok-ajanlı sistemi headless koşturan herkes bu gerilimi tanır: ya her adımı onaylarsın ya da riski kabul edip yetkiyi tam açarsın.
Haber: ajanına kendi Linux makinesini ver
GitHub’da öne çıkan clawk, bu ikilemi VM seviyesinde çözmeyi öneriyor. clawk komutuyla bir repoya girdiğinde Claude Code ya da Codex, kendi makinende değil tek kullanımlık bir Linux VM içinde root yetkisiyle çalışıyor; kodun mount edilir ama anahtar zincirin ve makinenin geri kalanı erişim dışında kalır. Proje kendini şöyle özetliyor: “The agent gets its own machine instead of yours.” Sınırı bir prompt kuralı değil, hipervizör sınırı ve ağ allow-list’i belirliyor; ajan VM’i dağıtsa bile clawk destroy && clawk ile temiz bir kopya ve eski konuşma geçmişiyle geri dönüyorsun.
Bizim notumuz
AgentSpace’in worker’ları tam olarak clawk’ın hedeflediği senaryoda çalışıyor: headless CLI, sprint boyunca insan onayı yok, ajan paket kuruyor, komut çalıştırıyor, ağa çıkıyor. Bugünkü yetki modelimiz iki uçta: ya araç bazında izin listesi tutup ajanı sınırlıyoruz, ya da hız için geniş yetki verip riski kabul ediyoruz. clawk’ın önerdiği şey üçüncü bir seçenek: yetkiyi ajana tam ver ama ajanın durduğu makineyi değiştir. Bu bizim için doğrudan ilgi çekici, çünkü blast-radius sorunumuz bir prompt kuralıyla değil, ajanın gerçekten hangi dosya sistemine ve ağa dokunabildiğiyle ilgili — VM izolasyonu tam da bu katmana giriyor.
Ama bugün doğrudan devreye alacağımız bir şey değil. clawk şu an macOS + Apple Silicon üzerinde çalışıyor, Linux desteği (firecracker üzerinden) henüz deneysel; AgentSpace worker’ları ise headless olarak sunucu/Linux tarafında koşuyor, benim geliştirme makinem değil. “cd, clawk, çalıştır” akışı bizim deployment şeklimizle bugün birebir örtüşmüyor. Bunu henüz test etmedim — planım, worker’ları izole bir sınırın arkasına almanın mimari bedelini (boot süresi, disk maliyeti, ağ allow-list yönetimi) önce kağıt üzerinde çıkarmak, sonra tek bir worker sınıfında ölçmek.
Okuyucu için sonuç: ajanını headless çalıştırıyorsan izin problemi bir prompt kuralıyla değil, ajanın durduğu makineyle çözülür — clawk bunun somut bir örneği.
Bugün ne yapıyoruz
- Ajanının izin modelini yaz: her adım onaylı mı, tam yetkili mi?
- Tam yetkiliyse hangi dosya sistemine, hangi ssh anahtarına, hangi ağa erişebildiğini listele.
- clawk’ın security model sayfasını oku: “mount ettiğin ve allow-list’e eklediğin her şey ajana açıktır” ilkesini kendi worker’larına uygula.
- Linux/sunucu tarafında çalışıyorsan firecracker desteğinin olgunlaşmasını takip et; bugün için izolasyonu manuel ağ allow-list + salt-okunur mount ile taklit etmeyi değerlendir.