AI Ajanı Sandbox Seçimi: Konteyner, gVisor ve microVM

AI ajanı neden sandbox gerektirir?

Kod çalıştıran bir ajan dosya oluşturabilir, paket kurabilir, komut çalıştırabilir ve ağa bağlanabilir. OWASP Agentic Top 10 (2026) bu riski ASI05 Unexpected Code Execution başlığıyla ayrı bir madde olarak ele alır: ajanın ürettiği ya da çalıştırdığı kodun beklenmedik sonuç doğurması. Sandbox, ajanın hatasını ya da yanıltılmasını önlemez. Hatanın etkisini sınırlar.

Sandbox'ın korumaya çalıştığı varlıklar şunlardır:

• Ana makinenin dosyaları, süreçleri ve çekirdeği
• Aynı altyapıyı paylaşan diğer kullanıcılar ve görevler
• Ortamdaki sırlar, belirteçler ve bulut kimlik bilgileri
• İç ağdaki servisler ve bulut meta veri uç noktası
• İşlemci, bellek ve dolayısıyla maliyet

Her ajan aynı düzeyde izolasyona ihtiyaç duymaz. Yalnız metin üreten bir asistan için sandbox gerekmez. Kod yorumlayıcısı olan, dosya değiştiren ya da kabuk komutu çalıştıran her ajan için gerekir. Kodlama asistanlarının kendi sandbox yaklaşımları için AI kod asistanı güvenliği karşılaştırması yazısına bakabilirsiniz.

Konteyner, gVisor ve microVM nasıl karşılaştırılır?

Üç yaklaşım, güvenilmeyen kod ile ana makine arasına farklı kalınlıkta duvar koyar.

Docker belgelerine göre varsayılan seccomp profili 300'ü aşkın sistem çağrısından yaklaşık 44'ünü kapatır. Bu yararlı bir daraltmadır, ama geri kalan çağrılar hâlâ paylaşılan çekirdeğe ulaşır. gVisor belgeleri, Sentry'nin uygulamanın sistem çağrılarını ana çekirdeğe iletmediğini ve dosya erişimini Gofer adlı ayrı bir süreç üzerinden yaptığını açıklar. Firecracker yalnız beş aygıt taklit eder ve sanallaştırma sınırı aşılırsa ikinci savunma hattı olarak jailer sürecini kullanır.

Tablo genel bir yönelim verir. Ayrıcalıklı çalışan, ana makine dizinleri bağlanmış bir microVM, sıkı yapılandırılmış bir konteynerden daha zayıf olabilir. Katmanın adı değil, yapılandırması sonucu belirler.

Konteyner tek başına ne zaman yetmez?

Konteyner izolasyonu çekirdeği ve çalışma zamanını paylaştığı için bu bileşenlerdeki bir açık doğrudan kaçış yolu olur. Ocak 2024'te duyurulan CVE-2024-21626, runc 1.1.11 ve önceki sürümlerdeki bir dosya tanımlayıcı sızıntısı nedeniyle konteyner sürecinin ana makine dosya sistemine erişmesine yol açabiliyordu. Kötü niyetli bir imaj da aynı yolu kullanabiliyordu. Ajanın kendi seçtiği paketleri ve imajları çalıştırdığı bir ortamda bu tür açıklar soyut bir risk değildir.

Konteyner kullanacaksanız en azından şu sıkılaştırmaları uygulayın:

docker run --rm \
  --runtime=runsc \
  --network none \
  --read-only --tmpfs /work:rw,size=256m \
  -v "$PWD/girdi:/girdi:ro" \
  --cap-drop ALL --security-opt no-new-privileges \
  --pids-limit 128 --memory 512m --cpus 1 \
  --user 10001:10001 \
  ajan-calistirici:1.4 python /girdi/gorev.py

Bu örnekte konteyner gVisor çalışma zamanıyla başlatılır, ağı kapalıdır, kök dosya sistemi salt okunurdur, yazma yalnız geçici bir çalışma dizininde mümkündür, bütün Linux yetenekleri düşürülmüştür ve süreç ayrıcalıksız bir kullanıcıyla çalışır. gVisor kurulu değilse --runtime=runsc satırı çıkarılır, ama bu durumda kod paylaşılan çekirdekle doğrudan konuşur.

AI ajanı sandbox için hangi katman seçilmeli?

