jai - AI ajanları için kolay yalıtım aracı

 (jai.scs.stanford.edu)
3 puan yazan GN⁺ 2026-03-29 | 1 yorum | WhatsApp'ta paylaş
  • Linux ortamında AI ajanlarını yalıtılmış olarak çalıştırmak için kullanılan hafif bir araç; karmaşık konteyner ayarları olmadan tek bir komutla güvenli bir çalışma sınırı sağlar
  • AI araçlarının gerçek dosya sistemine erişip verileri silmesi veya bozması yönündeki vakalar art arda yaşanırken, güvenli çalışma ortamı ihtiyacı öne çıkıyor
  • Ev dizinini copy-on-write overlay ile korur ve /tmp ile /var/tmp dizinlerini ayırarak özgün dosyaların değiştirilmesini engeller
  • Güvenlik seviyesi ve erişim kapsamının seçilebilmesi için üç yalıtım modu sunar: Casual, Strict ve Bare
  • Stanford araştırma ekibi tarafından geliştirilen açık kaynak proje, AI araçlarını daha güvenli kullanmak için pratik bir koruma yöntemi sunuyor

AI ajanlarının yalıtımı için hafif araç jai

  • jai, Linux ortamında AI ajanlarını kolayca yalıtmak (containment) için tasarlanmış bir araçtır
    • Karmaşık konteyner veya VM yapılandırmaları olmadan, tek bir komutla güvenli bir çalışma sınırı sağlar
    • Kod yazma yardımcıları ya da script çalıştırma gibi mevcut iş akışlarına doğrudan uygulanabilir

  • Gerçek sorun örnekleri

    • Birçok kullanıcı, AI araçlarını kullanırken dosya kaybı ve dizin silinmesi yaşadığını bildirdi
      • Nick Davidov, terminal komutuyla 15 yıllık aile fotoğraflarının silindiğini bildirdi
      • Anthropic'in Claude Code aracı, ev dizinini silerek geliştirme projelerinin kaybolmasına yol açtı
      • Cursor'un çalışma ağacını boşalttığı ve “her şeyin kaybolduğu” bildirildi
      • Bir Reddit kullanıcısı, Antigravity'nin tüm D sürücüsünü sildiğini belirtti
      • Başka bir Cursor kullanıcısı ise 100 GB dosyanın silindiğini bildirdi
    • Bu örnekler, AI araçlarına gerçek kullanıcı hesabı erişimi verildiğinde ortaya çıkan güvenlik boşluğunu gösteriyor

  • jai'nin temel özellikleri

    • Çalıştırma hesabı ile ev dizini arasındaki sınırı otomatik olarak kurar
      • Çalışma dizini tam okuma/yazma iznini korur
      • Ev dizini, özgün dosyaların değişmemesi için copy-on-write overlay ile korunur
      • /tmp ve /var/tmp bağımsız alanlara ayrılır, diğer dosyalar ise salt okunur olarak sınırlandırılır
    • Komutun başına yalnızca jai ekleyerek yalıtılmış çalıştırma mümkündür
      • Örnek: jai codex, jai claude veya yalnızca jai ile shell çalıştırma
    • Dockerfile ya da imaj derleme süreci olmadan hemen kullanılabilir
      • Karmaşık bwrap bayrakları ayarlamaya veya script yazmaya gerek yoktur

  • Yalıtım modu seçimi

    • Üç mod sunulur: Casual / Strict / Bare
      • Casual: Ev dizinini copy-on-write ile korur, dosyaların çoğu okunabilir
      • Strict: Ayrı bir jai kullanıcısı olarak çalışır, boş bir ev diziniyle güçlü yalıtım sağlar
      • Bare: Ev dizini boş başlar ama kullanıcı UID'si korunur
    • Her modun gizlilik (confidentiality), bütünlük (integrity) ve NFS desteği farklıdır
      • Strict modu en güçlü yalıtımı sağlar, ancak NFS home desteği yoktur

  • Alternatif araçlarla karşılaştırma

    • Docker
      • İmaj tabanlı ortamların yeniden üretimi için uygundur, ancak host araçlarının geçici sandbox'ı için ağır kalır
      • Ev dizini overlay özelliği yoktur
    • bubblewrap
      • Güçlü bir namespace sandbox'ıdır, ancak dosya sistemi yapısının elle tanımlanmasını gerektirir
      • jai bu karmaşıklığı ortadan kaldırır
    • chroot
      • Bir güvenlik yalıtım aracı değildir; mount, PID namespace ve ayrıcalık ayrımı özellikleri olmadığından Linux'ta da sandbox amacıyla önerilmez

  • Güvenlik sınırları

    • jai, tam güvenliği garanti etmez
      • Bir “casual sandbox” olarak hasarın kapsamını azaltır, ancak tüm saldırıları engellemez
      • Casual modu gizlilik korumasında zayıftır; Strict modu da konteyner veya VM düzeyinde bir yalıtımla aynı değildir
      • Çok kiracılı ortamlarda veya yüksek riskli durumlarda konteyner ya da sanal makine kullanılması önerilir

  • Projenin arka planı

    • Stanford Secure Computer Systems(SCS) araştırma grubu ile Future of Digital Currency Initiative(FDCI) tarafından ortak geliştirildi
    • Ücretsiz açık kaynak yazılım olarak sunuluyor ve kullanıcıların AI'ı daha güvenli şekilde kullanmasına yardımcı olmayı amaçlıyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-29
