Skip to main content
Beta-Funktion. Die Audit-Funktion wird als Beta veröffentlicht, während wir erstes Feedback sammeln. Der Detektor-Katalog und das Berichtsformat können sich vor dem nächsten stabilen Release ändern. Bitte eröffne ein Issue, falls etwas nicht stimmt.
Das Audit spielt vergangene Agent-CLI-Transkripte durch failproofais Policy-Engine und zeigt einen teilbaren, visuellen Bericht auf der /audit-Dashboard-Seite an — den Archetypen deines Agenten, einen Score von 0–100 und genau welche Policies was erkannt hätten.

​
Ausführen

Drei Einstiegsmöglichkeiten — alle führen zum selben /audit-Bericht.

Ohne Installation

npx -y failproofai audit lädt failproofai herunter, führt den Scan durch und öffnet das Dashboard für dich — ohne vorherige Installation.

Über die CLI

failproofai audit führt den Scan im Terminal aus und öffnet localhost:8020/audit automatisch nach Abschluss.

Über das Dashboard

Starte failproofai und klicke in der Navigationsleiste auf Audit (zwischen Policies und Projects), oder öffne /audit direkt.
Führe failproofai audit -h (oder --help) aus, um die Nutzungshinweise anzuzeigen. Das Audit läuft vollständig offline — kein Konto oder Netzwerk erforderlich — und das Dashboard bleibt aktiv, bis du es mit Ctrl+C beendest.
Das Dashboard scannt vergangene Agent-CLI-Transkripte auf diesem Rechner (Claude Code, Codex, Copilot, Cursor, OpenCode, Pi) und zeigt an, wie oft der Agent Dinge getan hat, die failproofai verhindern soll — Umgebungsvariablen-Prüfungen, Force-Pushes, redundante cd <cwd>-Präfixe, Sleep-Polling-Schleifen, erneutes Lesen gerade bearbeiteter Dateien und mehr. Für jedes Transkript wird jedes Tool-Use-Ereignis durch die 39 integrierten Policies und durch 8 audit-exklusive Detektoren wiedergegeben, die Muster erkennen, die noch nicht durch Laufzeit-Policies abgedeckt sind. Die Zählungen werden pro Policy/Detektor über alle Sitzungen hinweg aggregiert.

​
Was du erhältst

Die /audit-Seite ist ein einseitiges, teilbares Poster gefolgt von vier weiteren Abschnitten unterhalb des sichtbaren Bereichs:
  1. Poster — die Identität deines Agenten auf einen Blick: sein Archetyp (einer von 8 — optimist, cowboy, explorer, goldfish, paranoid architect, precision builder, hammer, ghost), seine Persona-Schlagwörter, wie selten dieser Archetyp ist, und ein Score von 0–100 mit einer Tier-Einstufung (S bis bottom tier). Zum Teilen gedacht — poste es auf X oder LinkedIn, oder lade es als PNG herunter.
  2. // strengths — was dein Agent bereits gut macht, als echte Zahlen aus dem Scan (z. B. Clean-Tool-Call-%, 0 Push-to-Main-Versuche), nur angezeigt, wo die betreffende Policy eine saubere Bilanz hat.
  3. // quirks — was durchgerutscht ist: eine priorisierte Tabelle mit Verhaltensweisen, die failproofai abgefangen hätte — wann es zuletzt passiert ist, was durchgerutscht ist (und das integrierte Policy, das es blockiert hätte), der Schweregrad und wie oft es aufgetreten ist (new / recurring / N× seen).
  4. // how to improve — die empfohlene Behebungsliste: eine Zeile pro Policy mit einem kopierbaren failproofai policy add <slug>, plus einem Install all-Button, der alle Empfehlungen auf einmal aktiviert und deinen voraussichtlichen Score anzeigt.
  5. // come back better — baue eine Gewohnheit auf: setze eine E-Mail-Erinnerung für das nächste Audit (3d / 7d / 14d / 30d) oder starte jetzt ein erneutes Audit, und lade einen Freund ein, sein eigenes Audit durchzuführen (gesendet von failproof.ai, Cc an dich). Erinnerungen und Einladungen erfordern eine Anmeldung.

​
Geplante Audits

