Skip to main content
Ein Harness ist die Umgebung, in der Ihr Agent tatsächlich ausgeführt wird. Failproof AI unterstützt zwölf davon, in zwei Klassen:
  • Coding-CLIs (10) — Claude Code, Codex, GitHub Copilot CLI, Cursor, OpenCode, Pi, Factory Droid, Devin CLI, Antigravity CLI, Goose
  • Chat- und Assistant-Gateways (2) — Hermes (Slack, Telegram, Cron), OpenClaw (selbst gehosteter Assistent)
Dieselben Richtlinien und dieselbe Sitzungshistorie gelten unabhängig davon, in welchem Harness ein Agent läuft. Eine Adapter-Schicht bildet die nativen Ereignisnamen, Tool-Namen und Tool-Eingabefelder jedes Harness auf 29 kanonische Ereignisse ab, bevor eine Richtlinie ausgeführt wird. Ein Agent, der in keinem der zwölf Harnesses läuft, wird direkt mit dem Python SDK instrumentiert. Das ist ein anderer Vertrag, und das sollte klar gesagt werden: Das SDK liefert Tracing, Sitzungen, Evaluierungen und Audits — es setzt Richtlinien nicht eigenständig durch. Das Blockieren einer unsicheren Aktion vor ihrer Ausführung erfordert einen Enforcement-Hook an der Tool-Grenze Ihrer Laufzeitumgebung; kontaktieren Sie uns und wir werden es abbilden. Jede Integration normalisiert ihre nativen Hook-Ereignisnamen, Tool-Namen und Tool-Eingabefelder, bevor Richtlinien ausgeführt werden. Eine Richtlinie kann nur auf Ereignisse reagieren, die der Harness bereitstellt; testen Sie das Verhalten am Sitzungsende und bei Anweisungen mit dem genauen Harness und der Version, die Sie einsetzen.

Enforcement-Fähigkeiten

„Blockieren” bedeutet, dass das vom aktuellen Adapter zurückgegebene Urteil vom genannten Harness verarbeitet wird. Post-Tool-Blockierung kann das dem Modell angezeigte Ergebnis ersetzen, kann jedoch einen bereits eingetretenen Tool-Seiteneffekt nicht rückgängig machen. Fähigkeiten sind versionsabhängig. Führen Sie nach dem Upgrade einer Agent-CLI erneut Tests durch, insbesondere wenn eine Richtlinie auf Prompt-, Stop-, Permission- oder Post-Tool-Verhalten anstelle des üblichen Pre-Tool-Gates angewiesen ist.

Capture- und Policy-Hooks installieren

  1. Öffnen Sie Administration → Keys und erstellen Sie einen Schlüssel mit events:add und policies:pull, benannt nach der Maschine oder Umgebung.
  2. Verbinden Sie auf der Zielmaschine die lokale CLI mit dem angezeigten Schlüssel und installieren Sie die Harness-Hooks.
  3. Starten Sie eine neue Agent-Sitzung und bestätigen Sie deren Hook- und Sitzungsereignisse unter Observe → Events.
  4. Öffnen Sie Observe → policy für dasselbe Zeitfenster und bestätigen Sie, dass eine Richtlinienentscheidung der Maschine zugeordnet wird.
Die Verbindung beginnt mit einem Maschinenschlüssel. Stellen Sie sicher, dass er sowohl Ingestion- als auch Policy-Delivery-Berechtigungen enthält, bevor Sie das Secret kopieren.Die neue API-Schlüssel-Schublade zum Gewähren von Ereignis-Ingestion- und Policy-Delivery-Berechtigungen.Nach der Installation der Hooks sollte der Events-Stream neue Ereignisse von der verbundenen Maschine und Umgebung anzeigen.Der Live-Events-Stream zur Bestätigung, dass ein neu installierter Harness Berichte sendet.Überprüfen Sie abschließend, ob Richtlinienentscheidungen derselben Maschine zugeordnet werden. Dies bestätigt, dass der Harness sowohl Richtlinienaktivitäten als auch Trace-Ereignisse meldet.Die Policy-Seite zur Überprüfung von Richtlinienentscheidungen eines neu verbundenen Harness.

Nicht-standardmäßigen Sitzungspfad hinzufügen

Zusätzliche Pfade werden auf der Maschine registriert, nicht in der Cloud. Nachdem Sie einen hinzugefügt haben, öffnen Sie Observe → Sessions, filtern Sie nach der Umgebung der Maschine und bestätigen Sie, dass Sitzungen aus dem neuen Pfad erscheinen. Öffnen Sie eine Sitzung und überprüfen Sie Agent, Harness und Ereignis-Zeitstempel, bevor Sie diese in einem Audit verwenden.Die Sitzungsliste, gefiltert nach der Umgebung, die Daten vom zusätzlichen Capture-Pfad empfängt.
Führen Sie nach der Installation eine neue Sitzung aus. Überprüfen Sie sowohl den Live-Event-Stream als auch eine tatsächliche Richtlinienentscheidung, bevor Sie den Rollout ausweiten.