Agent Safehouse: macOS-Sandbox für Coding-Agents mit Deny-First-Policy

Welches Problem Agent Safehouse adressiert

Ein Coding-Agent läuft typischerweise mit den Rechten des angemeldeten Benutzers. Er liest Projektdateien, führt Shell-Kommandos aus und darf dabei auf alles zugreifen, was das Konto hergibt: SSH-Schlüssel, Cloud-Credentials, Browser-Profile, andere Repositories. Das README von Agent Safehouse beschreibt genau diese Ausgangslage und setzt dagegen ein Deny-First-Modell: zuerst wird alles verboten, dann werden einzelne Pfade und Integrationen freigegeben. Zielgruppe sind Entwickler auf macOS, die Claude Code, Codex, Amp oder ähnliche Agents starten und deren Dateisystemzugriff auf das Nötige begrenzen wollen, ohne den Arbeitsablauf zu zerstören. Das Projekt positioniert sich selbst als Härtungsschicht und ausdrücklich nicht als perfekte Sicherheitsgrenze gegen einen entschlossenen Angreifer. Diese Selbsteinschätzung ist wichtig, denn sie bestimmt, wofür das Werkzeug taugt und wofür nicht.

sandbox-exec, Profile und die Reihenfolge der Regeln

Unter der Haube nutzt Agent Safehouse das macOS-Werkzeug sandbox-exec mit komponierbaren Policy-Profilen. Die Profile liegen im Scheme-Format vor und werden zur Laufzeit zu einer Gesamtpolicy gerendert. Zwei Variablen steuern dabei die Konkretisierung: HOME_DIR erzeugt home-relative Regeln, WORK_DIR bindet das gewählte Arbeitsverzeichnis über die Helfer workdir-literal, workdir-subpath und workdir-prefix ein. Relative Argumente beginnen mit einem Schrägstrich, sodass eine wiederverwendbare Regel auf Dateien wie <workdir>/.env zeigen kann, ohne einen absoluten Projektpfad fest zu verdrahten. Die Reihenfolge ist relevant: angehängte Profile laden zuletzt, ihre Deny-Regeln können also frühere Standardfreigaben wieder einengen. Zusätzlich löst Safehouse zur Renderzeit absolute Pfade in eingebauten allow file-read*-Regeln auf und erzeugt passende Grants für das reale Ziel, wenn der geschriebene Pfad ein Symlink ist. Das hält Systemdateien wie /private/etc/localtime funktionsfähig, ohne die Quellprofile auf rekursiven Zugriff nach /private/etc auszuweiten. Die Dokumentation begrenzt diesen Mechanismus ausdrücklich auf eingebaute absolute literal- und subpath-Lesegrants; schreibende oder rein metadatenbezogene Regeln werden derzeit nicht automatisch erweitert.

Was die Standardkonfiguration tatsächlich freigibt

Das README ist an dieser Stelle präzise und ungewöhnlich ehrlich. HOME_DIR allein gewährt keinen rekursiven Lesezugriff auf das Home-Verzeichnis. Erlaubt sind standardmäßig nur Metadaten-Traversal auf /, auf den Pfad zu $HOME und auf $HOME selbst, damit Runtimes explizit erlaubte home-bezogene Pfade prüfen können. Dazu kommen Verzeichniswurzel-Leserechte für ~/.config und ~/.cache, damit Werkzeuge XDG-Speicherorte finden, sowie einige explizite Dateien und Ordner aus immer aktiven Profilen, etwa Git- und SSH-Metadaten und gemeinsame Agent-Instruktionsordner. Die praktische Konsequenz beschreibt das README selbst: stat "$HOME" kann gelingen, während ls "$HOME" und cat ~/secret.txt weiterhin scheitern, solange keine spezifischere Regel den Pfad freigibt. Wer diese Standardausnahmen nicht will, muss sie über --append-profile zurücknehmen. Das ist ein bewusster Kompromiss zwischen Nutzbarkeit und Enge, und er ist nicht kostenlos: Die Angriffsfläche umfasst weiterhin die freigegebenen Metadatenpfade.

Installation und der Aufruf im Alltag

Die Installation läuft entweder über Homebrew mit brew install eugene1g/safehouse/agent-safehouse oder über ein Standalone-Skript, das nach ~/.local/bin/safehouse geladen und ausführbar gemacht wird. Für den täglichen Gebrauch zeigt das README ein Muster, das Maschinen-spezifische Pfade aus der Projektkonfiguration heraushält. In der Shell-Konfiguration wird SAFEHOUSE_APPEND_PROFILE auf eine lokale Datei wie $HOME/.config/agent-safehouse/local-overrides.sb gesetzt, und eine Funktion safe ruft safehouse mit --add-dirs-ro und --append-profile auf. Darauf aufbauend lässt sich safe-claude definieren, das claude --dangerously-skip-permissions startet. Die Beispiel-Policy in local-overrides.sb enthält sowohl Freigaben, etwa home-literal "/.gitignore_global" oder subpath "/Volumes/Shared/Engineering", als auch eine Verengung: (deny file-read* file-write* (workdir-literal "/.env")). Das Muster ist klar: --add-dirs-ro und --add-dirs für normale Freigaben, --append-profile für lokale Ausnahmen und endgültige Übersteuerungen. Für fish existiert eine parallele Variante mit set -gx und $argv.

Git-Worktrees: automatische Erkennung mit einem blinden Fleck

