Docker Sandboxes ile AI agent’ları microVM içinde izole etmek

Docker Sandboxes, AI coding agent’larını kendi Linux kernel’i, filesystem’i, ağı ve Docker Engine’i olan ayrı microVM’lerde çalıştırıyor. Docker, paylaşılan host kernel’i yüzünden container’ların otonom agent’lar için yeterli sınır çizmediğini savunuyor ve yaklaşımını “Sandbox the agent, containerize the application it works on” diye özetliyor. Sandbox, sbx adlı CLI ile tek komutla açılıyor.

microVM nedir?

microVM, yalnızca gerekli sanal donanımı içeren ve hızlı açılan küçük bir sanal makinedir. Kendi kernel’ini çalıştırır, host’tan hypervisor sınırıyla ayrılır. Container’ın açılış hızına yakın kalıp sanal makine düzeyinde izolasyon istenen yerlerde, örneğin serverless platformlarda ve güvenilmeyen kodun çalıştırılmasında kullanılır. Firecracker bilinen bir örneğidir.

Container sınırı kernel’de bitiyor

Bir coding agent’ı container’a koyup izole ettiğinizi düşünüyorsanız sınırın yerine bakın. Container, host kernel’ini paylaşan bir process. Namespace’ler görünümü ayırıyor, cgroups kaynakları sınırlıyor, kernel ise tek.

Bu tasarım uygulama için yeterli, çünkü uygulama yapılandırıldığı gibi davranır. Agent ise ortamını değiştirmek için çalışıyor. Paket kuruyor, veritabanı açıyor, image build ediyor ve saatlerce yeniden deniyor. README, issue metni veya MCP tool çıktısından gelen talimatla da hareket edebiliyor. Kimsenin okumadığı bir dosyadaki prompt injection, agent’ın çalıştıracağı komutu doğrudan yönlendirebiliyor.

Docker Sandboxes sınırı hypervisor’a taşıyor. Agent container’dan kaçsa bile kendi microVM’inde kalıyor. Her agent’a ayrı microVM düştüğü için aynı makinedeki iki agent birbirine ulaşamıyor.

MacOS ve Windows’ta Docker Desktop container’ları zaten bir VM içinde çalıştırıyor. Bu, host işletim sistemini koruyor, fakat o VM’deki bütün container’lar yine aynı kernel’i paylaşıyor.

Docker.sock bağlıysa exploit gerekmiyor

/var/run/docker.sock’u container’a mount etmek, o container’a host Docker daemon’ının kontrolünü veriyor. Daemon host path’lerini mount edebiliyor ve privileged container başlatabiliyor. Agent bunun için zero-day (sıfırıncı gün) aramıyor. Ortamı yokluyor, socket’i buluyor ve kullanıyor. WeAreDevelopers keynote demosunda bir agent bu yolla host’taki bir secrets dosyasına ulaştı.

Agent’ları şu anda container içinde çalıştırıyorsanız önce socket mount’larını tarayın:

docker ps -q | xargs docker inspect --format '{{.Name}} {{range .Mounts}}{{.Source}} {{end}}' | grep docker.sock

Çıktıda agent container’ı varsa onu host’ta root yetkisi olan bir kullanıcı gibi değerlendirin. Docker-in-Docker, mount edilmiş credential dosyaları ve geniş host mount’ları aynı listeye giriyor. CI pipeline’larındaki socket mount’larını da bu taramaya katın, agent orada çalışmasa bile açıklık aynı.

Docker Sandboxes kontrolü host’ta tutuyor

Sandbox içindeki agent, microVM’deki private Docker Engine ile konuşuyor. Testcontainers çalıştırabiliyor, bütün bir Compose stack’ini ayağa kaldırabiliyor. Host daemon’ı ve socket’i microVM’in dışında kalıyor. Agent sandbox içinde sudo yetkisiyle çalışıyor.

Fark, kuralların uygulandığı yerde:

• Outbound trafik deny-by-default politikalı bir host proxy’sinden geçiyor.
• Desteklenen HTTP servislerinde credential’ı host enjekte ediyor, token’ı environment variable olarak içeri vermeniz gerekmiyor.
• Workspace doğrudan read-write mount veya microVM içinde private clone olarak bağlanıyor.

Agent bu kuralları kapatamıyor, çünkü kurallar onun eriştiği kernel’de çalışmıyor.

Denemek için tek komut yetiyor:

sbx run claude

Sandbox’ı durdurup devam ettirebiliyorsunuz. Agent’ın kurduğu paketler ve image’lar siz sandbox’ı silene kadar duruyor. Saatler süren bir oturumda container’ın her yeniden oluşturuluşunda volume dışındaki state’in kaybolması sorununu bu çözüyor.

Paylaştığınız her şey hâlâ açık

MicroVM, içeri kendi elinizle verdiğiniz şeyi korumuyor. Workspace, izin verilen ağ hedefleri, MCP server’ları ve skill’ler agent’ın erişiminde kalıyor. Read-write mount ile verdiğiniz bir repo, yönlendirilmiş bir agent’ın elinde silinebilir.

Sınırı çizdikten sonra içeriği daraltın. Önemli repo’larda private clone tercih edin. Ağ allowlist’ini agent’ın gerçekten çağırdığı host’larla sınırlayın. Production credential’larını workspace’e hiç koymayın.

YOLO modunda onay prompt’u kalmıyor. Görevini yanlış okuyup production veritabanını silen agent örneği tam bu modda yaşandı. O noktada elinizde yalnızca sınır ve sınırın içine bıraktıklarınız var.

CI job’ları container’da kalsın

Docker ayrımı net çiziyor. Paketlenmiş uygulama, CI job’u ve kısa ömürlü çalıştırma için container doğru araç olmaya devam ediyor. Saatlerce state biriktiren, sudo isteyen ve kendi Docker Engine’ine ihtiyaç duyan otonom agent için sandbox öneriliyor.

Geçişi şu sırayla yapabilirsiniz:

1. Agent çalıştıran container’lardaki socket ve credential mount’larını kaldırın.
2. Agent’ı Docker Sandboxes içine alın, uygulamayı sandbox içinde container olarak çalıştırmaya devam edin.
3. Network politikasını deny-by-default ile başlatın, gereken hedefleri tek tek açın.

Her agent kendi kernel’i ve Docker Engine’iyle kendi microVM’inde çalışıyor. Bu yüzden aynı makinede kaç agent açacağınızı bellek ve disk bütçesine göre planlayın.