KI mit Sicherheitsgurt

Deine Apps sehen nur dein Projekt

BX startet Apps, die du längst hast - Claude, Claude Code, Cursor, VS Code, dein Terminal - in einer Sandbox, die macOS selbst mitbringt. Du sagst, in welchem Ordner die App arbeiten soll. Alles andere in deinem Benutzerordner ist für sie nicht gesperrt, sondern schlicht nicht da: Zugangsdaten, SSH-Schlüssel, Shell-Verlauf, Mail, Nachrichten, Passwortmanager.

Keine virtuelle Maschine, kein Container, keine Änderung an der App. Dieselben Apps, dieselben Ordner, derselbe Ablauf - nur das Sichtfeld ist kleiner.

Einmal einrichten, dann ein Klick

Drei Fragen, und der Launcher steht: Welche App? Welcher Ordner? Wie soll er heißen. Danach startest du ihn aus dem BX-Fenster, aus der Menüleiste, mit einem Icon im Dock oder indem du seinen Namen ins Terminal tippst.

Die App startet dabei so, wie du sie kennst. BX findet, wo sie ihre eigenen Einstellungen ablegt, und gibt ihr genau die zurück: kein Editor, der sich wie frisch installiert benimmt, keine verlorenen Anmeldungen, keine neu einzurichtenden Erweiterungen.

Wenn du Claude und andere KI-Werkzeuge nutzt

Du musst nicht programmieren, damit dich das betrifft. Eine KI-App, die Dateien lesen kann, liest sie mit deinen Rechten - und alles, was sie startet, ebenfalls. Ein einziges “schau doch mal in meinen Ordner” reicht, damit auch deine Steuerunterlagen, dein Mail-Archiv und deine Passwortdatenbank in Reichweite liegen.

Gib ihr stattdessen einen Launcher. Sie bekommt den Ordner, den du gemeint hast, und nichts darüber hinaus.

Zwei Dinge, die du wissen solltest:

• Beende die App zuerst. Läuft sie bereits ungeschützt, öffnet der Start des Launchers nur ein Fenster im bestehenden Prozess - still und ohne Sandbox. Die Menüleiste von BX weist dich darauf hin.
• Der Wert steckt oft in den Erweiterungen, nicht in der App. Ein MCP-Server, gestartet als npx irgendein-mcp-server, ist Code von Fremden, der als Kindprozess mit deinen vollen Rechten läuft. Genau darum liegt die Sandbox herum.

Die Werkzeuge passen auf, was geschrieben wird. BX passt auf, was gelesen wird.

Der naheliegende Aufhänger - “KI-Agenten sind unsicher” - ist der falsche. Der zutreffende ist enger und leichter zu überprüfen: Die Sandboxen, die diese Werkzeuge mitbringen, decken die Leseseite kaum ab.

Claude Code bringt auf macOS eine Sandbox mit, Codex CLI, Gemini CLI und Cursor ebenso. Der Schwerpunkt liegt dort aber auf Schreibzugriffen außerhalb des Arbeitsverzeichnisses und auf ausgehendem Netzwerkverkehr. ~/.ssh, ~/.aws, ~/.zsh_history, Mail- und Passwortmanager-Container bleiben die ganze Zeit lesbar.

Und jede dieser Sandboxen deckt nur ihr eigenes Werkzeug ab. Die Editor-Erweiterung, ein MCP-Server, ein Terminal, das ein Agent im Editor aufmacht - alles außerhalb davon. BX sitzt eine Ebene tiefer und interessiert sich nicht dafür, was darin läuft.

Sehen statt raten

Das ist der Teil, den ein Skript nicht hat.

Vorher: Die Schutzansicht zeigt als Baum, was die Sitzung lesen, was sie schreiben und was sie gar nicht sehen darf. Per Rechtsklick änderst du das für diesen einen Launcher oder für alle.

Hinterher: BX zeichnet auf, woran eine Sitzung abgewiesen wurde, und markiert es an genau der Stelle im Baum. Verhält sich ein Werkzeug seltsam, steht dort, was ihm gefehlt hat - und ein Klick gibt es frei. Bei heiklen Orten wie ~/.ssh fragt BX vorher nach.

