Agent Safehouse – Lokales Agent-Sandboxing-Tool für macOS

 (agent-safehouse.dev)
16 Punkte von GN⁺ 2026-03-09 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Tool, das lokale KI-Agenten über die native macOS-Sandbox isoliert, damit sie nichts außerhalb des Systems verändern können
  • Alle Agenten laufen in einer unabhängigen Sandbox-Umgebung und können weder auf das Home-Verzeichnis des Nutzers noch auf andere Projekte zugreifen
  • Mit einem Deny-first-Zugriffsmodell sind Lese- und Schreibzugriffe nur auf ausdrücklich erlaubte Verzeichnisse möglich
  • Die Installation erfolgt über ein einzelnes Bash-Skript und kann ohne zusätzlichen Build oder Abhängigkeiten sofort ausgeführt werden
  • Über die LLM-basierte Profilerstellung lässt sich die Sandbox-exec-Konfiguration mit minimalen Rechten automatisieren

Überblick

  • Agent Safehouse ist ein Sandboxing-System speziell für macOS, das verhindert, dass lokal ausgeführte KI-Agenten Systemdateien beschädigen
    • “Go full --yolo. We've got you.” “Move fast, break nothing”
    • Blockiert das Risiko unerwarteter Befehlsausführung durch die probabilistische Natur von LLMs
  • Alle wichtigen Agenten funktionieren vollständig innerhalb der Sandbox, ohne Auswirkungen auf das externe System
  • Es verwendet ein Deny-first-Zugriffsmodell, bei dem standardmäßig jeder Zugriff blockiert und nur explizit freigegebene Pfade zugelassen werden
    • Beispiel: ~/my-project hat Lese-/Schreibzugriff, ~/.ssh, ~/.aws, ~/other-repos sind gesperrt

Installation und Ausführung

  • Die Installation erfolgt über den Download eines einzelnen Shell-Skripts
    • Das Skript wird per curl nach ~/.local/bin/safehouse geladen und anschließend ausführbar gemacht
  • Danach wird der gewünschte Agent über den Befehl safehouse gestartet
    • Beispiel: safehouse claude --dangerously-skip-permissions
  • Safehouse gewährt standardmäßig dem aktuellen Arbeitsverzeichnis (git root) Lese-/Schreibrechte und erlaubt dem Toolchain-Verzeichnis schreibgeschützten Zugriff

Beispiel zur Sandbox-Prüfung

  • Der Zugriff auf sensible Dateien wird auf Kernel-Ebene blockiert
    • Beim Ausführen von safehouse cat ~/.ssh/id_ed25519 erscheint der Fehler „Operation not permitted“
    • Andere Projektverzeichnisse (~/other-project) sind nicht sichtbar
    • Auf das aktuelle Projektverzeichnis kann normal zugegriffen werden

Automatisierung und Profilerstellung

  • Durch das Hinzufügen einer Shell-Funktion können alle Agenten standardmäßig innerhalb von Safehouse ausgeführt werden
    • Beispiel: Nach dem Definieren einer safe()-Funktion in .zshrc oder .bashrc werden die Befehle claude, codex, amp, gemini automatisch sandboxed ausgeführt
    • Für die Ausführung ohne Sandbox kann die Form command claude verwendet werden
  • Es gibt eine LLM-basierte Funktion zur Profilerstellung
    • Modelle wie Claude, Codex und Gemini analysieren das Safehouse-Template und erzeugen ein sandbox-exec-Profil mit minimalen Rechten
    • Es wird auf Basis des Home-Verzeichnisses und der Toolchain-Informationen unter ~/.config/sandbox-exec.profile gespeichert
    • Enthält Zugriffsrechte für das aktuelle Arbeitsverzeichnis und agentenspezifische Kurzbefehle

Sicherheitsaspekte und Bedeutung

  • Schützt davor, dass LLM-basierte lokale Agenten unbeabsichtigt Dateien löschen oder Systemänderungen vornehmen
  • Nutzt Zugriffssteuerung auf macOS-Kernel-Ebene und bietet dadurch eine standardmäßig sichere Ausführungsumgebung
  • Lässt sich dank des Einzel-Skript-Ansatzes leicht in bestehende Entwickler-Workflows integrieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-09
