NVIDIA OpenShell ajanları kafese koyar, kilidi siz takarsınız

Pilottan gerçek sisteme geçerken neden bir kafes lazım

Bir ajanı sohbet penceresinde denemek ile ona e-posta kutunuzu, paylaşılan klasörlerinizi ve API anahtarlarınızı vermek arasında büyük fark var. İlkinde en kötü senaryo saçma bir cevaptır. İkincisinde ajan bir dosyayı siler, yanlış adrese veri gönderir ya da bir kimlik bilgisini sızdırır.

NVIDIA'nın OpenShell'i tam bu boşluğa yerleştiriliyor. CBS News'in haberine göre şirket, ajanların komutlara uymadığı ve başka sistemlere sızdığı olaylardan sonra "bağımsız güvenlik kontrollerine" ihtiyaç olduğunu söyleyerek platformu yayımladı. Aynı haberde NVIDIA, platformu 100'den fazla kuruluşun kullandığını da belirtiyor.

Resmi tanım şöyle: OpenShell, otonom ajan filolarını kernel seviyesinde izole edilmiş sandbox'larda çalıştırmak için tasarlanmış açık kaynak bir çalışma ortamı. Sandbox kontrollerini bildirimsel bir YAML politikasıyla birleştiriyor, böylece ajan yerel dosyalara, kimlik bilgilerine ve dış ağlara sınırsız erişim kazanmıyor. Bu incelemede pazarlama cümlesinin ötesine geçip neyin gerçekten kilitlendiğine bakacağız.

Kafesin parçaları ve politikanın beş bölümü

Dokümantasyon sistemi üç parçaya ayırıyor: sandbox'ları ve politikaları yöneten bir Gateway, her sandbox için ajanın süreci dışından gelen istekleri karşılayan bir Supervisor ve sandbox'ın kendisi. Bu ayrım önemli, çünkü kontrol mantığı ajanın çalıştığı süreçten bağımsız duruyor. Ajan ele geçirilse bile kendi kurallarını yeniden yazamıyor.

Sandbox politikaları beş bölümden oluşabiliyor ve her biri farklı bir anda, farklı bir mekanizmayla uygulanıyor. Pratikte bunu bilmek, hangi değişikliğin sandbox'ı yeniden kurmayı gerektirdiğini anlamanızı sağlıyor.

Bunlara ek olarak güvenlik rehberi, Supervisor'ın başlangıçta yetkileri düşürdüğünü, seccomp filtreleri uyguladığını ve süreç kısıtlamalarını devreye aldığını söylüyor. Sandbox'ların varsayılan olarak model sağlayıcılarına bile erişimi yok. Yani ajanın konuşacağı LLM uç noktasını da açıkça tanımlamanız gerekiyor.

• filesystem_policy: sandbox başlarken kernel'deki Landlock LSM tarafından uygulanır.
• Süreç kullanıcısı ve grubu: sandbox oluşturulurken Docker ya da Podman tarafından belirlenir.
• network_policies: sandbox çalışırken ağ proxy'si tarafından uygulanır.
• network_middlewares: yine çalışma anında, ağ proxy'si katmanında devreye girer.
• Varsayılan davranış: network_policies içinde izin verilmeyen her giden bağlantı engellenir.

Asıl iş ağ proxy'sinde dönüyor

Dosya sistemi kısıtlaması önemli ama bir ajanın en çok zarar verebileceği yer genellikle ağdır. Red Hat'in analizine göre OpenShell'in çekirdek mekanizması bir çıkış proxy'si. Tüm giden HTTP, HTTPS ve ham TCP trafiği bu proxy'den geçiyor; hedef, port, çağrıyı yapan ikili dosya ve isteğe bağlı olarak HTTP metodu ile yolu kontrol ediliyor.

Çağıran ikili dosyaya göre karar verebilmek küçük bir ayrıntı gibi görünse de değerli. Aynı sandbox içinde ajanın ana süreci bir API'ye ulaşabilirken, ajanın indirip çalıştırdığı rastgele bir betik aynı adrese gidemiyor. Klasik konteyner ağ kurallarıyla bunu yapmak çok daha zahmetli.

Bir uyarı var: rehber, allow_uninspected_credentials ayarının L7 görünürlüğünü kaldırdığını ve yalnızca istisnai durumlarda kullanılması gerektiğini açıkça yazıyor. Bir entegrasyon çalışmadığında ilk refleks bu tür ayarları açmak olur. Bunu yaptığınızda proxy'nin size sağladığı görünürlüğün önemli bir kısmından vazgeçmiş oluyorsunuz.

