FailproofAI: Protokollierung und Durchsetzung für Agenten-Harnesses

Wo Agenten-Läufe heute auseinanderfallen

Wer mehrere Coding-CLIs parallel nutzt, kennt das Problem: Claude Code schreibt seine Sitzung an eine Stelle, Codex an eine andere, und ein selbst gehosteter Assistent wie OpenClaw hat wieder eine eigene Ablage. Jede Harness bringt eigene Hooks mit, eigene Ereignisformate, eigene Grenzen dafür, was sich überhaupt abfangen lässt. FailproofAI setzt genau dort an und verspricht im README "Same events, same policies, same session history, whichever one your agent runs in". Die Zielgruppe sind damit nicht einzelne Entwickler, die eine CLI benutzen, sondern Teams, die mehrere Agenten-Runtimes betreiben und keine Lust haben, für jede eine eigene Auswertung zu bauen. Der zweite Teil des Versprechens ist die Durchsetzung: Tool-Aufrufe sollen nicht nur protokolliert, sondern vor der Ausführung blockiert werden können.

Hooks als einziger Eingriffspunkt

Der Mechanismus ist im README klar benannt: Failproof "hooks 12 agent harnesses". Es gibt also keinen Proxy, der den Netzwerkverkehr abgreift, und keinen Wrapper, der die CLI umschließt. Der Eingriff erfolgt über die Hook-Schnittstellen der jeweiligen Harness. Das erklärt, warum die Liste der unterstützten Systeme so aussieht, wie sie aussieht: zehn Coding-CLIs (Claude Code, Codex, GitHub Copilot CLI, Cursor Agent CLI, OpenCode, Pi, Factory Droid, Devin CLI, Antigravity CLI, Goose) und zwei Chat- beziehungsweise Assistant-Gateways (Hermes, OpenClaw). Die Aufteilung in zwei Klassen ist kein Marketing-Detail, sondern folgt aus den Hook-Modellen der Systeme. Für alles außerhalb dieser zwölf gibt es laut README nur das Python-SDK, und dort ausdrücklich ohne Durchsetzung: "Enforcement there needs a hook in your own runtime". Wer also einen eigenen Agenten-Loop gebaut hat, bekommt Tracing, Sitzungen und Audits, aber keine Policy-Blockade, solange er nicht selbst einen Hook implementiert.

Installation und der abgeschnittene README

