Kubernetes'te AI Ajanları İçin Güvenli Sandbox Mimarisi

Yapay zeka ajanlarının kendi ürettiği kodu (ör. pip install çağrıları) çalıştırması, incelenmemiş ve güvenilmeyen kodun üretimde yürütülmesi anlamına geliyor. Replit ajanının production veritabanını silmesi ve Nx tedarik zinciri saldırısı (s1ngularity) sırasında binlerce sırın çalınması gibi olaylar, bu riskin teorik olmadığını gösteriyor. Anthropic ve OpenAI da kendi araçlarında işletim sistemi seviyesinde sandbox ve varsayılan ağ kısıtlaması uygulayarak bu tehdidi zaten kabul etmiş durumda.

Kubernetes pod'ları varsayılan olarak güvenilir kod için tasarlanmıştır; namespace'ler süreçlere yalnızca kısıtlı bir 'görünüm' sunar, gerçek bir 'duvar' değildir ve tüm pod'lar hâlâ aynı çekirdeği paylaşır. runc'taki CVE-2019-5736, CVE-2024-21626 ve Kasım 2025'te aynı gün ortaya çıkan üç yeni kaçış açığı bunu somut olarak kanıtlıyor. Ajanları çok kiracılı bir ortamda veya birbirinden bağımsız görevlerle çoğaltarak çalıştırmak, bu zayıf izolasyonu yetersiz kılıyor.

Kubernetes'in RuntimeClass mekanizması, aynı pod tanımını farklı bir çalışma zamanına yönlendirmeyi mümkün kılıyor. gVisor kullanıcı alanında bir çekirdek taklidi sunarak düşük ek yükle çalışırken syscall-yoğun işlerde performans kaybına yol açabiliyor; Kata Containers her pod'a gerçek bir sanal makine ve çekirdek veriyor ama ~600ms başlatma gecikmesi ve ~180MiB ek yük getiriyor; Firecracker ise AWS Lambda'nın kullandığı minimalist mikroVM teknolojisi olarak 125ms altı açılış süresi ve 5MiB altı ek yükle neredeyse konteyner maliyetinde donanım seviyesinde izolasyon sağlıyor.

Ancak Firecracker'ın bu küçük ayak izi, Kubernetes'in normalde varsaydığı virtio-fs paylaşımlı dosya sistemleri, aygıt hot-plug ve VFIO gibi özellikleri devre dışı bırakıyor; bu da altyapı seviyesinde ek mühendislik gerektiriyor. Mühendisler için karar üç soruya indirgeniyor: kodu kim yazdı, kod tam olarak neye erişiyor/ne çalıştırıyor, ve çok sayıda ajanın tek bir sıcak durumdan hızla çatallanması gerekiyor mu.