AI Agent Tool Permissions Sandbox: Kendini Test Eden Ajan
Ajan kendi çıktısını nasıl test eder?
Geçenlerde datasette-apps projesindeki bir detaya takıldım: app_debug() adında bir fonksiyon, bir ajanın az önce ürettiği uygulamayı sınırlı bir sandbox içinde çalıştırıp test etmesine izin veriyor. Basit bir detay gibi görünüyor ama aslında AI agent tool permissions sandbox tasarımının can alıcı noktasına dokunuyor: ajana “bunu dene” dedikten sonra, o deneme sırasında ajanın elinde ne var? Tüm sisteme mi erişiyor, yoksa sadece kendi ürettiği şeyi mi görebiliyor?
Bu soru bana tanıdık geldi çünkü AgentSpace’i kurarken tam olarak aynı duvara çarptım. Worker ajanlar gerçek görevler alıyor, kod üretiyor, bir şeyler çalıştırıyor — ve üretilen çıktıyı doğrulamanın en güvenilir yolu, ajanın kendisine “şimdi bunu çalıştır, sonucu bana anlat” dedirtmek. Sorun şu: bunu yapabilmesi için hangi yetkilere ihtiyacı var, hangilerine yok?
Datasette’in çözdüğü şey
Datasette-apps’teki mantık kabaca şöyle işliyor: ajan bir uygulama/kod parçası üretiyor, sonra bunu doğrudan prod ortamda ya da kendi ana oturumunda değil, ayrı ve sınırlandırılmış bir çalıştırma bağlamında deniyor. app_debug() burada bir “önizleme kapısı” gibi çalışıyor — ajan kendi ürettiği şeyin gerçekten çalışıp çalışmadığını görüyor ama bu görme işlemi, sistemin geri kalanına yazma yetkisi vermiyor.
Bunun güzel yanı şu: sandbox’ı “ayrı bir makine” olarak değil, “ayrı bir izin kümesi” olarak kurmuşlar. Yani mesele illa disposable VM ya da konteyner değil (bu konuyu daha önce clawk’ın yaklaşımıyla ayrı bir yazıda karşılaştırmıştım) — mesele ajana test anında hangi tool çağrılarının açık olduğu. Bu ayrım önemli, çünkü izolasyon ve izin aslında iki farklı problem ve ikisini birbirine karıştırmak tasarımı gereksiz karmaşıklaştırıyor.
Bizim problemimiz: worker’a kendi çıktısını test ettirmek
AgentSpace’te lider ajan bir görevi worker’a devrediyor, worker bir sprint içinde kod üretiyor ve görev panosuna işliyor. Burada gerçek soru şu: worker, ürettiği kodu “çalışıyor mu” diye test ederken hangi yetkilerle hareket ediyor?
Blast radius neden asıl mesele
Bir worker ajana “kendi çıktını test et” dediğinizde, aslında ona iki farklı yetki demeti veriyorsunuz gibi görünür ama değil:
- Kodu çalıştırma yetkisi (gerekli, testin özü bu)
- O çalıştırma sırasında dış sisteme dokunma yetkisi (çoğu zaman gerekmiyor, ama default olarak açık kalıyor)
Sorun ikincisinde. Bir worker “bu API entegrasyonunu test ediyorum” derken, gerçekten dış bir servise istek atması mı gerekiyor, yoksa mock/stub bir yanıtla da doğrulama yapabilir mi? Çoğu zaman ikincisi yeterli ama ajanlar (ve bizler) varsayılan olarak “gerçek ortamda dene, en garantilisi bu” refleksine kayıyor. Bu da blast radius’u — bir hatanın yayılabileceği alanı — gereksiz büyütüyor.
Sandbox, izin listesinden farklı bir şey
Burada datasette-apps örneğinden çıkardığım asıl ders şu: “şu tool’lara izin var, şu tool’lara yok” listesi tek başına yeterli değil. Çünkü aynı tool’un (örneğin dosya yazma, HTTP isteği atma) test bağlamında ve gerçek görev bağlamında taşıdığı risk farklı. Sandbox, tool izin listesinin üstüne bir “bağlam” katmanı ekliyor: aynı worker, aynı tool’u, iki farklı bağlamda iki farklı kapsamda kullanabiliyor.
Bizim AgentSpace’teki tool/izin katmanını daha önce Claude Skills’i incelerken de anlatmıştım; oradaki mantık izinleri tool’a bağlamaktı. Buradaki ek katman ise izinleri bağlama (test mi, gerçek görev mi) bağlamak — henüz bunu sistematik olarak ayrıştırmış değilim, şu an worker’ın “test modu” ile “üretim modu” arasındaki sınır kod içinde net değil, daha çok görev tanımına gömülü kurallarla yönetiliyor.
Şu an AgentSpace’te durum ne
Açık olmak gerekirse: elimizde henüz datasette-apps’teki gibi ayrı bir app_debug() benzeri sandbox fonksiyonu yok. Worker ajanlar görev panosundan görev alıyor, kalıcı hafızalarına yazıyor, Claude üzerinde koşuyor ve ürettikleri çıktıyı çoğunlukla aynı oturum içinde, aynı tool izinleriyle test ediyorlar. Bu, işe yarıyor çünkü sprint’ler görece küçük kapsamlı — ama “işe yarıyor” ile “doğru tasarlanmış” aynı şey değil, bunu biliyorum.
Datasette’in yaklaşımından aldığım somut fikir şu: test amaçlı çalıştırmayı, gerçek görev çalıştırmasından ayrı bir tool izin profiliyle işaretlemek. Yani worker “şimdi kendi çıktımı doğruluyorum” dediği an, ona verilen tool seti otomatik olarak daralsın — yazma yetkileri salt-okunur bir kopyaya dönüşsün, dış çağrılar mock’a düşsün. Bunu henüz kod olarak kurmadım, şu an planım bu.
Henüz bilmediklerim
- Bu ayrımı (test modu / görev modu) görev tanımı seviyesinde mi, yoksa tool katmanında mı zorlamalı, henüz karar vermedim.
- Sandbox’ı fazla katı kurarsam worker’ın gerçek entegrasyon hatalarını (mock’un yakalayamadığı) kaçırma riski var — bunun dengesini ölçmedim.
- Datasette-apps’in kendi implementasyonunu satır satır incelemedim, sadece kavramı aldım; bire bir aynı mimariyi kurup kurmayacağım belli değil.
Bu yazı bir çözüm ilanı değil, bir problem tanımı. AI agent tool permissions sandbox aramanın arkasındaki asıl soru genelde bu: ajana yetki vermeden nasıl güven inşa edilir. Datasette’in cevabı bana mantıklı geldi, AgentSpace’e nasıl gireceğini önümüzdeki sprint’lerde göreceğiz.