Workban Guard

Guardrails für Coding-Agenten

Dein Agent darf viel.

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.

InstallierenFreischaltung anfragen

Version 0.2.0 · für Claude Code und Codex CLI · läuft lokal

  • Claude Code
  • Codex CLI
  • 39 Regeln
  • 30 Detektoren
  • p95 < 80 ms

Protokoll

wbg check

  1. denyrm -rf ~würde dein Home-Verzeichnis löschenfs.rm-catastrophic
  2. denygit push --force origin mainüberschreibt fremde Commits auf maingit.force-push
  3. denycat .envbrächte Secrets in den Verlauf und zum Modell-Anbietersecrets.read-env
  4. denynpm install reqeustsdas Paket gibt es nicht, ein typischer erfundener Namedeps.not-found
  5. askgit reset --hardverwirft nicht committete Änderungengit.discard-changes
  6. askpnpm db:resetdas Script führt supabase db reset ausdb.destructive
Echte Entscheidungen von wbg check

01 · Vor der Ausführung

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.

02 · Nach jedem Edit

Jede neue Zeile wird geprüft, nicht der Altbestand.

30 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
  • .only in Tests und Assertions, die immer bestehen

03 · Bevor er fertig ist

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.

04 · Cold Review

Ein 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.

05 · Kennzahlen

Was du bekommst.

  • 39Regeln prüfen jeden Befehl und jeden Dateizugriff.
  • 30Detektoren 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.

06 · Für Teams

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.

Zugang über Workban

Workban Guard ist nicht öffentlich.

Zugang bekommt ein ganzer Workspace in Workban. Ist er freigeschaltet, installiert jedes Mitglied Workban Guard mit seinem Workban-Konto, ohne eigenen Token. Schreib an christian@cg-labs.dev, für welchen Workspace und welche Projekte du es einsetzen willst.

Freischaltung anfragenZur Installation