jai – Einfaches Containment-Tool für AI-Agenten

 (jai.scs.stanford.edu)
3 Punkte von GN⁺ 2026-03-29 | 1 Kommentare | Auf WhatsApp teilen
  • Ein leichtgewichtiges Tool, mit dem sich AI-Agenten unter Linux isoliert ausführen lassen und das ohne komplexe Container-Konfigurationen mit einem einzigen Befehl sichere Ausführungsgrenzen bereitstellt
  • Da sich Fälle häufen, in denen AI-Tools auf das reale Dateisystem zugreifen und Daten löschen oder beschädigen, rückt die Notwendigkeit sicherer Ausführungsumgebungen in den Vordergrund
  • Es schützt das Home-Verzeichnis mit einem Copy-on-Write-Overlay und trennt /tmp sowie /var/tmp, um Änderungen an Originaldateien zu verhindern
  • Es bietet drei Containment-Modi – Casual, Strict und Bare –, sodass Sicherheitsniveau und Zugriffsbereich wählbar sind
  • Ein Open-Source-Projekt des Stanford-Forschungsteams, das einen praktischen Schutzmechanismus für die sicherere Nutzung von AI-Tools bereitstellt

Leichtgewichtiges Tool jai zur Isolation von AI-Agenten

  • jai ist ein Tool, das entwickelt wurde, um AI-Agenten unter Linux einfach in Containment auszuführen
    • Es bietet mit einem einzigen Befehl sichere Ausführungsgrenzen, ohne komplexe Container- oder VM-Konfigurationen
    • Es lässt sich sofort in bestehende Workflows wie Coding-Assistance oder Skriptausführung integrieren

  • Reale Problemfälle

    • Mehrere Nutzer berichteten bei der Verwendung von AI-Tools über Dateiverluste und gelöschte Verzeichnisse
      • Nick Davidov berichtete, dass 15 Jahre Familienfotos durch einen Terminalbefehl gelöscht wurden
      • Claude Code von Anthropic löschte das Home-Verzeichnis, wodurch Entwicklungsprojekte verloren gingen
      • Bei Cursor wurde berichtet, dass der Working Tree geleert wurde und „alles verschwunden“ sei
      • Ein Reddit-Nutzer erwähnte, dass Antigravity das komplette D-Laufwerk gelöscht habe
      • Ein weiterer Cursor-Nutzer berichtete, dass 100 GB an Dateien gelöscht wurden
    • Diese Fälle zeigen die Sicherheitslücke, die entsteht, wenn AI-Tools Zugriff auf echte Benutzerkonten erhalten

  • Kernfunktionen von jai

    • Grenzen zwischen Ausführungskonto und Home-Verzeichnis werden automatisch eingerichtet
      • Das Arbeitsverzeichnis behält vollständige Lese-/Schreibrechte
      • Das Home-Verzeichnis wird durch ein Copy-on-Write-Overlay geschützt, sodass Originaldateien nicht verändert werden
      • /tmp und /var/tmp werden als unabhängige Bereiche getrennt, alle übrigen Dateien sind auf schreibgeschützten Zugriff beschränkt
    • Isolierte Ausführung ist möglich, indem man dem Befehl einfach jai voranstellt
      • Beispiel: jai codex, jai claude oder einfach jai zum Starten einer Shell
    • Ohne Dockerfile oder Image-Build-Prozess sofort nutzbar
      • Komplexe bwrap-Flags oder eigene Skripte sind nicht nötig

  • Wahl des Containment-Modus

    • Es stehen drei Modi zur Verfügung: Casual / Strict / Bare
      • Casual: schützt das Home-Verzeichnis per Copy-on-Write, Lesen der meisten Dateien möglich
      • Strict: läuft unter einem separaten jai-Benutzer und bietet starke Isolation mit leerem Home-Verzeichnis
      • Bare: leeres Home-Verzeichnis, aber Beibehaltung der Benutzer-UID
    • Die Modi unterscheiden sich in Vertraulichkeit (confidentiality), Integrität (integrity) und NFS-Unterstützung
      • Der Strict-Modus bietet die stärkste Isolation, unterstützt jedoch keine NFS-Homes

  • Vergleich mit alternativen Tools

    • Docker
      • Eignet sich für reproduzierbare, imagebasierte Umgebungen, ist für temporäres Sandboxing von Host-Tools jedoch schwergewichtig
      • Bietet keine Overlay-Funktion für das Home-Verzeichnis
    • bubblewrap
      • Ein leistungsfähiger Namespace-Sandboxer, bei dem die Dateisystemkonfiguration jedoch manuell angegeben werden muss
      • jai beseitigt diese Komplexität
    • chroot
      • Kein Sicherheits-Isolationsmechanismus; wegen fehlender Mount-, PID-Namespace- und Privilegientrennung auch unter Linux nicht für Sandboxing empfohlen

  • Sicherheitsgrenzen

    • jai garantiert keine vollständige Sicherheit
      • Als „casual sandbox“ verringert es den potenziellen Schaden, blockiert aber nicht alle Angriffe
      • Der Casual-Modus schützt Vertraulichkeit nur eingeschränkt, und auch der Strict-Modus entspricht nicht der Isolation von Containern oder VMs
      • In Multi-Tenant-Umgebungen oder Hochrisikoszenarien wird die Nutzung von Containern oder virtuellen Maschinen empfohlen

  • Projekthintergrund

    • Gemeinsam entwickelt von der Forschungsgruppe Stanford Secure Computer Systems (SCS) und der Future of Digital Currency Initiative (FDCI)
    • Wird als kostenlose Open-Source-Software bereitgestellt und soll Nutzern helfen, AI sicherer einzusetzen