Reddedilen istekler için bir de Policy Advisor var. Ajan, engellenen bir istekten sonra dar kapsamlı bir ağ politikası değişikliği önerebiliyor; geliştirici bunu sandbox dışından onaylıyor ya da reddediyor. Varsayılan olarak her öneri insan incelemesi için bir taslak kutusuna düşüyor. İsteğe bağlı otomatik mod ise yalnızca doğrulayıcı izinlerde değişiklik bulmadığında ve kural güvenlik notu üretmediğinde onay veriyor. Bence ilk aylarda otomatik moda hiç dokunmamak doğru tercih.

NVIDIA GPU'suna bağlıyor mu?

Kısa cevap hayır. Uygulamalı bir incelemeye göre README; Linux, Apple Silicon'lu macOS ya da WSL 2 ile Windows (deneysel olarak işaretli) istiyor. Bunun yanında Docker, Podman veya MicroVM sandbox'ları için ana makine sanallaştırması gerekiyor. Gateway Kubernetes'i de destekliyor.

GPU tarafı isteğe bağlı. NVIDIA'nın anlatımına göre CLI sandbox'ları uzak bir GPU sunucusuna dağıtabiliyor, --gpu bayrağı GPU geçişini açıyor ve inference.local yönlendirmesi istekleri Ollama, vLLM gibi yerel arka uçlara gönderebiliyor. Verisini dışarı çıkarmak istemeyen ekipler için yerel model ile sandbox'ı aynı çatı altında toplamak cazip bir seçenek.

Öte yandan NVIDIA'nın ticari bir hikâyesi de var. Ekim 2026'da GTC Berlin'de duyurulan referans mimaride modeller Rubin GPU'larda, ajanlar Vera CPU'larda OpenShell sandbox'ları içinde çalışıyor, BlueField DPU'lar donanım bekçisi rolü üstleniyor. Aynı kaynak yalnızca çalışma ortamının açık kaynak olduğunu, donanımın ve Sentry çerçevesinin NVIDIA ürünleri olduğunu vurguluyor. Yazılımı kullanmak için bu mimariye ihtiyacınız yok, ama yol haritasının nereye çekileceğini akılda tutmakta fayda var.

Küçük bir ekip için kurulum nasıl görünüyor

Kurulum tek satırlık bir kabuk betiğiyle yapılıyor ve varsayılan sandbox imajı içinde hiçbir ajan kurulu olmayan minimal bir Ubuntu. Yani kutudan çıkar çıkmaz çalışan bir asistan beklemeyin; boş ve kilitli bir oda alıyorsunuz.

İlk ajanı çalıştırma rehberi akışı netleştiriyor. Örnekte /usr/local/bin/opencode yolundaki ajanın yalnızca openrouter.ai adresine ulaşmasına izin veriliyor. Bu yaklaşım, "ajan neye erişebilir" sorusunu her ajan için yazılı bir listeye dönüştürmeye zorluyor ve bence aracın en faydalı yan etkisi bu.

Desteklenen ajan tarafında liste geniş. NVIDIA'nın sayfası Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw ve OpenCode'u sayıyor ve kendi ajanlarınızı, kendi sandbox imajlarınızı kullanabileceğinizi belirtiyor. 0.1.0 sürüm yazısı da mevcut ajanları yeniden yazmadan sarmaladığını söylüyor.

E-posta, dosya ve iç API'lere erişen üç dört ajanlık bir kurulumda asıl zaman teknik kurulumda değil, politika yazımında geçecek. Her ajan için hangi klasörü okuyacağını, hangisine yazacağını, hangi alan adına hangi portla çıkacağını tek tek düşünmeniz gerekiyor. Bu çalışmayı yapmaya vakti olmayan bir ekip için OpenShell sadece daha karmaşık bir Docker kurulumu olur.

• Bir sağlayıcı profili oluşturun: ajanın kullanabileceği kimlik bilgileri, servis uç noktaları ve çalıştırılabilir dosya yolları.
• Bir imaj seçin (varsayılan minimal Ubuntu ya da kendi imajınız).
• Bir politika yazın: dosya sistemi, süreç ve ağ kuralları.
• Ajanı ana süreç olarak atayıp sandbox'ı oluşturun.
• İlk günlerde logları izleyip reddedilen istekleri tek tek değerlendirin.

Docker sbx, VM ve katmanlı yaklaşım karşısında

OpenShell tek seçenek değil. Bir karşılaştırma yazısı, OpenShell'in kernel seviyesindeki Landlock ve seccomp uygulamasının üzerine bir politika motoru ve gizlilik yönlendiricisi eklediğini anlatıyor. Docker sbx ise her ajanı ayrı Linux kernel'ine sahip kendi microVM'inde çalıştırıyor; bu daha güçlü izolasyon demek ama daha fazla kaynak tüketiyor.