Seçimi üç soruya göre yapın: kod kimden geliyor, ortamda hangi sırlar var ve ortamı kimler paylaşıyor?

Katmanlar birlikte de kullanılabilir. Örneğin microVM içinde kısıtlı bir konteyner, üstüne ağ çıkış vekili ve kısa ömürlü kimlik bilgisi eklenebilir. Firecracker sayfası, E2B gibi kod çalıştırma platformlarının ve Kata Containers'ın bu teknolojiyle bütünleştiğini listeler.

Ağ çıkışı neden dosya sistemi kadar önemli?

Anthropic, Ekim 2025'te Claude Code için yayımladığı sandbox mimarisinde bunu açıkça yazdı: etkili sandbox hem dosya sistemi hem ağ izolasyonu gerektirir. Ağ izolasyonu yoksa ele geçirilmiş bir ajan SSH anahtarı gibi hassas dosyaları dışarı gönderebilir. Dosya sistemi izolasyonu yoksa ajan sandbox'tan kaçıp ağ erişimi kazanabilir. Aynı yazıda Linux'ta bubblewrap, macOS'ta seatbelt kullanıldığı, ağ trafiğinin sandbox dışındaki bir vekil sunucudan geçtiği ve bu düzenin şirket içi kullanımda izin istemlerini %84 azalttığı belirtiliyor.

Ağ kısıtı için kontrol listesi:

1. Sandbox'ın dış çıkışını varsayılan olarak kapatın.
2. Gerekli alan adlarını sandbox dışındaki bir vekil sunucuda izin listesine alın.
3. İç ağ adreslerine ve bulut meta veri uç noktasına (169.254.169.254) erişimi açıkça engelleyin.
4. Paket kurulumunu denetimli ve kayıtlı bir paket aynasından yapın.
5. Tüm giden bağlantıları kaydedin ve yeni hedeflerde uyarı üretin.

Kısıtsız ağ aynı zamanda maliyet riskidir. Döngüye giren bir ajan dış servislere binlerce istek gönderebilir.

Sırlar sandbox'a nasıl verilir?

Sandbox içindeki her sır, ortam ele geçirilirse dışarı çıkabilir. Bu yüzden ilke, sırrı mümkün olduğunca içeri sokmamaktır. Kimlik gerektiren işlem sandbox dışındaki bir aracı katmanda yapılırsa ajan yalnız sonucu görür.

Ana makinenin ~/.ssh, ~/.aws ya da .env dosyalarını sandbox'a bağlamayın. Bir anahtar yine de sızarsa ilk saatlerde yapılacaklar için LLM API anahtarı sızıntısı rehberi yol gösterir.

Kubernetes'te izolasyon katmanı nasıl seçilir?

Kubernetes, farklı pod'ların farklı çalışma zamanlarıyla çalışmasına RuntimeClass nesnesiyle izin verir. Kubernetes belgeleri bunu performans ile güvenlik arasında denge kurmanın yolu olarak tanımlar. Ajanın kod çalıştırdığı pod'ları gVisor ya da Kata gibi bir çalışma zamanına, diğer servisleri varsayılan çalışma zamanına yönlendirebilirsiniz.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc        # düğümdeki CRI yapılandırmasındaki ad ile aynı olmalı
---
apiVersion: v1
kind: Pod
metadata:
  name: ajan-kod-calistirici
spec:
  runtimeClassName: gvisor
  automountServiceAccountToken: false
  containers:
    - name: calistirici
      image: registry.example.com/ajan-calistirici:1.4
      securityContext:
        runAsNonRoot: true
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

Belirtilen RuntimeClass yoksa ya da düğüm ilgili işleyiciyi çalıştıramıyorsa pod başarısız olur. Bu, sessizce zayıf çalışma zamanına düşmekten daha güvenli bir davranıştır. Ağ çıkışını NetworkPolicy ile ayrıca kısıtlayın. Küme düzeyindeki diğer sertleştirmeler için Kubernetes üzerinde LLM servisi sertleştirme yazısına bakın.

Sandbox hangi riskleri çözmez?

Sandbox kodu kısıtlar, niyeti denetlemez. Ajan sandbox içinde güvenle çalışsa bile dışarıdaki bir araca yetkili çağrı yapabiliyorsa asıl risk o çağrıdadır: e-posta gönderme, ödeme başlatma ya da kayıt silme. Bu çağrıların parametreleri ve yetkisi sandbox'tan bağımsız olarak denetlenmelidir. Yöntem için araç çağrısında parametre doğrulama yazısına bakın.

