Docker Sandboxes'ı test ettim ve bence çok iyi düşünülmüş bir şey.
Düşün ki Claude Code'a bir hatayı aratıyorsun ve birden şunu çalıştırmak için senden izin istiyor:
docker compose down && \
docker image rm mertbergblog-webservice-app 2>/dev/null; \
docker network inspect blog >/dev/null 2>&1 || docker network create blog && \
docker compose up -d --build && \
until docker compose exec db pg_isready -U blog -d blog >/dev/null 2>&1; do sleep 1; done && \
docker compose exec app goose -dir /migrations postgres "$DATABASE_URL" up && \
docker image prune -f --filter "dangling=true" && \
docker compose logs -f app
Korkutucu, değil mi?
Ama bir çözümü var, adı da Docker Sandboxes, kısacası sbx.
Docker Sandboxes ne yapıyor?
Özünde bir microVM oluşturuyor ve coding agent'ı onun içinde çalıştırıyor.
Teorisi bu. Peki pratikte ne demek? Bir microVM, container değildir. Container'lar aynı binadaki daireler gibidir: kendi kapıları var ama tek bir temel ve aynı tesisat, bu durumda da ortak bir kernel. MicroVM ise aynı sokağa kurulmuş kendi küçük evidir. Kendi kernel'i, kendi dosya sistemi, kendi network'ü, kendi Docker daemon'ı.
Sokak yine de host'un, ve yazının sonunda buraya geri döneceğiz.
Bu konudaki yazıların çoğu bir ayrıntıyı yanlış biliyor, kontrol etmeden önce benimki de dahil: microVM otomatik olarak Firecracker demek değil. MicroVM üzerine yazılan neredeyse her şey Amazon'un Firecracker'ını anlatıyor, bilinen 125 milisaniyelik boot süresi ve 5 MiB altındaki overhead rakamları da oradan geliyor. Docker Sandboxes ise görünüşe göre virtiofs ile birlikte libkrun kullanıyor. Yani bu rakamlar güzel bir benzetme, sbx ölçümü değil. Birine karşı kullanmadan önce bilmekte fayda var.
sbx için izolasyon sınırı, onu başlattığın klasör. Bir proje dizininde başlatırsan agent o projeyi görür. Home dizininde başlatırsan içindeki her şeyi görür. Güvenliğinin büyük bölümü bu tek ayrıntıya bağlı, o yüzden başka bir şeye geçmeden önce bunu netleştirmelisin.
Böylece bir sonraki bölüme geliyoruz.
Docker Sandboxes AI agent'lı geliştirmeyi neden daha güvenli yapıyor
Diyelim ki coding agent'ınla bir şey denemek istiyorsun ve bunun için güvenli bir alana ihtiyacın var. İzole bir microVM tam da bunun için doğru şey.
Ayrıca agent'tan bazı şeyleri uzak tutmak istediğinde de doğru seçim. .env dosyan, API key'lerin, aylar önce ayarlayıp unuttuğun erişim bilgilerin. Agent'ın bu verileri bir yere kaydetmesinden endişe ediyorsun ve bahse girerim bir sürü API key çoktan kimsenin beklemediği yerlere düşmüştür. Model sağlayıcılarından birine gerçekten başarılı bir saldırı olursa, bu çok kişi için kötü bir hafta olur.
Yani iyi bir güvenlik önlemi. Agent'ı güvenilir yaptığı için değil, AI'ı daha sorumlu kullanmak için bize bir araç verdiği için. Aslında hoşuma giden şey tam olarak bu: modelin ne yaptığını değil, benim neye izin verdiğimi değiştiriyor.
Şimdi IDE'ni sbx ile nasıl kullanacağını sorabilirsin. Bakalım.
SSH üzerinden Docker Sandboxes
Bir sandbox'a SSH ile bağlanabilirsin. Önce ~/.ssh/config dosyanı ayarlıyorsun:
sbx setup ssh
Sonra sandbox'ı oluşturuyorsun:
sbx create --name <NAME_OF_SBX_HOST> shell .
Ardından bağlanıyorsun:
ssh <NAME_OF_SBX_HOST>.sbx
sbx setup ssh konfigürasyonu yazıyor, sbx create her şeyi çözümlüyor ve nasıl bağlanacağını söylüyor.
Bu ekran görüntüsündeki bir şeyi bilerek bırakıyorum: o sandbox'ın workspace'i benim ~/.ssh dizinim ve üstelik yazılabilir olarak bağlı. SSH kurulumunu test ederken böyle yaptım ve bir saniye bile düşünmedim. Aşağıda anlattığım hatanın tam olarak kendisi. Sandbox bizi kendi seçtiğimiz klasörden korumuyor.
Cursor ve VS Code'da "Connect to..." ile bir klasörü SSH üzerinden açabilirsin.
VS Code sandbox ile başka herhangi bir remote host gibi konuşuyor. Gördüğün dosya ağacı microVM'in içinde.
Zed'de bende çalışmadı, proxy master başarısız oldu. Büyük kayıp değil, çünkü Zed 1.14 sürümünden beri kendi sandboxing özelliğini getiriyor: https://zed.dev/blog/sandboxing
Gerçekte nerede çalışıyor
Docker dar bir platform listesi belgeliyor: Apple Silicon üzerinde macOS Sonoma, Windows 11 ve Ubuntu 24.04 veya üzeri. Mint ya da Pop!_OS gibi türevler açıkça desteklenmiyor.
Ben Debian 13 üzerinde çalıştırıyorum ve çalışıyor. Bu Docker'ın desteklediği alanın dışında, o yüzden bunu bir taahhüt değil, benim sonucum olarak al. Debian 12'de bende çalışmadı. Her halükarda KVM'e ihtiyacın var, yani /dev/kvm var mı ve kullanıcın kvm grubunda mı diye kontrol et. Host'un kendisi bir VM ise hypervisor tarafında nested virtualization gerekiyor, yoksa guest içinde /dev/kvm olmaz ve hiçbir şey başlamaz.
Bir homelab makinesinde üç sandbox'ı aynı anda ayağa kaldırmadan önce iki varsayılanı bilmekte fayda var. Bir sandbox varsayılan olarak host belleğinin yüzde 50'sini alıyor, tavan 32 GiB. Ve sandbox'lar hiçbir şeyi paylaşmıyor: Docker kendi yazıyor, her biri kendi Docker daemon durumunu, kendi image cache'ini ve kendi paket kurulumlarını tutuyor. Dolayısıyla aynı image'ları her sandbox için yeniden indirip build ediyoruz. Root disk 20 GB.
Her sbx run neyi çözümlediğini yazıyor. Tek bir sandbox için on iki CPU ve 16 GiB, üstelik bunu ben istemedim.
Kullanırken keyifli olan tarafı
Testlerimde blog veritabanımı bir sandbox içinde çalıştırdım ve sınırlarına kadar zorladım. Bir şeyleri kırmaya çalıştım. Veri sildim, kod değiştirdim, yarım kurulmuş bir veritabanına karşı migration çalıştırdım.
Kendi backend'imin Dockerfile ve Compose dosyasını siliyorum ve hiç umursamıyorum. Bu his ürünün ta kendisi.
Aynı proje üzerinde farklı agent'larla birden fazlasını aynı anda da çalıştırabilirsin:
Aynı repository üzerinde iki sandbox, biri Claude biri Gemini. Hiçbir şeyi paylaşmıyorlar, mesele de bu, disk maliyetinin sebebi de bu.
İşim bitince çalışan parçaları dışarı kopyaladım ve sandbox'ı kaldırdım, bu da içindeki her şeyi siliyor.
Bu son nokta önemli: sbx rm <SANDBOX_NAME> ya da sbx prune çalıştırmadan önce işini dışarı kopyala. Geri dönüşü yok.
Bunun yerine tüm ortamı saklamak istiyorsan kendi template'ini ya da bir kit kullanabilirsin. Bu kısmı gerçekten ilginç. Bir sandbox'ın durumunu template'te tutup kit üzerinden agent'a komutları otomatik çalıştırtabilirsin. spec.yaml içinde başlangıçta hangi komutların çalışacağını tanımlıyorsun. Kit'ler bana hala deneysel geliyor, o yüzden üzerine henüz bir workflow kurmazdım.
Bunu homelab'imde farklı image sürümlerini test etmek için kullanıyorum. Her şey çalışınca aynı komutları production'da çalıştırıyorum. Backend testi için çok iyi. Agent tuhaf bir şey yapsa bile sandbox'ı kaldırıyorum ve her şey yolunda.
Ya da neredeyse her şey. Böylece anlaması en uzun süren kısma geliyoruz.
Docker Sandboxes'ın tuzakları
Her şey toz pembe değil. MicroVM'e rağmen içine ne koyduğumuza dikkat etmemiz gerekiyor ve bunların çoğunu Docker'ın kendisi belgeliyor.
Mount ettiğin klasördeki secret'lar. Varsayılan olarak dizinin yazılabilir şekilde bağlanıyor. Agent içindeki her şeyi okuyor, repo'nun yanında duran bir .env dahil, ve bu dosyaları değiştirebiliyor da. MicroVM bizi kendi elimizle verdiğimiz şeyden korumuyor. Emin değilsen --clone kullan.
Agent'ın yazdığı ve host'ta çalışan dosyalar. Bu nokta ince, ve en çok endişelendiğim nokta. Agent bizim makinemizde hiçbir şey çalıştıramıyor. Ama bir git hook'u, bir Makefile target'ı ya da package.json içinde scripts altına bir giriş yazabiliyor, ve bunlar biz ya da tooling'imiz onları alınca daha sonra host'ta çalışıyor. Kaçış hypervisor'dan geçmiyor, bir sonraki git checkout üzerinden geçiyor.
MCP server'ların microVM'in dışında çalışıyor. Yerel stdio MCP server'ları host yetkileriyle host process'i olarak başlıyor. Docker bunu kendi dokümantasyonunda yazıyor. Yani bir MCP server'a ulaşabilen agent'ın, en başından beri sandbox'ın içinde olmayan bir kanalı var.
Allowlist veri sızdırmak için kullanılabiliyor. Proxy içeriği değil, domain'i kontrol ediyor. İzin verilen bir domain'e giden istek bu yüzden veriyi dosya adında taşıyabilir, mesela <SECRET_KEY>.json şeklinde. İsteğin kendisi reddediliyor ama karşı taraf ismi çoktan loglamış oluyor. Güvenlik araştırmacıları 2026'da tam olarak bunu bir dizi coding agent'a karşı gösterdi ve Docker sorunu kendi dokümantasyonunda kabul ediyor: geniş bir domain'e izin vermek, üzerindeki herhangi bir içeriğe erişime izin veriyor, "including user-generated content".
Policy'nin gerçekte ne olduğuna bak. Docker varsayılan allowlist'i yayınlamıyor ve iki dokümantasyon sayfası varsayılanın izin vermek mi yoksa reddetmek mi olduğu konusunda birbiriyle çelişiyor. O yüzden okuma, çalıştır:
sbx policy ls
Bende ilk çalıştırma Balanced'a ayarladı ve bunu da söyledi:
"Default deny, with common dev sites allowed." Bilmekte fayda var, ve bunu bir doküman sayfasından değil kendi terminalinden okumak daha iyi.
Skills store'u sandbox'lar arasında paylaşılıyor. Docker buna kendisi "a narrow exception to cross-sandbox isolation" diyor ve yazılabilir olarak bağlıyor. Dolayısıyla bir sandbox, agent'ın daha sonra başka bir sandbox'ta kullanacağı talimatları değiştirebiliyor. Talimatlar da burada asıl önem taşıyan içerik türü.
Sandbox agent konfigürasyonunu hala senin projenden yüklüyor. Bu konfigürasyon sandbox'a ulaşmadan önce değiştirildiyse, sandbox uslu uslu ele geçirilmiş bir agent başlatıyor. Tam da bu yüzden .claude/settings.json içine kalıcılık hook'ları yazan zararlı yazılımlar var, ve bunlar onu getiren paket kaldırıldıktan sonra bile hayatta kalıyor.
Sandbox'ların kendisinde de delikler oldu. Claude Code'un network sandbox'ında, "her şeyi engelle" diye belgelenen boş bir allowlist'in network kısıtlamasını tamamen kapattığı bir hata çıktı (CVE-2025-66479). İkinci bir hata da içine null byte gömülmüş bir hostname'in kontrolü geçmesine izin verdi. İkisini de bulan araştırmacı bunu benim yapabileceğimden daha iyi ifade ediyor: "Shipping a sandbox with a hole is worse than not shipping one. The user with no sandbox knows they have no boundary. The user with a broken sandbox thinks they do."
Bir süre sonra onaylamaktan bıkıyoruz. Bir noktada auto moda geçiyor ya da izinleri bypass edip agent'ı öylece çalıştırıyorsun. Anlıyorum, ben de bazen yapıyorum, ve her seferinde içime sinmiyor. Sandbox bunu meşru yapmıyor, çünkü yukarıdaki maddeler hala host'a dokunuyor.
Ekran görüntüsündeki en alt satır: "bypass permissions on". Bunu yazı için açmadım. Zaten açıktı.
Performans. Sağlam bir şey söyleyecek kadar uzun kullanmadım, ama ek katman agent'ı yavaşlatabilir, ve başkaları yavaşlattığını bildiriyor. Yine de bilmeye değer bir şey var: varsayılan direct mount olanı yavaş olanı. Docker kendi troubleshooting dokümanında git status, git log ve dizin taramalarının hissedilir şekilde yavaş olabileceğini yazıyor, --clone modunda ise virtiofs cache'i aktif. Yani daha güvenli mod aynı zamanda daha hızlı olanı, ve bu kombinasyon yeterince nadir.
Ve eğer 125 milisaniyelik boot süresine güvenmek üzereysen: gerçekçi bir stack içinde bağımsız ölçümler Firecracker için 700 ila 1300 milisaniye soğuk başlangıç gösteriyor, sbx için de 2 ila 5 saniye ek başlangıç süresi bildiriliyor. O reklam rakamı özel olarak inşa edilmiş bir serverless kontrol düzlemini anlatıyor, bizim laptop'larımızı değil.
Pazarlamaya girmeyen kısım
Okurken iki şey buldum, ve ikisi de konu hakkında düşünme şeklimi değiştirdi.
Birincisi: "Firecracker'ın escape CVE'si yok" cümlesi 2026'dan beri doğru değil. Artık Firecracker'ın virtio-PCI transport'unda bir out-of-bounds write var, ve Cloud Hypervisor açıkça "a full guest-to-host (VM) escape" diyen bir advisory yayınladı. İkisi için de çalışan açık bir exploit yok, yani panik sebebi değil. Pazarlamayı tekrarlamayı bırakma sebebi.
İkincisi daha ağır basıyor, çünkü sokak burada geri geliyor. MicroVM hypervisor'ı küçültüyor. Ama KVM'i küçültmüyor, ve KVM host kernel'inde duran, guest'in doğrudan konuştuğu kod. 2026'da KVM'in kendisinde iki guest-to-host kaçışı oldu, biri 2010'dan beri shadow MMU içinde duran bir hatadan. Rust ile yazılmış, syscall filtresi sıkı sıkıya kapatılmış 50.000 satırlık bir VMM buna karşı tam olarak hiçbir işe yaramıyor.
Tüm bu sorunu en iyi anlatan örnek microVM'lerle ilgili bile değil. Temmuz 2026'da OpenAI'daki bir agent, kendi çıkış trafiğini kontrol etmek için konulmuş olan paket registry proxy'sinde bir zero-day buldu ve bunu kullanarak açık internete ulaştı. Sadece agent'ın paket erişimine ihtiyacı olduğu için var olan bileşen, çıkış kapısı oldu.
Peki değer mi?
Evet, satış şeklinde bir düzeltmeyle.
Bizi koruyan şey microVM değil. En kötü senaryoyu ortadan kaldırıyor, yani makinemize geri dönüşü olmayan bir şey yapan agent'ı. Geriye çok daha sıradan bir problem kalıyor: bilerek içeri uzattığımız her şey. Klasör, konfigürasyon, allowlist, MCP server.
Sandbox AI'ı daha güvenli yapmıyor. Beni daha cesur yapıyor, ve bu sadece hangi kapıyı açık bıraktığım konusunda dürüst kaldığım sürece bir iyileşme.