Verwandte Beiträge

1 Kommentare

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

  • Man muss nur die folgende Einstellung zu .claude/settings.json hinzufügen

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

    Wenn man Zugriff auf externe Verzeichnisse erlauben will, muss man den Teil allowRead anpassen.
    Diese Funktion ist eine neue Sandbox-Option, die vor 10 Tagen hinzugefügt wurde.

    • Ich habe schon erlebt, dass Claude das aktuelle Verzeichnis verwechselt oder Befehle wie rm -rf * ausführt.
      Zum Glück ist das nicht gleichzeitig passiert, aber schon die Vorstellung ist unerquicklich.
      Die Sandbox-Idee ist gut, aber sie ist nur wirksam, wenn sie auf niedriger Ebene erzwungen wird.
      Claude selbst ist ein riesiges, von KI erzeugtes Programm, daher kann das Hinzufügen einer von Menschen geschriebenen Sicherheitsschicht mit weniger als 3000 Zeilen ein sinnvoller Schutz sein.
    • Zukünftige Versionen von claude-code könnten diesen Einstellungsnamen stillschweigend ändern oder entfernen.
      Deshalb bevorzugen manche vielleicht separate Sandboxing-Software.
    • Es wurde ein scherzhaftes Beispiel für eine Konfiguration geteilt, die GPU-Nutzung erlaubt, aber nur das Löschen von / verhindert.
      Es ist eine satirische Konfiguration, die den Zugriff auf /dev/nvidia* erlaubt und Datenabfluss bewusst in Kauf nimmt.
    • Es gibt bereits seit Jahrzehnten bewährte bestehende Sicherheitstools.
      Wenn man Claude als Benutzer mit eingeschränkten Rechten ausführt, wird die Isolation automatisch an Unterprozesse vererbt.
    • Unter Linux (Arch) und macOS (Tahoe) funktionierte die Sandbox-Funktion nicht richtig.
      Ein entsprechendes Issue ist offen.
      Bubblewrap und Seatbelt funktionieren für sich genommen gut, wirken aber deaktiviert, wenn sie über claude-code ausgeführt werden.

  • Es ist erstaunlich, dass Leute so leichtfertig AI-Agenten auf ihren persönlichen Computern installieren.
    Wir haben jahrzehntelang Systemsicherheit verteidigt, und plötzlich gibt man unvorhersehbarer Software praktisch alle Rechte.

    • Schon früher wurden Warnungen ignoriert, als Build-Tools automatisch Abhängigkeiten nachluden, und jetzt wiederholen sich Supply-Chain-Angriffe.
      Kurzfristige Bequemlichkeit hat Vorrang vor langfristiger Sicherheit.
    • Tatsächlich sind die Menschen, die solche Risiken eingehen, und die, denen Sicherheit wichtig ist, verschiedene Gruppen.
    • In Unternehmensumgebungen ist der Zugriff ohnehin bereits eingeschränkt, daher ist das vor allem auf privaten PCs ein sensibleres Thema.
      Auf meiner Remote-Entwicklungs-VM liegen nur Daten, die Claude ruhig sehen darf.
    • In den Anfangstagen von Docker war die Stimmung auch eher „Einfach das Image herunterladen!“.
      Aber die Branche hat die Sicherheitsrisiken bald erkannt und reagiert.

  • Eine einfache Unix-Rechtetrennung reicht ebenfalls aus.
    Man legt zwei Benutzerkonten an und fasst nur die Ordner, die man mit der KI teilen will, in einer Gruppe zusammen.
    Siehe diesen Blogbeitrag.

  • Auf der Startseite steht „Hört auf, blind zu vertrauen“, aber die Installationsmethode ist manuelles Bauen statt curl | bash.

    • Es ist viel sicherer, die tar-Datei selbst zu entpacken und mit makepkg -i zu installieren.
      Die PKGFILE ist mit rund 30 Zeilen kurz, und auch die Build-Funktion hat nur 7 Zeilen.
      Dagegen sind Skripte wie rustup (910 Zeilen), claude (158 Zeilen) oder opencode (460 Zeilen) deutlich komplexer.
    • Umgekehrt ist es keine vertrauenswürdige Methode, curl | tar | makepkg in einer einzigen Zeile zu verketten.

  • Dieses Projekt ist gut entworfen und wirkt etwas sicherer und bequemer als mein Ansatz.
    Ich isoliere Agenten über ein separates Benutzerkonto.
    Allerdings verhaken sich dabei manchmal die Berechtigungen, die ich dann per Skript korrigiere.
    Am sichersten ist am Ende immer noch, gleich ein separates Notebook bereitzustellen.
    Nichts ist sicherer als physisch getrennte Hardware.

    • Wenn es aber mit externen Diensten kommunizieren soll, muss man ihm API-Schlüssel geben, und diese könnten dann abfließen.
      Der Agent hat Fähigkeiten auf dem Niveau von Security-Penetrationstests, daher fühlt sich einfache Benutzertrennung allein nicht ausreichend an.
    • Ich selbst nutze aktuell ebenfalls den Ansatz mit getrennter Benutzerkennung.
      Wenn man Container verwendet, kommt der Agent durcheinander, sobald er selbst Container erstellen soll.

  • Die Website wirkt wegen ihres „vibe-coded“-Looks qualitativ fragwürdig, aber das eigentliche Tool wurde von einem Stanford-Professor persönlich implementiert.
    Siehe FAQ-Link.

    • Wenn ich als Autor selbst etwas dazu sagen darf: Ich bin kein Webdesigner, aber ein Betriebssystem-Experte.
      Ich habe den inhaltlichen Teil der Dokumentation sorgfältig korrigiert, dem kann man also vertrauen.
      Dass ich die von der KI erzeugte Website so belassen habe, ist auf gewisse Weise ironisch.
    • Der Autor ist David Mazieres, der seit den frühen 2000ern an Dateisystemen im Userspace forscht.
      Er leitet die Stanford Secure Computer Systems Group.
    • Jai ist ein Werkzeug mit hohem Risiko, aber die Website ist simpel, daher ist es dort in Ordnung, wenn sie vibe-coded ist.
    • Persönlich finde ich trotzdem eine schlichte HTML-Seite besser.

  • Es ist besorgniserregend, dass ein Agent bei Schreibzugriff auf das Projektverzeichnis persistente Exploits etablieren kann.
    Über Dateien wie .pyc, .venv oder .git/hooks kann Code außerhalb der Sandbox ausgeführt werden.
    Auch in diesem ChatGPT-Gespräch wurden solche Schwachstellen bestätigt.
    Daher ist der sicherste Weg ein git-patch-basierter Dateitransfer.
    Geänderte Dateien aus der Sandbox sollten nur dann nach außen übernommen werden, wenn es sich um in Git versionierte Inhalte handelt.

    • Es wäre gut, eine Option hinzuzufügen, die das Verzeichnis .git/ schreibgeschützt macht.
      Mit jai -D kann man das CWD als Overlay anlegen, aber das Zusammenführen der Änderungen ist kompliziert.
    • Ich führe Code grundsätzlich nur innerhalb der Sandbox auf VM-Ebene aus.
      Der Agent arbeitet in einem separaten Git-Worktree-Branch und wird erst nach einer Prüfung zusammengeführt.
      So bleibt ein reviewbasierter Sicherheitsablauf erhalten.
    • Man sollte Git-Hooks niemals erlauben.

  • Als einfache Alternative kann man den Agenten per SSH unter einem separaten Benutzerkonto ausführen.
    Das Projektverzeichnis wird per Bind-Mount eingebunden, um den Zugriff zu steuern.
    Das passt gut zur SSH-Remote-Funktion von VSCode.

    • Ich nutze seit 6 Monaten ebenfalls ein dediziertes Konto; man muss nur die zugänglichen Verzeichnisse verwalten.
      Das ist eine viel einfachere und effiziente Isolationsmethode als komplexe Sicherheitssysteme.

  • In der Praxis gibt es weit subtilere Probleme als nur rm -rf.
    claude-code hat einmal beim Speichern einer SVG den Ordner /public/blog/ angelegt und damit das Apache-Routing kaputtgemacht.
    Es war kein Lösch- oder Berechtigungsproblem, sondern ein unbeabsichtigtes Verhalten, das dazu führte, dass der Blog 404-Fehler ausgab.
    Jai dürfte solche groben Fehler verhindern, aber solche feinen Probleme bleiben weiterhin schwierig.

  • Großartiges Projekt, aber der Titel ist etwas unglücklich.
    Mir gefällt die Struktur, bei der das aktuelle Verzeichnis vollständig zugänglich ist, der Rest nur lesbar und das Home-Verzeichnis per Copy-on-Write behandelt wird.
    So ein Ansatz sollte das Standard-Sicherheitsmodell für AI-Agenten sein.

    • Da der Website ein Titel fehlt, würde etwas wie „jai - filesystem containment for AI agents“ besser passen.