Agent Safehouse – macOS için yerel ajan sandbox aracı

 (agent-safehouse.dev)
16 puan yazan GN⁺ 2026-03-09 | 1 yorum | WhatsApp'ta paylaş
  • Yerel yapay zeka ajanlarını, sistemin dışını değiştirememeleri için macOS yerel sandbox ile izole eden bir araç
  • Tüm ajanlar bağımsız sandbox ortamlarında çalışır; bu sayede kullanıcı home dizinine veya diğer projelere erişemez
  • Deny-first erişim modeli uygulanır; yalnızca açıkça izin verilen dizinlerde okuma ve yazma yapılabilir
  • Kurulum tek bir Bash betiği ile tamamlanır; ek derleme ya da bağımlılık olmadan doğrudan çalıştırılabilir
  • LLM tabanlı profil oluşturma özelliğiyle en az ayrıcalıklı sandbox-exec yapılandırması otomatikleştirilebilir

Genel Bakış

  • Agent Safehouse, yerelde çalışan yapay zeka ajanlarının sistem dosyalarına zarar vermesini önleyen, yalnızca macOS için geliştirilmiş bir sandbox sistemidir
    • “Go full --yolo. We've got you.” “Move fast, break nothing”
    • LLM'lerin olasılıksal doğasından kaynaklanan beklenmedik komut çalıştırma riskini engeller
  • Tüm başlıca ajanlar sandbox içinde sorunsuz şekilde çalışır ve dış sistem üzerinde hiçbir etki yaratmaz
  • Deny-first erişim modeli benimsenmiştir; varsayılan olarak tüm erişimler engellenir ve yalnızca açıkça izin verilen yollar erişilebilir
    • Örnek: ~/my-project için okuma/yazma izni vardır; ~/.ssh, ~/.aws, ~/other-repos için erişim reddedilir

Kurulum ve Çalıştırma

  • Kurulum, tek bir shell betiği indirme adımıyla tamamlanır
    • Betik curl komutuyla indirilir, ~/.local/bin/safehouse içine kaydedilir ve çalıştırma izni verilir
  • Sonrasında istenen ajan safehouse komutuyla çalıştırılır
    • Örnek: safehouse claude --dangerously-skip-permissions
  • Safehouse varsayılan olarak geçerli çalışma dizinine (git root) okuma/yazma izni verir ve toolchain dizinleri için salt okunur erişim tanır

Sandbox Doğrulama Örnekleri

  • Hassas dosyalara erişim, çekirdek seviyesinde engellenir
    • safehouse cat ~/.ssh/id_ed25519 çalıştırıldığında “Operation not permitted” hatası oluşur
    • Diğer proje dizinleri (~/other-project) görünmez
    • Geçerli proje dizinine ise normal şekilde erişilebilir

Otomasyon ve Profil Oluşturma

  • Shell fonksiyonu ekleyerek tüm ajanlar varsayılan olarak Safehouse içinde çalıştırılabilir
    • Örnek: .zshrc veya .bashrc içine safe() fonksiyonu tanımlanarak claude, codex, amp, gemini komutları otomatik olarak sandbox içine alınabilir
    • Sandbox olmadan çalıştırmak için command claude biçiminde çağrı yapılabilir
  • LLM tabanlı profil oluşturma özelliği sunulur
    • Claude, Codex, Gemini gibi modeller, Safehouse şablonlarını analiz ederek en az ayrıcalıklı sandbox-exec profili oluşturur
    • Home dizini ve toolchain bilgilerine dayanarak ~/.config/sandbox-exec.profile yoluna kaydedilir
    • Geçerli çalışma dizinine erişim izinleri ve ajana özel kısayol komutlarını içerir

