AIREITERDosyaları düzenleyebilen, paket kurabilen ve API çağırabilen bir coding agent’ı yalnızca system prompt’a eklenmiş bir uyarıyla başıboş bırakmak yeterli değil. NVIDIA OpenShell bu yetkileri agent’ın dışına taşıyıp politika zorunlu bir sandbox içinde sınırlandırıyor. Ancak eksiksiz politikaları yazma ve kurulumunuzu doğrulama yükü hâlâ sizin üzerinizde.
Kısa karar: OpenShell bir runtime sınırı, agent framework’ü değil
NVIDIA OpenShell, otonom agent’lar için açık kaynaklı bir runtime. 0.1.x belgelerinde Gateway, her sandbox için bir Supervisor, kernel seviyesinde uygulanan dosya sistemi ve process kontrolleri, aracılı ağ erişimi, kimlik bilgisi bağlama ve politika inceleme araçları tanımlanıyor. NVIDIA’nın 28 Eylül 2026 tarihli teknik blog yazısına göre OpenShell, Codex ve Claude Code gibi agent’ları yeniden yazmadan çevrelemek üzere tasarlanmış (NVIDIA Technical Blog).
Buradaki kritik ayrım, çevreleme ile zekâ arasındaki farkta yatıyor: OpenShell yetkisiz bir dosya yazma veya ağ isteğini engelleyebilir; ancak eksik bir politikanın, aynı iş aksiyonuna giden tüm dolaylı yolları anlamasını sağlayamaz. Bu nedenle OpenShell’i kontrollü coding ve agent altyapısı için pilot projelerde değerlendirirdim. Üretimde çalışan bir agent’ın güvenli olduğunun kanıtı olarak ise tek başına sandbox’a güvenmezdim.
OpenShell gerçekte neleri kontrol ediyor?
OpenShell, filo yönetimiyle iş yükünü birbirinden ayırıyor. Gateway sandbox’ları ve politikaları yönetiyor, Supervisor iş yükünün dışına çıkan istekleri aracılık ederek denetliyor, Sandbox ise agent’ı işletim sistemi kısıtlamaları altında çalıştırıyor (NVIDIA Technical Blog).
| Katman | Neyi korur? | Çalışırken değiştirilebilir mi? |
|---|---|---|
| Dosya sistemi | Dosyalar ve dizinler | Hayır; sandbox yeniden oluşturulmalı |
| Process | Yetkiler ve sistem çağrılarının davranışı | Hayır; sandbox yeniden oluşturulmalı |
| Ağ | Host’lar, portlar, binary’ler ve seçili API operasyonları | Evet |
| Sağlayıcı kimlik bilgileri | Onaylanmış endpoint’lerde kullanılan sırlar | Evet |
OpenShell, politikaları uygulama katmanının altında devreye alıyor ve yeniden kullanılabilir kimlik bilgilerini agent’ın dışında tutuyor. Bu bilgileri yalnızca onaylanmış isteklere bağlıyor (OpenShell README).
“OpenShell, otonom AI agent filoları için güvenli ve gizli bir runtime’dır.” — NVIDIA OpenShell README (kaynak)
Güvenlik modeli sınırda güçlü, politika tasarımında ise daha kırılgan
OpenShell’in belgelenen kontrolleri, altyapının çeşitli sınırlarında varsayılan olarak kapalı davranabildiği için değerli. Ancak agent’ın birleştirmesine izin verilen aksiyonları modellemenin yerini tutmuyor.
Dosya sistemi, process ve ağ kontrolleri tek bir operasyonel tabloda
Güncel güvenlik rehberinde dosya sistemi erişimi için Landlock, process kısıtlamaları için seccomp ve yetki düşürme, dışarı yönlü trafik içinse OPA politika değerlendirmeli bir CONNECT proxy’si anlatılıyor (OpenShell Security Best Practices). Listelenmeyen dosya sistemi yollarına erişim yok; dışarı yönlü trafik varsayılan olarak engelleniyor ve ağ kuralları erişimi belirli bir binary kimliğine bağlayabiliyor.
Ağ kuralları yalnızca host ve port kontrolüyle sınırlı değil. REST politikaları method ve path bilgilerini, GraphQL politikaları operasyonları ve root field’ları, WebSocket politikaları ise handshake ve mesajları inceleyebiliyor. Bunun operasyonel bedeli açık: geniş kuralları çalışır durumda tutmak daha kolay, dar kuralları savunmak ise daha kolay.
Dosya sistemi ve process kısıtlamaları sandbox başlatılırken sabitleniyor. Ağ izinleri çalışan bir sandbox üzerinde güncellenebiliyor; ancak verilen bir onay, o sandbox instance’ı için kalıcı bir politika revizyonuna dönüşüyor. Böylece politika üzerinde iterasyon yapmak kolaylaşıyor ama tüm kontroller değişken hâle gelmiyor.
Kimlik bilgileri aracılık üzerinden korunuyor; sihirli biçimde zararsız hâle gelmiyor
Kimlik bilgilerine aracılık edilmesi maruziyeti azaltıyor, fakat gereğinden fazla yetkili bir endpoint’i güvenli hâle getirmiyor. Salt okunur bir API politikası, teknik olarak yazma yetkisi bulunan bir credential’ın kullanım alanını daraltabilir; ancak zaten yıkıcı operasyonlara izin veren bir politikayı düzeltemez.
Güvenlik rehberi, L7 kurallarına audit modunda başlanmasını, gerçek isteklerin incelenmesini ve ardından enforce moduna geçilmesini öneriyor. Audit modu ihlalleri günlüğe kaydediyor ama istekleri iletmeye devam ediyor. Yani bu mod üretimde engelleme mekanizması değil, keşif aşaması.
Demo ile güvenlik sonucunu karıştırmadan OpenShell nasıl değerlendirilir?
NVIDIA’nın resmi tutorial’ı, engellenen erişimi, salt okunur kuralları ve çalışan politikaların değiştirilmesini göstermek için curl ile kimlik doğrulaması gerektirmeyen GitHub REST API’sini kullanıyor. Bu bir öğrenme yolu; bağımsız bir benchmark değil (NVIDIA Technical Blog).
Tutorial’ı kullanarak şu üç kurulum sorusuna yanıt arayın:
- Agent’ınız ağ erişimi olmadan başlayıp yalnızca ihtiyaç duyduğu endpoint’lere erişim alabiliyor mu?
- API’lerinizde okuma ve yazma operasyonları arasındaki kritik ayrımı ifade edebiliyor musunuz?
- Operasyon ekibiniz, agent’a kendi isteğini onaylama yetkisi vermeden retleri ve politika revizyonlarını inceleyebiliyor mu?
Gerçek bir pilotta adversarial senaryoları da ekleyin: symlink ve path traversal denemeleri, paket kurulumu, shell alt process’leri, alternatif binary’ler, yanlış host’a gönderilen credential placeholder’ları ve tek tek izin verilen aksiyonların birleşimleri. Herkese açık materyaller latency, başlangıç maliyeti veya bağımsız escape oranı ölçümleri sunmuyor. Bu nedenle ürünün mimari iddialarını test sonucu gibi kullanmak yerine kendi ortamınızda bu metrikleri ölçün.
Üretim kararını zorlaştırabilecek noktalar
Üretim kararı verirken üç kısıt özellikle belirleyici olmalı:
- Olgunluk ve uyumluluk. Repository; Linux, Apple Silicon macOS ve deneysel WSL 2 üzerinden Windows desteğini, ayrıca çalıştırma seçenekleri olarak Docker, Podman veya host sanallaştırmasını listeliyor. Kubernetes için
NetworkPolicyuygulayan bir CNI gerekiyor. Kubernetes user namespace’leri de güncel kernel, Kubernetes ve runtime sürümleri gerektiriyor; bu kombinasyonda GPU uyumluluğu ise doğrulanmış değil (OpenShell README; Security Best Practices). - Politikaların birlikte çalışması. @liyun0016 tarafından paylaşılan gerçek kullanıcı testinde açık deny testleri başarılı olmuş; ancak bir repository’yi düzenlemek, CI’ı değiştirmek ve CI’ı tetiklemek birleşerek yetkisiz bir production yoluna dönüşebilmiş (gönderi). OpenShell yazdığınız kuralları uyguluyor; unutulmuş iş seviyesi kurallarını sizin yerinize tanımlamıyor.
- Kanıt kalitesi. NVIDIA, korunan repository’lere hiç yazma yapılmadığını gösteren uzun süreli adversarial deneyler raporluyor. Ancak atıf yapılan teknik materyallerde model sayıları, baseline’lar, false-positive oranları veya bağımsız tekrar sonuçları paylaşılmıyor. Bu verileri sertifikasyon değil, üretici kanıtı olarak değerlendirin.
“OpenShell, verdiğiniz kuralları uygulama konusunda açıkça başarılı. Ancak ... asıl darboğaz politika katmanı gibi görünüyor.” — @liyun0016 (kaynak)
NVIDIA OpenShell’i şu anda kimler kullanmalı?
| Durum | Karar |
|---|---|
| Hassas dosyalara erişen yerel coding agent | Linux/macOS runtime gereksinimleri uyuyorsa ve politikalar dar kapsamla başlatılıyorsa pilot için değerlendirilebilir |
| Birden fazla workspace kullanan ekip agent filosu | Ekiplerin izole workspace’lere, ortak politika incelemesine ve credential aracılığına ihtiyacı varsa uygun |
| GPU ağırlıklı Kubernetes kurulumu | Dikkatli pilot yapın; user namespace ve GPU uyumluluğu ayrıca doğrulanmalı |
| Geniş iş yetkileriyle gözetimsiz çalışan production agent | Tek başına OpenShell’e güvenmeyin; iş onayları, aksiyon seviyesinde kontroller, loglama ve geri alma mekanizmaları ekleyin |
| Yalnızca basit bir Python code sandbox ihtiyacı | Amaca özel bir sandbox’ı da karşılaştırın; OpenShell ihtiyacınızdan daha büyük bir control plane olabilir |
Benim önerim kapsamlı bir geçiş değil, sınırları belirlenmiş bir pilot: tek bir agent, tek bir workspace, varsayılan olarak her şeyi reddeden bir ağ politikası ve geri alınabilir küçük bir görev seti seçin. Engellenen isteklerin gürültü seviyesini, başlangıç süresini, politika bakım yükünü ve izin verilen aksiyonlar dizisinin bir iş sınırını aşıp aşamadığını ölçün.
NVIDIA OpenShell SSS
NVIDIA OpenShell için NVIDIA GPU gerekiyor mu?
README, CPU ve GPU çalıştırma yollarını belgeliyor; Docker, Podman ve host sanallaştırmasını da listeliyor. Runtime’ın NVIDIA GPU gerektirdiği belirtilmiyor, ancak ihtiyaç duyduğunuz sürücü ve kurulum kombinasyonunu ayrıca doğrulamalısınız.
OpenShell production-ready mi?
OpenShell 0.1.x belgelenmiş bir release hattına sahip. Ancak resmi materyallerde bağımsız güvenlik sertifikası veya kapsamlı performans benchmark’ları bulunmuyor. Bu nedenle onu evrensel bir production garantisi olarak değil, kendi tehdit modeliniz içinde doğrulamanız gereken bir altyapı olarak değerlendirin. Repository Apache License 2.0 lisansını listeliyor; kendi compute kaynaklarınızı, gateway operasyonlarınızı, politika bakımınızı ve güvenlik testlerinizi bütçelendirin (OpenShell README).
Genel karar: Geçer.
OpenShell Claude Code veya Codex çalıştırabilir mi?
NVIDIA’nın teknik blogu Claude Code ve Codex’i uyumlu agent’lar arasında sayıyor. Runtime, mevcut agent iş yüklerini yeniden yazmayı gerektirmek yerine onları çevrelemek üzere tasarlanmış.
Sandbox yeniden oluşturulmadan dosya sistemi kuralları değiştirilebilir mi?
Hayır. Güvenlik rehberi dosya sistemi ve process kontrollerini statik olarak sınıflandırıyor. Ağ politikaları ve sağlayıcı atamaları sandbox çalışırken değiştirilebiliyor.
OpenShell ile Docker arasındaki fark nedir?
Docker bir containerization primitive’i sunar. OpenShell ise dosya sistemi, process, ağ, API operasyonu, credential ve politika inceleme kontrolleri için agent odaklı bir politika katmanı ekler. İkisi aynı kurulumda birlikte de kullanılabilir.