Workban

Guardrails für Coding-Agenten

Dein Agent darf viel. Nicht alles.

Workban Guard läuft in Claude Code und Codex CLI und prüft jeden Befehl, bevor er ausgeführt wird. rm -rf ~, ein Force-Push auf main oder supabase db reset erreichen dein System nicht, auch nicht versteckt in einem Heredoc oder einem Package-Script. Nach jedem Edit prüft es die neuen Zeilen. Fertig ist der Agent erst, wenn Typecheck, Lint und Tests grün sind.

Protokollwbg check

  • deny: rm -rf ~. würde dein Home-Verzeichnis löschen (fs.rm-catastrophic)
  • deny: git push --force origin main. überschreibt fremde Commits auf main (git.force-push)
  • deny: cat .env. brächte Secrets in den Verlauf und zum Modell-Anbieter (secrets.read-env)
  • deny: npm install reqeusts. das Paket gibt es nicht, ein typischer erfundener Name (deps.not-found)
  • ask: git reset --hard. verwirft nicht committete Änderungen (git.discard-changes)
  • ask: pnpm db:reset. das Script führt supabase db reset aus (db.destructive)

Echte Entscheidungen von wbg check

  • Version 0.3.0
  • 39 Regeln
  • 33 Detektoren
  • Läuft lokal

Gefährliches wird gestoppt, bevor es läuft.

Workban Guard zerlegt jeden Shell-Befehl, statt im Text nach Mustern zu suchen. Es steigt in $(…), Heredocs, bash -c, Package-Scripts und make-Targets ab. Was ein Agent nie tun sollte, wird verweigert (deny). Was selten, aber legitim ist, braucht deine Bestätigung (ask).

Dateisystem
rm -rf auf Home, Projekt oder .git. Löschen außerhalb des Projekts nur nach Rückfrage.
Git
Force-Push und Push auf main, --no-verify, reset --hard, Secrets in Commits.
Datenbank
supabase db reset, DROP, TRUNCATE, DELETE ohne WHERE, gelöschte Docker-Volumes.
Secrets
.env und Schlüssel lesen, Secret-Literale in Dateien schreiben, Tokens ausgeben.
Pakete
Erfundene Pakete, Typosquats, brandneue und kaum genutzte Pakete, geprüft gegen npm und PyPI.
Deploys
vercel --prod, supabase db push, terraform apply oder npm publish nur nach Rückfrage.
Selbstschutz
Der Agent kann Workban Guard weder abschalten noch seine Config ändern.
Alle RegelnJede Regel und jeder Detektor, mit dem, was Workban Guard jeweils tut.

Auch was der Agent liest, wird geprüft.

Eine Datei, eine Webseite oder die Antwort eines MCP-Servers kann Anweisungen enthalten, die nicht von dir stammen. Workban Guard sucht lokal und ohne Modell mit 7 Regeln danach und warnt den Agenten und dich. Sperren kann es hier nichts, denn gelesen ist der Text schon. Die Warnung sagt dem Agenten, ihn als Daten zu behandeln, nicht als Auftrag.

  • Aufforderungen, frühere Anweisungen zu ignorieren
  • Text, der dem Agenten eine neue Rolle gibt
  • Befehle, die Secrets nach außen senden
  • Text in unsichtbaren Zeichen

Geprüft wird nur, was neu ist.

33 Detektoren laufen auf den Zeilen, die der Agent gerade geschrieben hat. Findet einer einen Fehler, meldet Workban Guard ihn sofort zurück, und der Agent behebt ihn, bevor er weitermacht.

  • any, @ts-ignore und abgeschaltete Lint-Regeln
  • leere catch-Blöcke und Platzhalter statt Code
  • SQL und Shell-Befehle aus zusammengesetzten Strings
  • Secrets im Code, abgeschaltete TLS-Prüfung, MD5 für Passwörter
  • Tabellen ohne Row Level Security, Service-Role-Key im Client
  • echte E-Mail-Adressen, IBANs und Kartennummern in Testdaten
  • .only in Tests und Assertions, die immer bestehen

Fertig heißt: Typecheck, Lint und Tests sind grün.

Will der Agent aufhören, laufen die Prüfungen des Projekts über die Dateien, die er in dieser Session geändert hat. Ist etwas rot, arbeitet er weiter. Nach zwei Runden lässt das Gate los und sagt dir, was offen ist, statt endlos zu kreisen.

Checks
typecheck, lint und test aus der package.json oder eigene aus der Config. Tests nur für die betroffenen Dateien.
Befunde
Fehler aus den Prüfungen nach jedem Edit, die noch im Code stehen.
Hinweise
Code ohne Test- oder Doku-Änderung. Standard ist ein Hinweis, auf Wunsch blockiert er.
Grenze
Höchstens zwei erzwungene Runden pro Aufgabe.

Cold Review: ohne Gesprächskontext.

/wbg:review startet unabhängige Reviewer als eigene Prozesse. Sie sehen nur Diff und Code, nicht euer Gespräch. Fünf Rollen prüfen Sicherheit, Tests, Schlamperei, Architektur und eure eigenen Regeln. Jedes Finding wird in einer Wegwerf-Kopie nachgeprüft und gilt erst als bestätigt, wenn es sich reproduzieren lässt.

  • Geprüft wird mit dem Agenten, in dem du arbeitest. Eine andere KI nur, wenn du sie ausdrücklich nennst.
  • Mit review.engines legt ein Projekt fest, an welche KI ein Review überhaupt Code schicken darf.
  • Regeln aus .claude/rules/ im Projekt ersetzen gleichnamige globale Regeln.

Was du bekommst.

39Regeln prüfen jeden Befehl und jeden Dateizugriff.
33Detektoren prüfen jede neue Zeile.
< 80 mspro Prüfung (p95). Der Agent wird nicht spürbar langsamer.
lokalLäuft auf deinem Rechner, ohne Telemetrie. Paketnamen gehen an npm und PyPI, Diffs nur bei einem Review an deine KI.

Regeln, die mit dem Projekt kommen.

  • .workban-guard.json im Repository verschärft die Regeln für alle. Lockern geht erst nach deiner Freigabe mit /wbg:trust.
  • Eigene Regeln als regulärer Ausdruck oder Pfad-Glob, zum Beispiel: keine Verbindung zur Produktionsdatenbank.
  • Modus plan erlaubt nur Lesen bis zur Freigabe, autopilot ist für unbeaufsichtigte Läufe.
  • Jede Entscheidung steht im Audit-Log .workban-guard/audit.jsonl, Secrets maskiert.
  • /wbg:allow gibt genau eine gesperrte Aktion einmal frei, wenn du sie doch willst.

Workban Guard ist nicht öffentlich.

Zugang bekommt ein ganzer Workspace in Workban. Mit der Registrierung legst du einen an. Als Owner oder Admin fragst du dann in Workban unter Einstellungen → Workban Guard die Freischaltung an. Ist sie erteilt, installiert jedes Mitglied Workban Guard mit seinem Workban-Konto, ohne eigenen Token.

Mit Workban startenZur Installation