Hacker News yorumları

  • .claude/settings.json dosyasına aşağıdaki ayarı eklemek yeterli

    {
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"],
      "allowWrite": ["."],
      "denyWrite": ["/"]
    }
  }
}

    Dış dizinlere erişime izin vermek için allowRead kısmını değiştirmek yeterli
    Bu özellik 10 gün önce eklenen yeni bir sandbox seçeneği

    • Claude'un mevcut dizini karıştırdığını ya da rm -rf * gibi komutlar çalıştırdığını gördüm
      Neyse ki ikisi aynı anda olmadı, ama düşüncesi bile ürkütücü
      Sandbox fikri iyi, ama etkili olabilmesi için alt seviyede zorunlu olarak uygulanması gerekiyor
      Claude'un kendisi de yapay zeka tarafından üretilmiş devasa bir program olduğu için, insanların doğrudan yazdığı 3000 satırdan kısa bir güvenlik katmanı eklemek anlamlı bir savunma olabilir
    • claude-code'un gelecekteki sürümleri bu ayar adını sessizce değiştirebilir ya da kaldırabilir
      Bu yüzden insanlar ayrı sandbox yazılımlarını tercih edebilir
    • GPU kullanımına izin verip sadece / silinmesini engelleyen şaka yollu bir ayar örneği paylaşıldı
      /dev/nvidia* aygıt erişimine izin veren bu yapılandırma, veri sızıntısını göze alan hicivli bir ayar
    • On yıllardır kendini kanıtlamış mevcut güvenlik araçları zaten var
      Claude'u sınırlı yetkilere sahip bir kullanıcı olarak çalıştırırsanız, izolasyon alt süreçlere de otomatik olarak miras kalır
    • Linux'ta (Arch) ve macOS'ta (Tahoe) sandbox özelliği düzgün çalışmadı
      İlgili issue açılmış durumda
      bubblewrap ve seatbelt tek başlarına düzgün çalışıyor, ancak claude-code üzerinden çalıştırıldıklarında devre dışıymış gibi görünüyor

  • İnsanların AI agent'ları kişisel bilgisayarlarına bu kadar kolay kurması şaşırtıcı
    On yıllardır sistem güvenliğini koruduk, sonra bir anda tüm yetkileri öngörülemez yazılımlara verdik

    • Eskiden de build araçları bağımlılıkları otomatik çekmeye başladığında uyarıları görmezden geldik; şimdi ise tedarik zinciri saldırıları tekrar tekrar yaşanıyor
      Kısa vadeli rahatlık, uzun vadeli güvenliğin önüne geçiyor
    • Aslında bu riski alanlarla güvenliği önemseyenler farklı iki grup
    • Şirket ortamlarında erişim zaten kısıtlı olduğu için bu mesele asıl kişisel PC'lerde daha hassas
      Benim uzak geliştirme VM'imde Claude'un görmesinde sakınca olmayan veriler var
    • Docker'ın ilk günlerinde de hava “imajı indir geç!” şeklindeydi
      Ama sektör kısa süre içinde güvenlik risklerini fark edip önlem aldı

  • Basit Unix yetki ayrımı da yeterli olabilir
    İki kullanıcı hesabı açıp yalnızca AI ile paylaşılacak klasörleri aynı grupta toplamak yeterli
    İlgili blog yazısına bakılabilir

  • Ana sayfada “körü körüne güvenmeyi bırakın” yazıyor, ama kurulum yöntemi curl | bash yerine manuel derleme

    • tar dosyasını elle açıp makepkg -i ile kurmak çok daha güvenli
      PKGFILE yaklaşık 30 satır uzunluğunda ve build fonksiyonu da sadece 7 satır
      Buna karşılık rustup (910 satır), claude (158 satır), opencode (460 satır) gibi script'ler çok daha karmaşık
    • Öte yandan curl | tar | makepkg şeklinde tek satırda zincirlemek güvenilir bir yöntem değil

  • Bu proje iyi tasarlanmış ve benim yöntemime göre biraz daha güvenli ve kullanışlı görünüyor
    Ben agent'ı ayrı bir kullanıcı hesabı oluşturarak izole ediyorum
    Yalnız bazen izinler karışıyor, onları da script ile düzeltiyorum
    Sonuçta en sağlam yöntem ona tamamen ayrı bir laptop vermek
    Fiziksel olarak ayrılmış donanım kadar güvenli bir şey yok

    • Ama dış servislerle iletişim kurması için API anahtarları vermek gerekiyor; bu anahtarların sızma riski var
      Agent'lar güvenlik sızma testi düzeyinde yeteneklere sahip olduğundan, basit kullanıcı ayrımı tek başına tedirgin edici olabiliyor
    • Ben de şu an kullanıcı ayrımı yöntemini kullanıyorum
      Container kullanınca agent kendi kendine container oluşturmaya çalıştığında kafası karışıyor

  • Site “vibe-coded” göründüğü için kalitesiz izlenimi veriyor, ama aracın kendisini bizzat bir Stanford profesörü geliştirmiş
    SSS bağlantısına bakılabilir

    • Yazarı olarak bizzat söyleyeyim: web tasarımından anlamam ama işletim sistemi uzmanıyım
      Dokümandaki içeriği doğru şekilde düzelttim, o yüzden güvenilebilir
      Siteyi AI'ın ürettiği haliyle bırakmış olmam da biraz ironik
    • Yazar David Mazieres; 2000'lerin başından beri kullanıcı düzeyi dosya sistemleri üzerine çalışan biri
      Stanford Secure Computer Systems grubuna liderlik ediyor
    • jai yüksek riskli bir araç, ama web sitesi basit olduğu için vibe-coded olması çok da sorun değil
    • Yine de kişisel olarak sade bir HTML sayfasını tercih ederim

  • Agent'ın proje dizinine yazma yetkisi varsa kalıcı exploit mümkün olması endişe verici
    .pyc, .venv, .git/hooks gibi dosyalar üzerinden sandbox dışından çalıştırma yapılabilir
    ChatGPT konuşmasında da bu tür açıklar doğrulandı
    Bu yüzden en güvenli yöntem git patch tabanlı dosya aktarımı
    Sandbox içinde değiştirilen dosyaların yalnızca git'e commit edilmiş olanlarını dışarı aktarmak gerekiyor

    • .git/ dizinini salt okunur yapacak bir seçenek eklemek iyi olabilir
      jai -D ile CWD bir overlay'e dönüştürülebiliyor, ama değişiklikleri birleştirmek zahmetli
    • Ben kodu doğrudan yalnızca sandbox (VM düzeyi) içinde çalıştırıyorum
      Agent ayrı bir git worktree branch'inde çalışıyor ve ancak incelemeden sonra birleştiriliyor
      Böylece inceleme temelli güvenlik akışı korunabiliyor
    • git hook'lara asla izin verilmemeli

  • Basit bir alternatif olarak agent'ı ayrı bir kullanıcı hesabında ssh üzerinden çalıştırıyorum
    Proje dizinini bind mount ederek erişimi kontrol ediyorum
    VSCode'un ssh remote özelliğiyle iyi uyum sağlıyor

    • Ben de 6 aydır özel bir hesap kullanıyorum; sadece erişebildiği dizinleri yönetmek yetiyor
      Karmaşık güvenlik sistemlerinden çok daha basit ve verimli bir izolasyon yöntemi

  • Gerçekte sorunlar rm -rf'ten çok daha ince olabiliyor
    claude-code bir SVG kaydetmek için /public/blog/ klasörünü oluşturdu ve Apache routing bozuldu
    Bu bir silme ya da izin sorunu değildi, ama istenmeyen bir davranış yüzünden blog 404 döndürmeye başladı
    jai bu tür büyük hataları önleyebilir, ama böyle ince sorunlar hâlâ zor

  • Harika bir proje ama başlık zayıf
    Mevcut dizine tam erişim, geri kalanına salt okunur erişim ve home dizinine copy-on-write uygulanması fikri hoşuma gidiyor
    Bu yaklaşım AI agent'lar için varsayılan güvenlik modeli olmalı

    • Sitede başlık olmadığı için “jai - filesystem containment for AI agents” gibi bir ad daha uygun olabilir