Damit wird aus “das Werkzeug tut nichts und ich weiß nicht warum” eine Liste mit einem Knopf daneben. Für die gängigen Programme ist das ohnehin schon erledigt: VS Code und seine Varianten, JetBrains-IDEs, Claude Desktop, ChatGPT, Xcode und rund ein Dutzend Kommandozeilen-Agenten bringen mit, was sie zum Laufen brauchen.

Nicht nur KI

Alles, was du startest, liest mit deinen Rechten, ob Agent oder nicht:

• Paketinstallationen und Builds - pnpm install, pip install, cargo build, make, Gradle. Postinstall-Skripte sind der meistgenutzte Weg über Abhängigkeiten überhaupt, und das passiert täglich.
• Mac-eigene Toolchains, die sich nicht containerisieren lassen - Swift, Code Signing, Fastlane. Dafür gibt es kein Docker, und genau dort liegen App-Store-Connect-Schlüssel und Signaturen.
• Mandantentrennung in der Auftragsarbeit - das Material von Kunde A bleibt unerreichbar, während du für Kunde B arbeitest. Ein vertragliches Argument, kein angstbasiertes.
• Fremde Repositories - von GitHub klonen und reinschauen. .vscode/tasks.json, .envrc, Git-Hooks und das Makefile laufen alle, bevor du eine Zeile gelesen hast.

In eine Sandbox stecken lässt sich jede App, die macOS nicht ohnehin einschränkt. Für die meisten lohnt der Aufwand nicht - für die, die fremden Code ausführen, schon.

Was du bekommst

• Launcher. App, Ordner und Regeln an einem Ort. Start aus dem Fenster, aus der Menüleiste, aus dem Dock oder als getipptes Wort im Terminal.
• Eine Policy, die du vorher lesen kannst. Der Baum listet jeden Ordner auf, den die Sitzung lesen und schreiben darf. Kein Raten.
• Die Liste der abgewiesenen Zugriffe an der Stelle, an der sie passiert sind - mit einem Klick zum Freigeben.
• Regeln als lesbare Textdateien. .bxignore, in gitignore-Syntax, kommentierbar und versionierbar - global, pro Launcher oder pro Projektbaum.
• Eine Menüleiste, die sagt, worin du gerade arbeitest. Geschützt durch BX, durch eine eigene Sandbox, oder gar nicht - und eine Warnung, wenn ein Werkzeug ungeschützt läuft, obwohl es einen Launcher dafür gibt.
• Dieselbe Engine auf der Kommandozeile. bx run, bx dry, bx list - und jeder Launcher unter seinem kurzen Namen.

Gängige Apps werden automatisch erkannt, inklusive der Electron-Eigenheiten, die sie sonst am Start hindern würden. Angeboten wird nur, was auf deinem Mac wirklich installiert ist.

Wo der Schutz endet

BX ist ein Lesefilter für das Dateisystem. Eine Sitzung darf weiterhin alles ausführen und ins Netz - sie sieht nur weniger.

Ausbrüche aus einer Seatbelt-Sandbox sind dokumentiert, und was ein Prozess lesen kann, kann er auch senden. Damit ist das realistische Problem abgedeckt: nicht der gezielte Angreifer, sondern ein Werkzeug, das mehr liest als nötig und es irgendwohin weitergibt. Bewusst bösartige Software auszuführen, ist nicht der Zweck von BX.

Ebenfalls nichts zu holen gibt es bei Apps, die schon Apples eigene Sandbox mitbringen - eine zweite können sie nicht annehmen. BX bietet sie deshalb gar nicht erst zur Auswahl an.

Testen, dann kaufen

BX läuft drei Tage unverändert. Danach schützt es genau weiter wie vorher: jeder Launcher behält seine Sandbox, jede Regel gilt weiter, es sagt nur einmal pro Sitzung, dass es bezahlt werden möchte. Der Schutz liegt nie hinter der Bezahlschranke - was mit dem Kauf dazukommt, ist mit einem kleinen Einkaufswagen gekennzeichnet und erspart Klicks, keine Angriffsfläche.

Einmalkauf, kein Abo. Vorausgesetzt wird macOS 14 oder neuer.