AI Ajanları için CubeSandbox Nedir? İzolasyon Açıklaması

Yapay zeka aracınız kod yazabiliyorsa, kötü kod da yazabilir. Araçları çağırabiliyorsa, yanlış aracı yanlış argümanlarla çağırabilir. Çözüm daha akıllı bir istem (prompt) değildir. Bu, modelin çıktısı ile onu çalıştıran makine arasında bir izolasyon sınırıdır. CubeSandbox, tam da bu sınır için inşa edilmiş sistemlerden biridir ve ne yaptığını, diğer yaklaşımlarla nasıl karşılaştırıldığını ve aracınız gerçek API'lere ve gerçek verilere dokunmaya başladığında nerede konumlandığını anlamaya değerdir.

TL;DR

CubeSandbox, yapay zeka aracı kodlarını çalıştırmak için Tencent Cloud'dan gelen açık kaynaklı, donanım izoleli bir korumalı alan hizmetidir. Her korumalı alan, KVM aracılığıyla kendi misafir işletim sistemi çekirdeğini alır, yaklaşık 60 ms'de başlar ve 5 MB'ın altında bellek yükü kullanır. Apache 2.0 lisanslıdır ve E2B SDK ile doğrudan uyumludur.

Giriş

Aracılı sistemler artık üretimde kod yazıyor ve çalıştırıyor. Bir kodlama aracı bir Python betiği oluşturur ve çalıştırır. Bir araştırma aracı bir sayfayı kazır, ayrıştırır ve sonucu başka bir adıma aktarır. Bir veri aracı bir CSV yükler ve modelin çalışma zamanında karar verdiği dönüşümleri çalıştırır. Bu kodların hiçbiri çalıştırılmadan önce bir insan tarafından incelenmedi. Bu, aracı korumalı alanın (sandboxing) çözdüğü temel sorundur: Güvenilmeyen, model tarafından oluşturulan talimatları ana bilgisayarınıza, dosya sisteminize, kimlik bilgilerinize veya ağınıza erişim vermeden yürütmeniz gerekir.

Aracıların özerklik kazanmasıyla bu daha da önem kazanıyor. Bir SQL sorgusunda yanlış olan bir model can sıkıcıdır. `rm -rf` hakkında yanlış olan veya kazınmış bir web sayfasındaki enjekte edilmiş bir talimatı takip eden bir model bir güvenlik olayıdır. Korumalı alan sert bir çizgi çizer: aracı tek kullanımlık, izole bir ortamda istediğini yapabilir ve yaptığı hiçbir şey dışarı sızmaz.

İkinci, daha sessiz bir sorun var. Aracılar sadece kod çalıştırmaz; API'leri ve araçları da çağırır. Bir aracının bir korumalı alanın içinden ödeme API'nizi veya dahili hizmetlerinizi kullanmasına güvenmeden önce, bu API'lerin doğru davrandığını ve aracının onları beklediğiniz şekilde çağırdığını bilmeniz gerekir. İşte burada API araçları çalışma zamanı izolasyonunun yanında yerini alır. Apidog gibi bir platform, bir aracının çağıracağı uç noktaları taklit etmenize ve test etmenize olanak tanır, böylece özerk bir sistem korumalı bir çalıştırmada onu kullanmaya başlamadan önce sözleşmeyi doğrulamış olursunuz. Halihazırda aracı mimarisi hakkında düşünüyorsanız, aracılı yapay zeka mimarisi hakkındaki kılavuzumuz, bu yürütme ve araç katmanlarının nasıl bir araya geldiğini anlatmaktadır.

Bu makalenin geri kalanı CubeSandbox'ın ne olduğunu, aracıların neden bir korumalı alana ihtiyaç duyduğunu, izolasyon modellerinin nasıl farklılaştığını ve bunun aracılarınızın bağlı olduğu API'leri test etmeyle nasıl bağlantılı olduğunu açıklamaktadır.

CubeSandbox Nedir?

CubeSandbox, yapay zeka aracı kodlarını çalıştırmak için bir güvenlik korumalı alan sistemidir ve Nisan 2026'da Tencent Cloud tarafından Apache 2.0 lisansı altında açık kaynak olarak yayınlanmıştır. GitHub sloganı onu açıkça tanımlar: "Yapay Zeka Aracılar için Anında, Eşzamanlı, Güvenli ve Hafif Korumalı Alan." Bu sadece bir SDK değildir. Kendinizin dağıtabileceği, çoğunlukla Rust ile yazılmış, tam bir hizmet olarak korumalı alan (sandbox-as-a-service) yığınıdır.