Wird als Arbeitsverzeichnis ein Git-Worktree-Root gewählt, erkennt Safehouse das beim Start. Der Worktree erhält dann Zugriff auf die gemeinsamen Git-Metadaten, auch wenn das common dir außerhalb des gewählten Verzeichnisses liegt, und die übrigen verknüpften Worktrees desselben Repositories werden lesbar. Das ist bequem für Inspektionen über Baumgrenzen hinweg. Die Einschränkung steht direkt daneben: Dieser Schnappschuss aktualisiert sich nicht für bereits laufende Prozesse. Wer Worktrees unter einem stabilen Elternverzeichnis wie ~/worktrees anlegt, soll dieses Root besser explizit mit --add-dirs-ro hinzufügen. Das ist ein Fall, in dem die Automatik genau dann nicht greift, wenn sie am nützlichsten wäre, nämlich bei Agents, die während ihrer Laufzeit neue Worktrees erzeugen. Wer diesen Arbeitsstil pflegt, sollte die Automatik nicht als verlässlich einplanen.

Grenzen und Fälle, in denen das Werkzeug die falsche Wahl ist

Die erste Grenze nennt das Projekt selbst: eine Härtungsschicht, kein perfekter Schutz gegen einen entschlossenen Angreifer. Wer eine belastbare Isolation für nicht vertrauenswürdigen Code sucht, braucht eine andere Ebene, etwa eine VM oder einen Container. Die zweite Grenze ist die Plattformbindung. Safehouse ist auf macOS zugeschnitten und nutzt sandbox-exec. Auf Linux läuft es nicht, und das README verweist für diesen Fall auf eigene Alternativen. Die dritte Grenze betrifft die Policy-Pflege. Die Symlink-Auflösung zur Renderzeit gilt nur für eingebaute absolute literal- und subpath-Lesegrants. Eigene Pfadfreigaben werden separat normalisiert, und schreibende oder metadatenbezogene eingebaute Regeln werden heute nicht automatisch erweitert. Wer also eigene Profile schreibt, muss mit uneinheitlichem Verhalten zwischen eingebauten und eigenen Regeln rechnen. Viertens ist die Dokumentation auf der Website gebündelt; das README selbst verweist für Setup, Optionen, Architektur, Tests und Debugging auf die VitePress-Dokumentation. Ohne diese Seite bleiben viele Details offen.

Linux-Alternativen und der Unterschied im Ansatz

Das README listet für Linux mehrere Projekte mit deutlich anderer Mechanik. bubblewrap nutzt unprivilegierte User-Namespaces und ist damit ein generisches Sandbox-Werkzeug, das man selbst zusammensetzt. firejail ist ein etabliertes SUID-Programm mit fertigen Profilen für gängige Anwendungen. vetto arbeitet laut Beschreibung als Zero-Daemon-Kernel-Sandbox mit Landlock LSM und seccomp-bpf auf Linux sowie Seatbelt auf macOS und richtet PATH-Shims über vetto enable <agent> ein. nono.sh kombiniert Landlock mit seccomp-notify und erlaubt Rechteerhöhung ohne Neustart. sandlock ist ein reines Python-Projekt, das Landlock, seccomp-bpf und seccomp-User-Notification verbindet und ohne Root, Container oder C-Compiler auskommt. Der konzeptionelle Unterschied zu Agent Safehouse liegt weniger im Ziel als im Hebel: Die Linux-Varianten setzen auf Kernel-Features wie Landlock und seccomp, Safehouse auf das macOS-eigene sandbox-exec mit einer Scheme-Policy. Wer plattformübergreifend ein einheitliches Modell braucht, wird mit keinem der beiden Wege vollständig glücklich.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Das Projekt steht unter Apache-2.0, einer permissiven Lizenz mit ausdrücklicher Patentgewährung. Für den üblichen Einsatz in einem Entwicklerteam entstehen daraus keine Copyleft-Pflichten; wer die Software weiterverbreitet oder modifiziert, sollte die Lizenzbedingungen im Detail selbst prüfen, denn dieser Text ist keine Rechtsberatung. Die Release-Historie zeigt ein gepflegtes Projekt: v0.12.0 datiert auf September 2026, davor v0.11.1 im Juli und v0.11.0 im selben Monat. Die Versionsnummern im 0.x-Bereich sagen nichts über Stabilität im Sinne einer API-Garantie aus; Änderungen an Profilformaten oder Optionen sind in diesem Bereich zu erwarten. Der Upgrade-Aufwand hängt davon ab, wie viel eigene Policy im Spiel ist. Wer nur --add-dirs-ro nutzt, hat wenig anzupassen. Wer lokale .sb-Dateien mit eigenen Regeln pflegt, muss bei jedem Sprung prüfen, ob sich eingebaute Pfade, Standardausnahmen oder die Symlink-Auflösung geändert haben. Konkret heißt das: profiles/ im Repository mit der eigenen local-overrides.sb abgleichen und die gerenderte Policy für das eigene Workdir ansehen, bevor der Agent mit --dangerously-skip-permissions startet.

Redaktionelles Fazit

Wer auf macOS Coding-Agents wie Claude Code mit möglichst wenig Dateisystemrechten laufen lassen will und Scheme-Profile akzeptiert, findet hier ein schlankes Werkzeug mit Homebrew-Installation und dokumentierter Policy-Struktur. Wer eine belastbare Sicherheitsgrenze gegen gezielte Angriffe braucht oder auf Linux arbeitet, sollte nicht zu diesem Projekt greifen. Vor dem Einsatz lohnt sich ein Blick in profiles/ und die gerenderten Regeln für das eigene Workdir, denn die Standardausnahmen für ~/.config, ~/.cache und Git-Metadaten sind bewusst gesetzt und lassen sich nur über --append-profile zurücknehmen.

Offizielle Quellen

1. eugene1g/agent-safehouse on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases