Docker Sandboxes, yapay zekâ kodlama ajanları için güven sınırını yeniden çiziyor

Raju Dandigam'ın dev.to'daki yazısı, Docker Sandboxes hakkında sivri bir argüman ileri sürüyor: Bir yapay zekâ kodlama ajanını bir container içine koymak onu güvenli kılmaz; riski sandbox ile host arasındaki dikiş yerlerine taşır.

Yazıya göre yalnızca bir patch önerebilen ajan bir tür risktir; bir shell'e, paket yöneticisine, Docker daemon'ına, kimlik bilgilerine ve ağ erişimine sahip olan ajan ise başka bir tür. İkincisini container'a koymak bu farkı ortadan kaldırmaz. Yazara göre sorulmaya değer soru şu: Hangi kaynaklar izolasyon sınırını hangi yönde ve hangi yetkiyle aşıyor?

Sandbox gerçekte neyi izole ediyor

Docker'ın belgelenmiş yerel modelinde ajan, kendi çekirdeğine ve kendi Docker Engine'ine sahip bir microVM içinde çalışır. Bu VM içinde ajanın sudo dahil geniş yetkileri vardır. Host'a erişim ise workspace dosyaları, kimlik bilgileri, ağ, paylaşılan skill'ler ve MCP sunucularını kapsayan tanımlı bir dizi sınır üzerinden aracılık edilir.

İki detay öne çıkıyor. Sandbox, host daemon'ı yerine özel bir Docker Engine alıyor; bu önemli, çünkü host'un Docker socket'ini sıradan bir container'a mount etmek, host düzeyinde kontrol elde etmenin bilinen bir yoludur. Ayrıca sağlayıcı kimlik bilgileri, host tarafındaki bir proxy aracılığıyla onaylı giden isteklere enjekte edilebiliyor; böylece ham API anahtarları hiçbir zaman VM'ye girmiyor. Bu, anahtarların açığa çıkma riskini sınırlar, ama ajan bu proxy'li anahtarların taşıdığı yetkinin tamamını yine de kullanabilir.

Workspace modu inceleme sınırını belirliyor

Yazı, dosya erişimini sonuçları bir hayli farklı olan üç moda ayırıyor. Direct mount modunda host deposu okuma-yazma paylaşılır ve ajanın düzenlemeleri çalışma ağacında anında görünür. Bu, etkileşimli bir düzenleme-inceleme döngüsüne uyar; ama aynı zamanda ajanın, sandbox dışında host'ta daha sonra yürütülecek CI yapılandırmasını, package script'lerini, editör görevlerini veya ajan yapılandırma dosyalarını yeniden yazmasına da izin verir.

Clone modunda host deposu salt okunur mount edilir ve ajan VM içindeki özel bir klon üzerinde çalışır; yazar bunu keşif amaçlı çalışmalar veya tanınmayan depolar için varsayılan olarak öneriyor. Mountless mod ise hiçbir host dosyası paylaşmaz ve görev bunlara ihtiyaç duymadığında en güçlü seçenektir. Yazıya göre seçim, geliştirici alışkanlığına değil görevin gereksinimine göre yapılmalıdır.

Açık kalan köprüler

Giden ağ trafiği, host tarafındaki bir proxy'den varsayılan olarak reddet (deny-by-default) politikasıyla geçer; ancak yazı, bunun hiçbir şeyin erişilebilir olmadığı anlamına gelmediği konusunda uyarıyor. Docker'ın Balanced preset'i, yaygın model sağlayıcıları, paket yöneticileri, kod host'ları, registry'ler ve bulut hizmetlerini kapsayan bir temel izin listesiyle gelir ve Open ile Locked Down preset'lerinden anlamlı şekilde farklıdır. Öneri, davranışı preset'in adından çıkarsamak yerine sbx policy ls komutuyla etkin kuralları incelemek ve görev için daraltmaktır.

İki köprü daha özel ilgi görüyor. Paylaşılan skill deposu, izolasyona bilinçli bir istisnadır: Bir sandbox, başka bir sandbox'ın daha sonra tüketeceği talimatları veya script'leri değiştirebilir; dolayısıyla onu okuma-yazma paylaşan birkaç sandbox fiilen aynı güven sınırında yer alır. Ve MCP gateway önemlidir, çünkü yerel stdio MCP sunucuları VM içinde değil host üzerinde çalışır; yani host tarafındaki bir MCP aracı, sandbox'ın kendisinin sahip olmadığı bir yetkiye sahip olabilir.

Uçuş öncesi kontrol listesi

Ajanı otonom çalıştırmadan önce yazı, canlı host düzenlemeleri gerekmedikçe clone veya mountless modu tercih etmeyi, görevin ihtiyaç duymadığı ağ varış noktalarını kaldırmayı ve çalışan en düşük yetkiye sahip görev kapsamlı kimlik bilgileri vermeyi öneriyor. Ayrıca her yerel MCP sunucusunu sanki host koduymuş gibi incelemeyi, sandbox'lar arası değişiklik gerekmediğinde paylaşılan skill'leri devre dışı bırakmayı ve değiştirilmiş hook, script veya CI dosyalarını yürütmeden önce değişiklikleri gözden geçirmeyi tavsiye ediyor.

Yazar, insan onayının yayınlama, dağıtım ve diğer geri alınamaz eylemlerde var olmaya devam etmesi gerektiğini ekliyor; çünkü izolasyon, kodun nerede çalıştığını belirler, önerilen bir iş eyleminin uygun olup olmadığını değil. Bir uyarı geçerli: Analiz Docker'ın yerel sandbox modelini kapsıyor ve bulut sandbox'larının kendi yaşam döngüsü, kimlik bilgisi ve bağlantı davranışları var; bu yüzden ekipler, bir sandbox sonucunu güvenlik kanıtı olarak kabul etmeden önce görevin hangi ortamda yürütüldüğünü kaydetmeli.

Neden önemli

Kodlama ajanları, "container içinde mi?" sorusunu yetersiz kılan tam da o yetenekleri — shell'ler, paket yöneticileri, daemon'lar, kimlik bilgileri ve ağ erişimi — hızla ediniyor. Docker Sandboxes, microVM izolasyonu, özel bir daemon, proxy'li kimlik bilgileri ve açık ağ politikasıyla yürütme sınırını gerçekten iyileştiriyor. Kalan risk, bu sınırın ötesinde bilinçli olarak paylaşılan kaynaklardan geçiyor ve bu köprüler her biri bir kullanım kolaylığı özelliği gibi göründüğü için gözden kaçması kolay. Yazının çıkarılan dersi herhangi bir agent runtime'a genellenebilir: Görevi tamamlamak için en küçük workspace, ağ, kimlik bilgisi ve araç yüzeyini verin ve host'a geri giden her köprüyü güvenlik modelinin bir parçası olarak değerlendirin.