Mimari, birçok bulut hipervizörü tarafından kullanılan aynı Linux çekirdek sanallaştırma katmanı olan RustVMM ve KVM üzerine kuruludur. Projenin belgelerine ve resmi duyuruya göre, sistem birkaç bileşene ayrılmıştır:

• CubeAPI: E2B korumalı alan arayüzünü yansıtan bir REST ağ geçidi.
• CubeMaster: korumalı alanları düğümler arasında zamanlayan küme düzenleyicisi (orchestrator).
• CubeHypervisor ve CubeShim: her bir mikroVM'i başlatan ve yöneten KVM sanallaştırma katmanı.
• Cubelet ve CubeProxy: korumalı alanları çalıştıran ve onlara yönlendiren düğüm düzeyindeki aracılar.
• CubeVS: çekirdek düzeyinde korumalı alanlar arası ağ izolasyonunu uygulayan eBPF destekli bir ağ katmanı.

Manşet özelliği, her korumalı alanın kendine özel bir misafir işletim sistemi çekirdeğine sahip olmasıdır. Bu, ana bilgisayar çekirdeğini paylaşan bir konteynerden daha farklı ve daha güçlü bir izolasyon modelidir. Tencent'in yayınladığı sayılar, tek eşzamanlılıkta yaklaşık 60 ms'lik bir soğuk başlatma süresi (50 eşzamanlı oluşturma altında P95 yaklaşık 90 ms ile ortalama 67 ms), örnek başına 5 MB'ın altında bellek yükü ve tek bir büyük ana bilgisayarda binlerce korumalı alan çalıştırma yeteneği olduğunu belirtiyor. Basın materyalleri, 96 sanal CPU'lu bir sunucunun 2.000'den fazla eşzamanlı korumalı alanı desteklediğini gösteriyor. Tencent, CubeSandbox'ın kendi altyapısında ölçekli olarak çalıştığını ve MiniMax'ın onu heterojen ortamlarda büyük ölçekli aracılı takviyeli öğrenme eğitimi için kullandığını belirtiyor.

Olay düzeyinde anlık görüntü geri alma (snapshot rollback) gibi bazı gelişmiş özellikler, kontrol noktası oluşturma (checkpointing) ve korumalı alan durumunu geri yükleme (restoring) için hala geliştirilme aşamasında olarak tanımlanmaktadır. İleriye dönük öğeleri gönderilmiş garantiler olarak değil, yol haritası olarak değerlendirin ve güncel durum için depoyu kontrol edin. Satıcının kendi rakamlarının ötesindeki halka açık karşılaştırma metodolojisi sınırlıdır, bu nedenle performans iddialarını kendi iş yükünüze göre doğrulayın.

Kanonik detaylar için, gerçek kaynak CubeSandbox GitHub deposu ve resmi belgeler sitesidir.

Yapay zeka aracıları neden bir korumalı alana ihtiyaç duyar?

Tehditler konusunda somut olmak yardımcı olur, çünkü "güvenlik" karşı tasarım yapmak için çok belirsizdir. Ekipleri korumalı alana yönlendiren üç hata modu vardır.

Riskli oluşturulan kod. Bir model doğru olduğuna inandığı kodu üretir. Bazen doğru değildir. Yanlış dizini siler, sıkı bir döngüde belleği tüketir veya olması gereken yere bir dosya yazar. Bunların hiçbiri kötü niyetli değildir; sadece yanlıştır ve ana bilgisayar erişimi olan yanlış kod tehlikelidir. Aracının bir patlama yarıçapı kavramı yoktur, siz ona vermediğiniz sürece.