Hier wird die Materiallage dünn. Der README-Auszug endet mitten im Installationsabschnitt, direkt nach der Zeile ```sh und dem Wort npm. Der vollständige Befehl, die Konfigurationsdatei, die Namen der Config-Keys und die Art und Weise, wie ein Hook in eine Harness eingetragen wird, sind in dem vorliegenden Ausschnitt nicht enthalten. Ich kann deshalb keinen Installationsweg beschreiben, ohne ihn zu erfinden. Gesichert ist lediglich, dass es ein npm-Paket namens failproofai gibt (der Badge verlinkt auf npmjs.com/package/failproofai) und dass die Releases eine separate SDK-Linie führen: failproofai-sdk in Version 0.0.1b2, veröffentlicht am 8. September 2026. Die SDK-Version mit dem Suffix b2 und der 0.0.1-Nummer spricht dafür, dass dieser Teil deutlich jünger ist als das Hauptpaket, das parallel bei v1.0.4-beta.4 steht. Für die konkrete Inbetriebnahme muss man die Dokumentation unter docs.befailproof.ai heranziehen.

Neununddreißig Policies und die Frage nach dem Katalog

Das README nennt "39 built-in policies" als blockierenden Bestandteil, während die Repository-Beschreibung von 40 spricht. Diese Abweichung zwischen den beiden Angaben im selben Projekt ist klein, aber sie ist der einzige konkrete Hinweis darauf, wie gepflegt die Außendarstellung ist. Inhaltlich entscheidend ist ohnehin nicht die Zahl, sondern welche Tool-Aufrufe eine Policy tatsächlich abfängt und wie sich eigene Regeln ergänzen lassen. Dazu sagt der Auszug nichts. Wer FailproofAI evaluiert, sollte die 39 Policies einzeln durchsehen, bevor er sich auf die Durchsetzung verlässt. Eine Policy, die einen rm -rf auf ein falsches Verzeichnis nicht erkennt, ist im Betrieb wertlos, egal wie lang der Katalog ist. Die Zahl allein ist kein Qualitätsmaß.

Lokal, ohne Konto, mit einer Einschränkung

FailproofAI bewirbt drei Eigenschaften, die für den Einsatz in regulierten Umgebungen relevant sind: "Runs locally", "no account required" und "Zero latency". Die ersten beiden sind nachvollziehbar, weil die Ausführung lokal erfolgt und kein Cloud-Login erzwungen wird. Der dritte Punkt ist die schwächste Behauptung im Text. Jede Hook-basierte Erfassung fügt dem Agenten-Lauf Arbeit hinzu, und ob diese Arbeit im Millisekundenbereich bleibt, hängt davon ab, was die Policies prüfen und ob Ereignisse lokal geschrieben oder zusätzlich an einen Dienst gesendet werden. Das README liefert keine Messung, keinen Benchmark und keine Angabe, worauf sich die Null bezieht. Wer Latenz als Auswahlkriterium hat, sollte das selbst messen, statt die Angabe zu übernehmen. Es gibt daneben einen "generous free cloud plan", der ohne Konto nutzbar sein soll; ob und wann Daten das lokale System verlassen, geht aus dem Auszug nicht hervor.

Wann FailproofAI das falsche Werkzeug ist

Zwei Fälle sind aus dem Material klar ableitbar. Erstens: Agents, die in keiner der zwölf Harnesses laufen. Dort gibt es Tracing, aber keine Durchsetzung, und damit genau die Hälfte dessen, was das Projekt ausmacht. Zweitens: Umgebungen, die eine belastbare, klar benannte Open-Source-Lizenz voraussetzen. Der License-Badge im README behauptet "MIT + Commons Clause", das Repository selbst meldet dagegen NOASSERTION, also keine maschinenlesbare Lizenzkennung. Das ist ein Widerspruch, der vor einer Übernahme in kommerzielle Produkte geklärt werden muss. Die Commons Clause schränkt den Verkauf von Software ein, die auf dem lizenzierten Code basiert; was genau hier gilt, lässt sich aus dem Auszug nicht sagen, und das ist keine Rechtsberatung, sondern der Hinweis, dass hier eine offene Frage steht. Dazu kommt der Reifegrad: Die Releases tragen Beta-Nummern (v1.0.4-beta.4), die veröffentlichten Zeitstempel liegen dicht beieinander.

Der Unterschied zu reinen Tracing-Backends

Die naheliegende Alternative sind Tracing-Systeme wie Langfuse oder OpenTelemetry-basierte Pipelines, die Agenten-Läufe über SDK-Instrumentierung erfassen und in einem Backend auswertbar machen. Der Unterschied liegt nicht im Umfang der Auswertung, sondern im Zeitpunkt des Eingriffs. Ein Tracing-Backend beobachtet nachgelagert: Der Tool-Aufruf ist bereits ausgeführt, wenn das Span geschrieben wird. FailproofAI sitzt davor und kann ihn verhindern, weil es über die Hooks der Harness im Ausführungspfad liegt. Das ist ein grundlegend anderes Modell, und es erklärt auch die Abhängigkeit von den zwölf Harnesses: Ohne Hook gibt es keinen Punkt, an dem sich ein Aufruf stoppen lässt. Umgekehrt erkauft man sich diesen Vorteil mit einer Bindung an die Hook-APIs der jeweiligen Anbieter. Ändert eine Harness ihr Hook-Format, muss FailproofAI nachziehen. Ein SDK-basiertes Tracing-System hat dieses Problem nicht, kann dafür aber nichts blockieren.

Wartung, Versionen und was zu prüfen bleibt

Die Release-Historie zeigt zwei getrennte Versionslinien: das Hauptpaket bei v1.0.4-beta.4 und das SDK bei 0.0.1b2. Wer das SDK einsetzt, muss mit Änderungen an einer Schnittstelle rechnen, die noch keine 0.1 erreicht hat. Die npm-Bindung bedeutet, dass Aktualisierungen über die üblichen Befehle laufen, aber die Konfiguration der Hooks pro Harness liegt außerhalb des Pakets und muss bei Änderungen an den Harness-Schnittstellen angepasst werden. Das ist der eigentliche Wartungsaufwand, nicht das Paket selbst. Zwölf Integrationen bedeuten zwölf Stellen, an denen etwas brechen kann, wenn ein Anbieter seine Hook-API umbaut. Vor einem produktiven Einsatz sind drei Dinge zu klären: die Lizenzfrage hinter NOASSERTION, der vollständige Installationsweg aus der offiziellen Dokumentation und die Frage, welche der 39 Policies welchen Tool-Aufruf tatsächlich blockiert.

Redaktionelles Fazit

FailproofAI passt zu Teams, die mehrere Coding-CLIs parallel betreiben und Tool-Aufrufe zentral blockieren wollen, ohne einen Cloud-Account anzulegen. Wer Agents in keiner der zwölf Harnesses laufen lässt, bekommt laut README nur Tracing über das Python-SDK, Enforcement dagegen nicht. Vor dem Einsatz sind zwei Dinge zu prüfen: die tatsächliche Lizenz hinter dem NOASSERTION-Eintrag und der vollständige Installationsweg, den der vorliegende README-Auszug nach dem npm-Block abbricht.

Offizielle Quellen

1. FailproofAI/failproofai on GitHub
2. Issues
3. Project website
4. README
5. Releases