Hazmat isoliert Coding-Agenten im eigenen Nutzerkonto

Ein Coding-Agent, der aus dem eigenen Terminal startet, erbt im Zweifel alles: SSH-Schlüssel, Cloud-Zugangsdaten und die über Jahre gewachsene Konfiguration im Home-Verzeichnis. Gleichzeitig muss er im Projekt schreiben dürfen, sonst ist er kaum nützlich. Genau hier setzt Hazmat an. Das Werkzeug beseitigt den Widerspruch nicht, sondern zieht eine engere Grenze um den Agentenlauf.

Ein eigenes Nutzerkonto als Sicherheitsgrenze

Hazmat führt Coding-Agenten in einem separaten Nutzerkonto auf demselben Rechner aus. Der Agent erhält ein eigenes Home-Verzeichnis; freigegeben wird das Projektverzeichnis, an dem er arbeiten soll. Auf macOS sichert Hazmat das Projekt vor dem Lauf, erzeugt eine Policy für die Sitzung, wechselt in das Agentenkonto und startet anschließend den gewünschten Harness.

Die Reihenfolge ist wichtiger als das Etikett „Sandbox“: Erst entsteht der Rückweg, dann bekommt der Agent seine Rechte. Snapshots sollen Änderungen nach dem Lauf sichtbar und bei Bedarf rückgängig machen.

Das begrenzt vor allem Dateischäden. Es verhindert jedoch nicht jede schädliche Aktion. Liegt ein API-Schlüssel im freigegebenen Projektverzeichnis und kann der Agent ihn über das Netzwerk übertragen, hilft auch ein sauberer Rollback nicht. Die Datei lässt sich wiederherstellen; das Geheimnis bleibt kompromittiert.

Der Sitzungsvertrag macht Rechte sichtbar

Vor dem Start zeigt Hazmat einen lesbaren Sitzungsvertrag mit Projektzugriff, Integrationen, Netzwerkmodus und Servicezugriff. Das ist mehr als Bedienoberfläche. Wer mehrere Coding-Agenten verwendet, muss erkennen können, welches Werkzeug gerade mit welchen Rechten läuft. Unklare Berechtigungen sind sonst genau die Art von Betriebszustand, in der ein Vorfall lange unbemerkt bleibt.

Hazmat unterstützt laut Projektangaben unter anderem Claude, Codex, OpenCode, Antigravity, Hermes, Qwen, Cursor Agent und Pi sowie einfache Shell-Schleifen. Für Plattform- und Betriebsteams liegt darin der praktische Vorteil: Die Berechtigungsgrenze hängt an der Sitzung und muss nicht für jeden neuen Harness vollständig neu entworfen werden.

Vor einem echten Einsatz würde ich diese Grenze trotzdem mit einem Wegwerfprojekt prüfen: Kann der Agent eine Datei außerhalb des freigegebenen Verzeichnisses lesen? Ist der angezeigte Netzwerkmodus tatsächlich der erwartete? Entsteht vor dem Lauf ein Snapshot, und lässt sich eine absichtlich veränderte Datei zuverlässig zurücksetzen? Erst diese Probe zeigt, ob Policy und Rückweg in der eigenen Umgebung tragen.

Formale Spezifikation ist kein Sicherheitsstempel

Zum Projekt gehört eine Spezifikation in TLA+. Damit sind die beabsichtigten Zustandsübergänge einer Isolationssitzung maschinell prüfbar formuliert, statt nur in Prosa beschrieben zu werden.

Die Go-Implementierung bleibt davon getrennt und kann Fehler enthalten. Eine geprüfte Spezifikation belegt nicht automatisch, dass der ausgeführte Code sie korrekt umsetzt.

Diese Abgrenzung ist eine Stärke. Hazmat liefert eine präzise Sicherheitsabsicht, aber keine verifizierte Implementierung. Das Werkzeug ist deshalb eine zusätzliche Schutzschicht und kein Ersatz für Secret-Management, minimale Netzwerkrechte, Code-Review oder getrennte Entwicklungszugänge.

Für den Alltag reichen drei Regeln: Zugangsdaten gehören nicht in das geteilte Projektverzeichnis. Der Sitzungsvertrag muss vor jedem Lauf geprüft werden. Und ein Snapshot schützt nur vor reversiblen Änderungen. Hazmat zieht damit eine nachvollziehbare Grenze um den Agentenlauf und schafft einen Rückweg für Dateischäden. Alles, was diese Grenze verlässt, muss weiterhin an anderer Stelle abgesichert werden.