Güvenilmeyen araç çağrıları. Aracılar, modelin çalışma zamanında karar verdiklerine göre araçları ve API'leri çağırır. Eğer model, bir belgeye, bir web sayfasına veya bir araç yanıtına gömülü bir istem enjeksiyonu tarafından yönlendirilirse, yıkıcı bir aracı çağırabilir, saldırgan tarafından kontrol edilen argümanları geçirebilir veya çağrıları hiç niyetlenmediğiniz bir şekilde zincirleyebilir. Model burada güvenilir bir aktör değildir; bağlam penceresine ulaşan herhangi bir metnin yorumlayıcısıdır. Bu konuya, geleneksel API güven varsayımlarının otonom arayanlarla neden bozulduğunu anlatan yeni API tüketicileri olarak yapay zeka aracıları hakkındaki yazımızda daha derinlemesine değiniyoruz.

Veri sızdırma. Bu, insanların hafife aldığı bir durumdur. Ağ erişimi ve sır erişimi olan bir aracı, bir veri sızdırma kanalına dönüştürülebilir. Zehirli bir talimat, aracıya bir API anahtarını tutan bir ortam değişkenini okumasını ve bunu harici bir uç noktaya POST etmesini söyler. Çıkış filtrelemesi ve kimlik bilgisi izolasyonu olmadan, korumalı alan sınırı anlamsızdır çünkü veriler ön kapıdan çıkar. Bu nedenle CubeSandbox, çekirdek düzeyinde izolasyonu CubeVS aracılığıyla eBPF tabanlı çıkış filtrelemesi ile eşleştirir; ağ açıksa sürecin izolasyonu yeterli değildir.

Ortak nokta: aracının davranışının, aldığı güvenilmeyen veriler tarafından kısmen kontrol edildiği için aracının iyi davranacağını varsayamazsınız. Bir korumalı alan, modelin güvenilir olup olmadığını düşünmeyi bırakıp, ne olursa olsun geçerli bir sınır hakkında düşünmeye başlamanızı sağlar. Bu davranışları üretime ulaşmadan önce incelemek için, API'leri çağıran yapay zeka aracılarını nasıl test edeceğinizi inceleyin.

Aracı korumalı alanlar nasıl çalışır: izolasyon modelleri

Tüm korumalı alanlar aynı şekilde izole etmez ve farklılıklar hem güvenlik hem de performans açısından önemlidir. Aracı ekosisteminde göreceğiniz dört genel yaklaşım vardır.

Süreç düzeyinde izolasyon. Kodu seccomp filtreleri, bırakılan yetenekler (capabilities), ad alanları (namespaces) ve cgroup'lar ile kısıtlanmış bir işletim sistemi süreci olarak çalıştırın. Bu en hafif ve en zayıf seçenektir. Ana bilgisayar çekirdeğini paylaşır, bu nedenle bir çekirdek istismarı, ana bilgisayarın tehlikeye girmesi anlamına gelir. Çoğunlukla güvendiğiniz kod için iyidir; rastgele model çıktısı için zayıftır.

Konteynerler. Docker tarzı konteynerler ad alanı (namespacing) ve kaynak sınırları ekler ve operasyonel olarak tanıdıktır. Ancak konteynerler tasarım gereği ana bilgisayar çekirdeğini paylaşır. Konteyner kaçışı güvenlik açıkları gerçek ve tekrarlayan bir hata sınıfıdır ve "paylaşılan çekirdekli bir konteynerdeki güvenilmeyen kod" bilinen bir zayıf noktadır. Birçok ekip kolay olduğu için buradan başlar, sonra izolasyon tavanına çarpar.

MikroVM'ler. Bir mikroVM, donanım sanallaştırma (KVM) içinde minimal bir misafir çekirdeği başlatır. Aracının kodu kendi çekirdeğine karşı çalışır, bu nedenle çekirdek düzeyindeki bir istismar ana bilgisayara değil, tek kullanımlık bir VM'ye hapsolur. Firecracker bu modeli sunucusuz iş yükleri için popülerleştirdi ve CubeSandbox, her korumalı alan için bir misafir çekirdeği ile RustVMM ve KVM kullanarak bu kategoriye girer. Tarihsel dezavantaj başlangıç süresiydi; mikroVM'ler konteynerlerden daha yavaş başlıyordu. Modern uygulamalar bunu anlık görüntü alma (snapshotting) ve kaynak ön hazırlığı (resource pre-provisioning) ile ele alır, CubeSandbox'ın 100 ms altı başlangıçları bu şekildedir.

Uygulama çekirdekleri. gVisor farklı bir yol izler: kullanıcı alanında sistem çağrılarını yakalar ve Linux benzeri bir arayüzü kendi başına uygular, böylece iş yükü asla doğrudan ana bilgisayar çekirdeğiyle konuşmaz. Tam bir VM olmadan güçlü bir izolasyon katmanıdır, bazı sistem çağrısı uyumluluğu ve performans ödünleşimleri vardır.

İşte yaklaşımların aracılar için önemli boyutlarda nasıl karşılaştırıldığı:

Tek bir kazanan yok. Doğru karar, koda ne kadar güvendiğinize, soğuk başlatmaları ne kadar hızlı yapmanız gerektiğine, KVM çalıştırıp çalıştıramadığınıza ve altyapıyı kendiniz mi işletmek istediğinize yoksa bir hizmet olarak mı kullanacağınıza bağlıdır.

Manzarada CubeSandbox

CubeSandbox'ın konumu özeldir: bir konteyner gibi hızlı soğuk başlatmalarla donanım düzeyinde izolasyon sunar ve kiralanan bir hizmetten ziyade sizin çalıştırdığınız bir şey olarak dağıtılır. Bu onu üç referans noktasıyla doğrudan kavramsal karşılaştırmaya sokar.

Konteynerlere karşı. Bir konteyner ana bilgisayar çekirdeğini paylaşırken; CubeSandbox her korumalı alana kendi çekirdeğini verir. Rastgele aracı tarafından oluşturulan kod için güvenlik argümanı budur. Maliyeti, KVM özellikli bir x86_64 Linux ana bilgisayarına (çıplak metal sunucu, iç içe sanallaştırmayı destekleyen bir bulut VM veya yerel çalışma için WSL 2) ihtiyacınız olmasıdır. Platformunuz KVM'yi sunamıyorsa, mikroVM tabanlı izolasyon sizin için mevcut değildir ve gVisor gibi bir kullanıcı alanı yaklaşımı veya barındırılan bir API daha uygun olabilir.

Firecracker'a karşı. Firecracker, sunucusuz için iyi bilinen bir mikroVM'dir ve kendisi bir yapı taşıdır, bir aracı-korumalı alan ürünü değildir. CubeSandbox da KVM/RustVMM tabanlıdır ancak yığının daha üst katmanlarında gelir: bir düzenleyici (orchestrator), E2B uyumlu bir API ağ geçidi ve eBPF ağ izolasyonu, bu nedenle bir araya getirmek yerine bir aracı korumalı alan hizmeti dağıtıyorsunuz. İlkel öğeler istiyorsanız, Firecracker. Aracı şekilli bir API'ye sahip bir korumalı alan hizmeti istiyorsanız, CubeSandbox bunu hedefler.

E2B ve barındırılan korumalı alanlara karşı. E2B, yönetilen bir hizmet olarak izole korumalı alanlar sağlar; bir API çağırırsınız ve altyapı başkasının sorunudur. CubeSandbox'ın dikkat çekici tasarım seçimi E2B SDK uyumluluğudur. Belgeler onu doğrudan bir yedek olarak tanımlar: `E2B_API_URL` adresini kendi barındırdığınız Cube örneğinize işaretleyin ve mevcut kod çalışmaya devam eder. Bu, asıl kararı "hangi korumalı alan"dan ziyade "yönetilen hizmet mi yoksa kendi kendine barındırılan altyapı mı" olarak değiştirir; veri yerleşimi, ölçekteki maliyet ve operasyonel sahiplik belirleyici faktörlerdir. Ayrıca Tencent'in duyurusuna göre OpenAI Python SDK'sını yerel olarak destekler.

Dürüst bir özet: CubeSandbox, açık bir tezle (güçlü izolasyon, hızlı başlangıçlar, kendi kendine barındırılan, E2B uyumlu) aracı-korumalı alan alanında güvenilir bir giriştir. Ayrıca yeni ve büyük ölçüde kendi satıcısı tarafından belgelenmiştir, bu nedenle bağımsız karşılaştırmalar sınırlıdır. Taahhütte bulunmadan önce iş yükünüze karşı prototipini oluşturun ve soğuk başlatma, yoğunluk ve izolasyon davranışını ölçün.

Bu, aracılarınızın çağırdığı API'leri ve araçları test etmeyle nasıl bağlantılıdır