Sandbox'ı sürekli yönetilen bir kontrol olarak ele alın:

• Komut, dosya erişimi ve ağ bağlantısı kayıtlarını sandbox dışında, ajanın erişemeyeceği bir yerde saklayın.
• Temel imajları düzenli yeniden oluşturun ve tarayın, çalışma zamanının güvenlik bültenlerini izleyin.
• Her görev için temiz ortam başlatın, ortamı görevler arasında yeniden kullanmayın.
• Süre, işlemci ve bellek sınırı koyun, sınır aşımında ortamı sonlandırın.
• İzin kurallarını kod olarak saklayın ve değişiklikleri gözden geçirin.

Kayıtlar olağandışı bir davranış gösterdiğinde ajanı kademeli olarak durdurma yöntemi için ajan kill-switch ve durdurma merdiveni yazısı uygulanabilir bir çerçeve sunar.

Sık Sorulan Sorular

Konteyner tek başına AI ajanı sandbox için yeterli mi?

Güvenilmeyen kod için tek başına yeterli sayılmaz. Konteynerler ana makinenin çekirdeğini paylaşır, bu yüzden çekirdek ya da konteyner çalışma zamanındaki bir açık izolasyonu aşabilir. Modelin ürettiği ya da kullanıcıdan gelen kodu çalıştırıyorsanız gVisor veya microVM gibi ek bir katman ekleyin. Gözden geçirilmiş, sabit araçlar için sıkılaştırılmış konteyner makul olabilir.

gVisor ile microVM arasındaki fark nedir?

gVisor, uygulamanın sistem çağrılarını Sentry adlı kullanıcı alanı çekirdeğinde karşılar ve bunları ana çekirdeğe doğrudan iletmez. microVM ise kendi çekirdeği olan, KVM gibi donanım sanallaştırmasına dayanan hafif bir sanal makinedir. gVisor süreç benzeri esnek kaynak kullanımı sunar ama bazı sistem çağrılarını desteklemez. microVM daha güçlü bir sınır çizer, sabit maliyeti biraz daha yüksektir.

Sandbox ajanın veri sızdırmasını engeller mi?

Tek başına engellemez. Sandbox kodun ana makineye zarar vermesini sınırlar, ama sandbox içinde okunabilen veri açık bir ağ yolundan dışarı gönderilebilir. Ağ çıkışını varsayılan olarak kapatın, gerekli alan adlarını sandbox dışındaki bir vekil sunucuda izin listesine alın ve sandbox'a yalnız görev için gereken dosyaları verin. Etkili izolasyon hem dosya sistemi hem ağ sınırı gerektirir.

Sır yönetimi sandbox'ta nasıl yapılmalı?

Sandbox'a kalıcı ve geniş yetkili anahtar vermeyin. En iyi düzen, sırrın hiç içeri girmemesi ve kimlik gerektiren işlemin sandbox dışındaki bir aracı katmanda yapılmasıdır. Sır gerekiyorsa görev başına üretilen, kısa ömürlü ve dar kapsamlı bir kimlik bilgisi kullanın. Görev bitince bu kimliği iptal edin ve kullanım kaydını inceleyin.

Kaynaklar

• Anthropic Engineering: Beyond permission prompts, making Claude Code more secure and autonomous
• gVisor: What is gVisor?
• Firecracker: Secure and fast microVMs for serverless computing
• Docker Docs: Seccomp security profiles for Docker
• Kubernetes Docs: Runtime Class
• NVD: CVE-2024-21626 Detail

İlgili Yazılar

• AI Kod Asistanı Güvenliği Karşılaştırması 2026 Claude Code, Cursor, Codex CLI, Gemini CLI ve Cline'ı izin modeli, sandbox ve CVE ekseninde ölçtük
• Otonom Ajan Kill-Switch Tasarımı: Ajan Durdurma Merdiveni Rogue agent müdahale runbook'u ve devre-kesici deseni
• Kubernetes LLM Güvenliği: Model Servisini Sertleştirme
• LLM Araç Çağrısı Doğrulama: Tool Calling İçin Şema, Yetki ve Politika