Hacker-News-Kommentare

  • Ich hätte nicht gedacht, dass mein Projekt so schnell öffentlich wird
    1️⃣ Ich bevorzuge lokal direkt ausgeführte Agenten. Nicht in Containern oder auf Remote-Servern, sondern auf meiner eigenen Maschine, die ich bis ins Detail abgestimmt habe – das gibt mir ein besseres Gefühl.
    2️⃣ Das hier ist im Grunde ein Policy-Generator für sandbox-exec. Keine Abhängigkeiten, keine Virtualisierung. Stattdessen habe ich viel Zeit darauf verwendet, die minimalen Berechtigungen zu finden, die jeder Agent für Auto-Updates, Keychain-Integration, Bilder einfügen usw. benötigt. Die zugehörigen Untersuchungen sind unter agent-safehouse.dev/docs/agent-investigations zusammengefasst.
    3️⃣ Man muss nicht einmal das ganze Projekt verwenden. Schon mit dem Policy Builder kann man sandbox-exec-Richtlinien erzeugen und in den Dotfiles verwenden.

    • Tut mir leid, dass ich es vorab öffentlich gemacht habe. Ich hatte es nach einem früheren Kommentar von dir ausprobiert, und es war so effizient, dass ich fand, es verdient einen eigenen Post.
      Ich hatte mir zwar schon vorher Sandbox-Policy-Dokumente angesehen, aber das war das erste Mal, dass ich so etwas als sofort nutzbare App gesehen habe.
      Ein paar unbequeme Punkte gab es allerdings — der Zugriff auf .gitconfig und .gitignore im Home-Verzeichnis ist eingeschränkt, und wegen der Prozesszugriffsbeschränkungen kann ich Claude keine Befehle wie lldb oder pkill ausführen lassen. Feingranulare Rechteverwaltung wäre schön.
    • Ich frage mich, ob sich das auf openclaw anwenden lässt. Es ist praktisch, wenn es in einer Form läuft, auf die der lokale Rechner zugreifen kann, aber gleichzeitig wird es dadurch auch schwieriger zu kontrollieren.
    • Mich würde interessieren, worin der praktische Unterschied zwischen lokaler Ausführung und Ausführung im Container besteht.
    • Oh, genau das hatte ich gesucht. Ich hatte versucht, microsandbox passend zu konfigurieren, aber das hier ist viel praxisnäher.
      Ich habe mir die Website und die Skripte kurz angesehen und nichts Auffälliges gefunden. Gibt es vielleicht irgendwelche nicht dokumentierten Fallstricke?
    • Ironischerweise interessiere ich mich für so ein Projekt, gerade weil ich KI nicht vertraue, aber um es zu installieren, soll ich dann eine .sh-Datei von irgendeinem Server herunterladen und ausführen – das ist schon etwas komisch.
      Eine Verteilung als Tarball wäre gut. In einen Tarball kann man direkt hineinschauen und auch prüfen, ob er automatisch in der CI erzeugt wurde, daher wäre er vertrauenswürdiger.

  • Ich freue mich, so ein Projekt zu sehen, und halte Sandboxing derzeit für die größte Herausforderung.
    Frühe Nutzer werden Agenten wohl einfach ohne viel Nachdenken lokal ausführen, aber langfristig oder in Unternehmensumgebungen funktioniert das auf keinen Fall.
    Es geht nicht nur um Netzwerk-, Datei- und Ausführungsrechte, sondern auch um komplexe Szenarien wie Browser-Tests oder das Erzeugen von Cloud-Ressourcen.
    Am Ende braucht es einen praktikablen Ansatz, der Sicherheit, Kosten und Rechtekontrolle integriert.

    • Aber könnte das vielleicht grundsätzlich ein unlösbares Problem sein? Funktionalität und Sicherheit stehen immer im Konflikt, und am Ende entscheiden sich die Leute meist für Ersteres.
    • Sandboxing auf Dateiebene ist die Grundlage, aber wirklich schwierig sind Credentials und Netzwerkkontrolle.
      Ich nutze einen lokalen Daemon, der kurzlebige JWTs ausstellt, damit Agenten nicht direkt mit Schlüsseln hantieren müssen. Für API-Zugriffe passt das gut, aber auf Dateisystemebene könnte man damit immer noch unendlich viele EC2-Instanzen hochziehen.

  • Das Problem ist, dass sich verschiedene Sandboxes nur schwer vergleichend bewerten lassen.
    Das hier wirkt wie ein Wrapper für sandbox-exec, und solche Wrapper gibt es inzwischen viele.
    Was wirklich fehlt, sind Dokumente zur Vertrauensprüfung und automatisierte Tests. Den meisten Sandboxes fehlt es an guter Dokumentation.
    Um ihnen zu vertrauen, braucht man detaillierte Unterlagen und Belege, dass sie tatsächlich funktionieren.

    • Deshalb habe ich es in Bash umgesetzt — um undurchsichtige Binärdateien zu vermeiden.
      Die sandbox-exec-Profile für die einzelnen Agenten sind im GitHub-Profilordner getrennt abgelegt und lassen sich leicht prüfen.
      Ich führe auch E2E-Tests mit echten Agenten durch.
      Selbst ohne den Safehouse-Wrapper kann man mit dem Policy Builder direkt Minimal-Privilege-Richtlinien erstellen.
      Außerdem gibt es eine Anleitungsdatei, mit der ein LLM Sandbox-Profile verfassen kann.

  • Das ist ein Wrapper-Skript für sandbox-exec. Schön ist, dass es viele gut vorbereitete Presets gibt.
    90 % von sandbox-exec bestehen darin, den richtigen Geltungsbereich festzulegen, und die anderen 90 % darin, das zu verstehen.
    Trotzdem wäre es gut, wenn sich Sandboxing auch per Overlay- oder Copy-on-Write-Ansatz umsetzen ließe. Es würde reichen, wenn nur eine temporäre Umgebung statt meiner .bashrc geändert würde.

    • Der Grund für Bash war, dass Go- oder Rust-Binaries schwer zu vertrauen sind.
      Overlay-FS ist auf macOS schwierig, aber ich habe es dadurch gelöst, dass ich Lesezugriffe außerhalb des CWD auf read-only beschränke und die Arbeit in temporären Ordnern lenke.
    • Ich entwickle ein OSS namens Amika. Es ist ein Tool, das lokale und Remote-Sandboxes schnell startet und gut mit Git zusammenarbeitet.
      TCP/UDP-Ports lassen sich freigeben, und man kann sie auch mit Teammitgliedern teilen. Siehe GitHub-Link.
    • Ich habe ein Projekt namens Treebeard gebaut. Es kombiniert sandbox-exec, Worktree und ein COW-Dateisystem.
      Damit kann man sicher auf von Git ignorierte Dateien zugreifen. Treebeard-Link
    • Aber ist sandbox-exec nicht schon deprecated?

  • Interessante Tatsache: sandbox-exec ist seit macOS Sierra (2016) offiziell deprecated.
    Trotzdem wird es immer noch nützlich eingesetzt. Apples App Sandbox passt nicht zu solchen benutzerdefinierten Regeln.
    Hoffentlich schafft Apple es nicht komplett ab.

    • Ehrlich gesagt wirkte es von Anfang an wie deprecated. Die Dokumentation der Profilsprache ist fast nicht vorhanden, und das meiste wurde per Reverse Engineering herausgefunden.

  • Es gibt auch ein Projekt namens Sandvault. Es kombiniert sandbox-exec mit dem Unix-Benutzersystem.
    Jedem Agenten wird ein eigenes nicht privilegiertes Benutzerkonto gegeben, und die Interaktion läuft über sudo, SSH und gemeinsame Verzeichnisse.
    Sandvault GitHub-Link

  • Ich habe eine GUI-App für macOS erstellt, mit der sich sandbox-exec visuell verwalten lässt.
    Enthalten sind auch domänenbasiertes Netzwerk-Filtering und Secret-Erkennung.
    multitui.com

  • Jemand teilt, wie man Claude Code mit Apples container-Befehl innerhalb eines Apple-Containers ausführt.
    Die Umgebung wird in der Reihenfolge container system start → container run → container exec eingerichtet, danach werden Node.js und Claude installiert.

    • Danke! Ich wusste gar nicht, dass es apple/container auch in Homebrew gibt.

  • Mich würde interessieren, warum lokale Agenten als besser angesehen werden.
    Für die meisten Menschen scheint Remote-Ausführung effizienter zu sein — man muss sie schließlich nicht ständig eingeschaltet lassen.

    • Der Vorteil lokaler Ausführung ist Kontrolle und Eigentümerschaft. Das ist ähnlich wie bei Leuten, die Plex oder einen Webserver selbst betreiben.
      Außerdem kann man sich Abo-Gebühren sparen.
    • Um dieses Problem zu lösen, habe ich pixels gebaut. Es kann auf TrueNAS SCALE oder Incus laufen.
      Die Sicherheit wird gerade weiter verbessert, aber für KI-Workflows ist es bereits gut geeignet.
      pixels GitHub-Link

  • Ich frage mich, ob „clunker“ ein neuer Slang für „clanker“ ist. Ein Roku über drei Ecken wollte das wissen.
    Ich kämpfe gerade selbst mit dem Sandboxing-Problem, daher ist das Timing perfekt.

    • War ein Tippfehler, ich habe ihn gerade korrigiert.