Wenn du den failproofaid-Daemon ausführst (siehe failproofai config), kann er das Audit nach einem Zeitplan für dich wiederholen und den /audit-Bericht im Hintergrund aktualisieren. Er ist standardmäßig deaktiviert, da der Scan den Inhalt jedes Agent-Sitzungstranskripts auf diesem Rechner liest — nichts scannt nach einem Timer, bis du es anforderst. Aktiviere es in ~/.failproofai/config.toml:
  • Der Zeitplan basiert auf der Echtzeit, übersteht also Suspend und Neustarts: Ein Laptop, der seinen fälligen Zeitpunkt im Schlafmodus verpasst hat, läuft einmal beim Aufwachen — ohne Rückstand.
  • Jeder Durchlauf ist ein separater Prozess mit niedriger Priorität (nice 19) — nie der Hook-Pfad des Daemons, der frei bleibt, um Tool-Aufrufe zu beantworten.
  • Ein Scan wird übersprungen, wenn failproofai audit oder der erneute Durchlauf des Dashboards bereits läuft; er wird kurz danach wiederholt, anstatt als Fehler behandelt zu werden.
  • Der Fortschritt wird in ~/.failproofai/state/audit-schedule.json gespeichert (letzter Durchlauf, nächste Fälligkeit). Der Daemon besitzt diese Datei — ändere den Rhythmus in config.toml.
Wenn du dies auf einem Rechner aktiviert hast, der mit einer älteren Version von failproofai eingerichtet wurde, führe einmalig failproofai config aus. Die Service-Definition des Daemons benötigt einen zusätzlichen Eintrag, bevor die CLI gestartet werden kann, und die Aktualisierung ist Teil dieses Befehls.

​
Audit-exklusive Detektoren

Diese erkennen Muster für „dummes Verhalten”, die (noch) nicht in Echtzeit erzwungen werden. Sie laufen nur während des Audits und blockieren niemals einen Live-Tool-Aufruf.

​
Caches

  • Transkript-spezifischer Cache unter ~/.failproofai/cache/audit/<sha1>.json, nach (mtime, size, engineVersion, detectorVersion) geordnet — wird automatisch ungültig, wenn das Transkript oder der Policy-/Detektor-Code sich ändert. Jeder Eintrag enthält auch einen cachedAt-Zeitstempel als TTL-Metadaten (nicht Teil des Cache-Schlüssels); Einträge, die älter als 7 Tage sind, werden beim Lesen abgelehnt, damit langlebige Ergebnisse nicht eine sich weiterentwickelnde Detektor-Absicht überleben.
  • Gesamtergebnis-Cache unter ~/.failproofai/audit-dashboard.json (Modus 0600). Ermöglicht dem Dashboard eine sofortige Darstellung beim Navigieren ohne erneuten Scan. Wird beim Lesen nach der 7-Tage-TTL ebenfalls abgelehnt — /audit fällt dann in seinen leeren Zustand zurück und fordert einen neuen Durchlauf an. Klicke unten im Bericht auf [ re-audit now ], um zu aktualisieren — ein erneutes Audit sendet noCache: true, umgeht damit den transkript-spezifischen Cache und scannt alle Transkripte neu, anstatt das gecachte Ergebnis zurückzugeben; der Durchlauf streamt den Fortschritt über einen fixierten Top-Streifen und tauscht das Ergebnis bei Erfolg direkt aus (kein Seitenneuladn; ein fehlgeschlagenes erneutes Audit behält den vorherigen Bericht).

​
Hinweise

  • Keine Änderungen. Das Audit läuft im Nur-Lesen-Modus. warn-repeated-tool-calls wird übersprungen, da sonst der sitzungsspezifische Begleiter geändert würde.
  • Workflow-Policies übersprungen. require-*-before-stop-Policies werden nur bei Stop-Ereignissen ausgelöst und führen execSync gegen den Live-Git-Zustand aus — sie haben keine sinnvolle „Was wäre 2025 passiert”-Interpretation und erscheinen daher nicht in den Audit-Zählungen.
  • Benutzerdefinierte Policies übersprungen. Vom Benutzer bereitgestellte benutzerdefinierte Hooks werden nicht wiedergegeben (sie können sich seit der ursprünglichen Sitzung geändert haben).