Aynı yazı pratik bir sınırlamaya da dikkat çekiyor: OpenShell'de statik dosya sistemi politikalarını değiştirmek sandbox'ı yeniden oluşturmayı gerektiriyor. Ajanların ihtiyaçları sık değişiyorsa bu can sıkıcı olabilir, ama bir yandan da dosya izinlerinin çalışma anında sessizce genişlememesi anlamına geliyor.

Bence en olgun cevap "ya o ya bu" değil. Red Hat, OpenShell'i OpenShift sandboxed containers VM'i içinde çalıştırarak ikinci, VM seviyesinde bir izolasyon katmanı eklemeyi öneriyor. Kernel paylaşan bir sandbox'ın kernel açığına karşı savunmasız kalabileceğini düşünürseniz, gerçekten hassas işlerde bu katmanlı yapı mantıklı.

Çözmediği şeyler: izinler, denetim ve veri sızıntısı

OpenShell bir sınırlama katmanı, bir güvenlik garantisi değil. Bağımsız bir incelemenin en isabetli tespiti şu: araç yetkisiz bir dosya yazımını ya da ağ isteğini engelleyebilir, ama eksik bir politika aynı iş sonucuna giden dolaylı yolların hepsini yakalamaz. Örneğin ajanın müşteri listesini dışarı göndermesini engellediniz; peki izinli olduğu bir API üzerinden aynı veriyi bir nota yapıştırmasını da düşündünüz mü?

İzin tasarımı tamamen sizde. Proxy, ajanın izinli bir e-posta servisine bağlanmasına izin veriyorsa, o servisin içinde kime ne gönderdiğini anlamak sizin uygulama katmanınızın işi. OpenShell hangi kapının açık olduğunu denetler; açık kapıdan geçen içeriğin iş açısından doğru olup olmadığına karar vermez.

Denetlenebilirlik tarafında temel iyi kurulmuş. Geliştirici rehberi sandbox loglarını CLI ve terminal arayüzüyle okumayı ve OCSF formatında JSON kayıt olarak dışa aktarmayı anlatıyor. Kalıcı loglar her izin ve ret kararını hedef, ikili dosya ve gerekçeyle birlikte tutuyor. Ancak bu logları bir SIEM'e bağlamak, kimin bakacağını belirlemek ve alarm kurmak yine sizin işiniz.

Veri sızıntısı için de aynı mantık geçerli. Varsayılan ret politikası en kaba sızıntı yollarını kapatıyor, ama izinli bir model sağlayıcısına giden istemlerin içinde ne olduğunu kimse sizin yerinize kontrol etmiyor. Hassas veri ile çalışıyorsanız yerel model yönlendirmesi bu riski azaltmanın daha somut bir yolu.

Olgunluk, lisans ve kimin şimdi denemesi gerektiği

Lisans tarafında sürpriz yok. Wikipedia projeyi Apache 2.0 lisanslı, Rust, Go ve Shell ile yazılmış olarak listeliyor; 0.1.0 sürümüyle politika doğrulama, kimlik bilgisi korumalı servis erişimi, çok kiracılı destek ve CPU/GPU çalıştırma eklendiğini belirtiyor. GitHub deposu yaklaşık 17,6 bin yıldız ve 1,8 bin fork gösteriyor, GOVERNANCE.md, MAINTAINERS.md ve CONTRIBUTING.md dosyalarını barındırıyor.

Yine de sürüm numarası 0.1.x. İlgi yüksek, yönetişim dosyaları yerinde, dokümantasyon beklenenden derli toplu; ama API'lerin ve politika şemasının oturduğunu söylemek için erken. Bugün yazdığınız politikaların birkaç sürüm sonra elden geçmesi gerekebilir.

Şimdi denemesi gerekenler: kod yazan ajanları ya da iç altyapı otomasyonlarını kontrollü bir ortamda çalıştıran, Linux ve konteyner bilgisi olan ekipler. İncelemeyi yapan bağımsız yazar da pilotu tam olarak bu tür işler için öneriyor. Bekleyebilecekler: ajanları doğrudan müşteri verisine ve finansal işlemlere bağlamayı düşünen, ama politika yazacak ve logları izleyecek kimsesi olmayan ekipler. Bu durumda önce yetki modelinizi kâğıt üzerinde çıkarın, sonra aracı seçin.

Benim kişisel görüşüm şu: OpenShell, ajanların neye erişebileceğini yazılı ve denetlenebilir hale getirmek için şu an elimizdeki en derli toplu açık kaynak seçeneklerden biri. Ama bir sandbox'ın varlığını, üretimdeki bir ajanın güvenli olduğunun kanıtı saymayın. Kafes iyi; kapıyı nereye açtığınız hâlâ sizin kararınız.