Çalışma zamanı izolasyonu "kod kötüyse ne olur?" sorusunu yanıtlar. "Aracının çağırdığı API kötüyse veya aracı onu yanlış çağırıyorsa ne olur?" sorusunu yanıtlamaz. Bunlar farklı sorunlardır ve ikisinin de ele alınması gerekir.

Seyahat rezervasyonu yapan bir korumalı alana alınmış bir aracı düşünün. Kod, CubeSandbox içinde güvenli bir şekilde çalışır. Ancak aracı yine de bir uçuş API'si, bir ödeme API'si ve dahili bir seyahat programı hizmetini çağırır. Bunlardan herhangi biri hatalı bir yanıt döndürürse, aracı döngüye girebilir, bir kurtarma halüsinasyonu görebilir veya aşağı akışa kötü veri aktarabilir. Ödeme API'sini yanlış idempotentlik anahtarıyla çağırırsa, izolasyon sizi kurtarmaz; para yine de hareket eder. Korumalı alan ana bilgisayarı aracıdan korur. Sistemlerinizi, gerçek hizmetlere gerçek çağrılar yapan şaşkın bir aracıdan korumaz.

Bu nedenle, gerçekte geçerli olan iş akışı, birlikte çalışan iki katmandan oluşur:

1. Yürütmeyi izole edin, böylece model tarafından oluşturulan kod ve araç çağrıları ana bilgisayara zarar veremez veya veri sızdıramaz. Bu, CubeSandbox katmanıdır.
2. Aracının erişebileceği her API ve aracın sözleşmesini, korumalı alan çalıştırmalarından önce ve sırasında doğrulayın. Bu, API araçları katmanıdır.

İkinci katman için, davranışları test ederken aracının kontrollü bir vekille konuşabilmesi için bağımlılıkları taklit edin, ardından şema uyumluluğu, hata işleme, kimlik doğrulama ve kenar durumları için gerçek uç noktaları test edin. Apidog ile deterministik, şemaya uygun yanıtlar döndüren bir taklit sunucu oluşturabilir, korumalı alana alınmış aracıyı ona yönlendirebilir ve üretim ortamına dokunmadan aracının hem başarı hem de başarısızlık yollarına nasıl tepki verdiğini izleyebilirsiniz. Hazır olduğunuzda, sözleşmenin geçerliliğini doğrulamak için aynı senaryoları canlı API'ye karşı çalıştırın. Korumalı alan testi hakkındaki kılavuzumuz, izole edilmiş, kontrollü ortamlara karşı test yapma genel pratiğini kapsar ve bu burada doğrudan uygulanabilir.

Bu eşleştirme önemlidir çünkü aracılar sözleşme kaymasını (contract drift) artırır. Bir insan bir API yanıtının yanlış göründüğünü fark eder. Bir aracı genellikle fark etmez; yanıtı alır ve ona göre hareket eder. Taklitler ve testlerle uygulanan sıkı API sözleşmeleri, otonom bir arayanın tek bir kötü yanıtı bir dizi hataya dönüştürmesini engeller. Eğer aracılarınız Model Bağlam Protokolü (Model Context Protocol) konuşuyorsa, Apidog ile MCP sunucularını test etmek aynı disiplini araç katmanına genişletir. Ve eğer aracı tüketicileri için API'ler tasarlıyorsanız, yapay zeka aracıları için API tasarlamak otonom çağrıları tahmin edilebilir kılan sözleşme modellerini kapsar.

Gerçek dünya kullanım senaryoları

İzolasyon artı sözleşme yaklaşımının değerini gösterdiği birkaç örnek:

• Kodlama aracıları ve kod yorumlayıcıları. Bir model, bir soruyu yanıtlamak, verileri dönüştürmek veya bir grafik oluşturmak için kod yazar ve çalıştırır. Bu, kanonik korumalı alan kullanım durumudur ve E2B uyumlu API'lerin doğrudan hedeflediği şeydir. CubeSandbox'ın korumalı alan başına çekirdeği burada önemlidir çünkü kod tamamen rastgeledir ve her çalıştırmada değişir.
• Çok kiracılı aracı platformları. Birçok müşterinin aracıları paylaşılan altyapı üzerinde kod çalıştırıyorsa, kiracılar arasındaki konteyner düzeyinde izolasyon risklidir. Korumalı alan başına donanım izolasyonu, bir kiracının aracısı düşmanca olsa bile geçerli olan bir kiracılık sınırı sağlar. Bildirilen yoğunluk (ana bilgisayar başına binlerce korumalı alan) bu yaklaşımı, kiracı başına bir VM yerine uygulanabilir kılar.
• Aracılı pekiştirmeli öğrenme (RL) ve eğitim döngüleri. Aracıları pekiştirmeli öğrenmeyle eğitmek, çok sayıda kısa ömürlü, güvenilmeyen denemeyi çalıştırmak anlamına gelir. Tencent, MiniMax'ın tam da bu amaçla, heterojen ortamlarda CubeSandbox kullandığını belirtiyor. Hızlı soğuk başlatma ve düşük örnek başına ek yük, uygulanabilir bir eğitim çalıştırması ile uygulanamaz olan arasındaki farktır.
• Araç kullanan araştırma ve veri aracıları. Bir aracı harici içeriği alır, ayrıştırır ve aşağı akış API'lerini çağırır. Alınan içerik güvenilmezdir (istem enjeksiyonu riski), bu nedenle ayrıştırma ve oluşturulan kod bir korumalı alanda olmalı, aşağı akış API'leri ise önce taklitlere karşı denenmelidir. İzolasyonu API sözleşme testi ile eşleştirmenin en çok işe yaradığı yer burasıdır.
• Güvenilmeyen eklenti veya uzantı yürütme. Kullanıcılar aracınızın çalıştırdığı araçları veya kodu sağlayabiliyorsa, tanım gereği üçüncü taraf güvenilmeyen kodu yürütüyorsunuz demektir. Yürütme başına bir mikroVM sınırı uygun bir duruştur, sunucusuz platformların Firecracker'ı benimserken kullandığı aynı mantık.

Sonuç

Aracılar insan incelemesi olmadan kod yürütmeye ve araçları çağırmaya başladığı anda, aracı korumalı alanı isteğe bağlı olmaktan çıktı. CubeSandbox, bu sorunun izolasyon yarısına somut, açık bir yanıttır.

Temel çıkarımlar:

• CubeSandbox gerçek ve spesifiktir: Tencent Cloud'un yapay zeka aracıları için Apache 2.0 açık kaynak korumalı alanı, RustVMM ve KVM üzerine inşa edilmiş, korumalı alan başına misafir çekirdekleri ile.
• İzolasyon modeli ana noktadır: korumalı alan başına özel bir çekirdek, rastgele model tarafından oluşturulan kod için konteyner izolasyonundan daha güçlüdür, bildirilen 100 ms altı soğuk başlatma süreleri ve 5 MB'ın altında ek yük ile.
• E2B uyumluluğu geçiş maliyetini düşürür: eğer E2B kullanıyorsanız, belgelenmiş doğrudan uyumlu yol, seçimi yeniden yazmaktan ziyade yönetilen ile kendi kendine barındırılan arasında bir tercih olarak yeniden şekillendirir.
• Satıcı rakamlarını bir başlangıç noktası olarak ele alın: performans ve yoğunluk iddiaları büyük ölçüde Tencent'ten gelmektedir; kendi iş yükünüze karşı karşılaştırma yapın ve hangi özelliklerin yayınlandığını veya geliştirme aşamasında olduğunu depo üzerinden kontrol edin.
• İzolasyon gerekli ama yeterli değildir: bir korumalı alan ana bilgisayarınızı aracıdan korur; API'lerinizi şaşkın bir aracının onları çağırmasından korumaz.
• Çalışma zamanı izolasyonunu API sözleşme testi ile eşleştirin: bir aracının erişebileceği her uç noktayı taklit edin ve test edin, böylece tek bir kötü yanıt bir dizi hataya yol açmaz.

Eğer aracılarınız sahip olduğunuz veya bağımlı olduğunuz API'leri çağırıyorsa, izolasyon katmanının yanı sıra sözleşme katmanını da kurun. Korumalı alanlı aracılarınızın kullandığı hizmetleri taklit etmek ve şema, kimlik doğrulama ve hata davranışları açısından test etmek için Apidog'u indirin, böylece özerk bir sistem onları üretime geçirmeden önce bu kontrolleri yapmış olursunuz.

düğme