Güvenlik ve Kullanım Açısından Önemi

  • LLM tabanlı yerel ajanların istenmeyen dosya silme veya sistem değişiklikleri yapmasını engeller
  • macOS çekirdek seviyesindeki erişim kontrolünü kullanarak varsayılan olarak güvenli bir çalıştırma ortamı sağlar
  • Tek betik tabanlı yapısı sayesinde geliştirici iş akışına kolayca entegre edilebilir

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-09
Hacker News yorumları

  • Yaptığım projenin bu kadar hızlı duyulacağını bilmiyordum
    1️⃣ Ben yerelde doğrudan çalışan ajanları tercih ediyorum. Container ya da uzak sunucu yerine, ince ayarını kendim yaptığım kendi makinemde çalışması içimi daha rahat ettiriyor
    2️⃣ Bu aslında sandbox-exec için bir politika oluşturucu. Bağımlılığı da yok, sanallaştırma da yok. Bunun yerine her ajanın otomatik güncelleme, anahtarlık entegrasyonu, görsel yapıştırma gibi işlemleri yapabilmesi için gereken en düşük yetkileri bulmaya çok zaman harcadım. İlgili araştırmaları agent-safehouse.dev/docs/agent-investigations altında topladım
    3️⃣ Projenin tamamını kullanmak da gerekmiyor. Sadece Policy Builder ile bile sandbox-exec politikaları üretip dotfiles içine koyarak kullanabilirsiniz

    • Erken paylaşmış olmam için kusura bakma. Daha önce bıraktığın bir yorumu görüp denedim; verimliliği o kadar iyiydi ki yazıyla tanıtılmayı hak ettiğini düşündüm
      Daha önce de sandbox politika belgelerine bakmıştım ama böyle doğrudan kullanılabilir uygulama formunda olanını ilk kez gördüm
      Yine de birkaç rahatsız edici nokta vardı — home dizinindeki .gitconfig, .gitignore erişimi kısıtlanıyor ve süreç erişim kısıtları yüzünden Claude’a lldb ya da pkill gibi komutları çalıştıramıyorum. Ayrıntılı yetki kontrolü olabilse güzel olurdu
    • Bunu openclaw için uygulamak mümkün mü diye merak ediyorum. Yerel makineden erişilebilir biçimde çalıştırmak rahat olur ama aynı anda kontrol etmesi de daha zorlaşıyor
    • Yerelde çalıştırma ile container içinde çalıştırma arasındaki pratik farkın ne olduğunu merak ediyorum
    • Ah, aradığım şey tam olarak buydu. microsandbox’ı oturtmaya çalışıyordum ama bu çok daha gerçekçi görünüyor
      Siteye ve betiklere göz gezdirdim, özel bir sorun bulamadım. Belgelenmemiş herhangi bir dikkat edilmesi gereken nokta var mı?
    • İşin ironik yanı, yapay zekaya güvenmediğim için böyle projeler ilgimi çekiyor ama kurmak için rastgele bir sunucudan .sh dosyası indirip çalıştırmak gerekiyor olması biraz komik
      Keşke tarball olarak dağıtılsa. Tarball olursa içeriğini kendim inceleyebilir ve CI tarafından otomatik üretildiğini de doğrulayabilirim; bu yüzden daha güven verici olur

  • Böyle projeleri görmek sevindirici ve şu anda en büyük meselenin sandboxing olduğunu düşünüyorum
    İlk kullanıcılar ajanları düşünmeden yerelde çalıştıracaktır ama uzun vadede ya da kurumsal ortamlarda bunun yürümesi mümkün değil
    Sadece ağ, dosya ve çalıştırma izinlerini denetlemenin ötesine geçip tarayıcı testi ya da bulut kaynağı oluşturma gibi karmaşık senaryoları da ele almak gerekiyor
    Sonuçta gereken şey, güvenlik, maliyet ve yetki kontrolünü birleştiren pratik bir yaklaşım

    • Ama acaba bu temelden çözülemez bir problem olabilir mi? İşlevsellik ile güvenlik her zaman çatışıyor ve insanlar eninde sonunda ilkini seçiyor
    • Dosya düzeyinde sandboxing zaten temel gereklilik; asıl zor kısım kimlik bilgileri ve ağ kontrolü
      Ben yerel bir daemon’un kısa ömürlü JWT vermesiyle ajanın anahtarları doğrudan ellememesini sağlıyorum. API erişimi için iyi çalışıyor ama dosya sistemi seviyesinde hâlâ sonsuz sayıda EC2 instance ayağa kaldırmak mümkün

  • Sorunlardan biri de farklı sandbox’ları karşılaştırmalı değerlendirmesinin zor olması
    Bu, sandbox-exec için bir wrapper gibi görünüyor ve son zamanlarda bu tür wrapper’lar çoğaldı
    Asıl ihtiyaç duyulan şey güvenilirlik doğrulama belgeleri ve otomatik testler. Sandbox’ların çoğunda belge eksik
    Güvenebilmek için ayrıntılı dokümantasyon ve çalıştığına dair kanıt lazım

    • Bu yüzden Bash ile yazdım — opak binary’lerden kaçınmak için
      Her ajana özel sandbox-exec profilleri GitHub profil klasöründe ayrı tutuluyor ve kolayca incelenebiliyor
      Gerçek ajanlarla E2E testleri de yapıyorum
      Safehouse wrapper’ı olmadan da Policy Builder ile minimum yetkili politikaları doğrudan üretebilirsiniz
      Ayrıca LLM’in sandbox profilleri yazması için bir talimat dosyası da sunuyorum

  • Bu, sandbox-exec için bir wrapper betiği. Önceden iyi hazırlanmış çok sayıda preset olması güzel
    sandbox-exec işinin %90’ı doğru kapsamı belirlemek, kalan %90’ı da bunu anlamak
    Yine de overlay ya da copy-on-write yöntemiyle sandboxing yapılabilse iyi olurdu. Benim .bashrc dosyam yerine sadece geçici ortamın değişmesi yeterli

    • Bash seçmemin nedeni Go ya da Rust binary’lerine güvenmenin zor olması
      Overlay FS macOS’ta zor ama CWD dışını salt okunur kısıtlayıp geçici klasörde çalışmaya yönlendirerek çözdüm
    • Ben Amika adlı bir OSS geliştiriyorum. Yerel ve uzak sandbox’ları hızlıca ayağa kaldıran, Git ile iyi entegre olan bir araç
      TCP/UDP portlarını açabiliyor, ekip üyeleriyle paylaşım da mümkün. GitHub bağlantısı
    • Ben de Treebeard adında bir proje yaptım. sandbox-exec, worktree ve COW dosya sistemini birleştiren bir yapı
      git-ignored dosyalara güvenli şekilde erişebiliyor. Treebeard bağlantısı
    • Ama sandbox-exec zaten deprecated değil mi?

  • İlginç bir bilgi: sandbox-exec, macOS Sierra’dan (2016) beri resmî olarak deprecated durumda
    Buna rağmen hâlâ faydalı şekilde kullanılıyor. Apple’ın App Sandbox’ı bu tür kullanıcı tanımlı kurallara uygun değil
    Umarım Apple tamamen kaldırmaz

    • Aslında sanki doğduğu andan beri deprecated gibiydi. Profil dilinin belgelenmesi neredeyse yok; bilinenlerin çoğu tersine mühendislikle çıkarılmış durumda

  • Sandvault diye bir proje de var. sandbox-exec ile Unix kullanıcı sistemini birleştiren bir yaklaşım
    Her ajana ayrı, ayrıcalıksız bir kullanıcı hesabı veriyor; sudo, SSH ve paylaşımlı dizinlerle etkileşim sağlıyor
    Sandvault GitHub bağlantısı

  • Ben de macOS için GUI bir uygulama yaptım; sandbox-exec’i görsel olarak yönetebiliyorsunuz
    Alan adına göre ağ filtreleme ve gizli bilgi tespiti özellikleri de var
    multitui.com

  • Apple’ın container komutunu kullanarak Claude kodunu Apple container’ı içinde çalıştırma yöntemini paylaşıyorum
    container system start → container run → container exec sırasıyla ortam kuruluyor, ardından Node.js ve Claude yükleniyor

    • Teşekkürler! Homebrew’de de apple/container olduğunu ilk kez öğrendim

  • Ajanları yerelde çalıştırmanın neden daha iyi olduğunu düşündüğünü merak ediyorum.
    Çoğu insan için uzakta çalıştırma daha verimli gibi görünüyor — sürekli açık tutmak gerekmiyor

    • Yerelde çalıştırmanın avantajı kontrol ve sahiplik. Plex ya da web sunucusunu kendin çalıştırmayı tercih etmenin nedeniyle benzer
      Ayrıca abonelik ücretlerinden kaçınabiliyorsun
    • Ben de bu sorunu çözmek için pixels yaptım. TrueNAS SCALE ya da Incus üzerinde çalışabiliyor
      Güvenliği güçlendirme çalışmaları sürüyor ve AI iş akışları için yeterince uygun
      pixels GitHub bağlantısı

  • “clunker”, “clanker” için yeni bir argo mu diye merak ediyorum. Bir arkadaşımın arkadaşı Roku soruyor
    Şu an sandboxing sorunlarıyla uğraşıyorum, zamanlaması tam denk geldi

    • Yazım hatasıydı, az önce düzelttim