Benutzerdefinierte Richtlinien

Erstelle eine Datei mit der Endung policies.js, policies.mjs oder policies.ts unter .failproofai/policies/. Konventionsdateien werden automatisch auf Projekt- und Benutzerebene geladen.

Richtlinie vor der Cloud-Veröffentlichung testen

Dashboard
CLI

Installiere die benutzerdefinierte Richtlinie auf einem Testrechner und löse sowohl eine übereinstimmende Aktion als auch eine legitime Nicht-Übereinstimmung aus.
Gehe zu Observe → policy und vergleiche die beiden Entscheidungen.
Öffne jede verknüpfte Sitzung und überprüfe, ob das Ereignis-Payload genügend Belege für die Regel enthält.
Wenn das Verhalten korrekt ist, verschiebe den geprüften Quellcode in Admin → policy editor und veröffentliche eine Version.

failproofai policies --install --custom ./security.policies.ts \
  --cli claude --scope project
failproofai policies

Konventionsdateien unter .failproofai/policies/ werden ohne --custom geladen. Behalte einen expliziten Installationsbefehl in CI, wenn die Validierung bei einem defekten Modul fehlschlagen soll.

import { customPolicies, allow, deny } from "failproofai";

customPolicies.add({
  name: "protect-production-paths",
  description: "Block writes to production configuration",
  match: { events: ["PreToolUse"] },
  fn: async (ctx) => {
    if (ctx.toolName !== "Write" && ctx.toolName !== "Edit") return allow();
    const path = String(ctx.toolInput?.file_path ?? "").replaceAll("\\", "/");
    if (path.split("/").includes("production")) {
      return deny("Writes to production configuration require approval.");
    }
    return allow();
  },
});

Dies trifft auf production/config.yml, /srv/production/config.yml, /srv/production und C:\\production\\config.yml sowohl für Write als auch für Edit zu. Namen wie production-backup werden nicht erfasst, da production ein vollständiges Pfadsegment sein muss. Validiere und installiere eine explizite Datei:

failproofai policies --install --custom ./security.policies.ts

Der Richtlinienkontext enthält den Ereignistyp, die normalisierte Nutzlast, den Tool-Namen und die Tool-Eingabe, Sitzungsmetadaten, Parameter sowie das Quell-CLI, sofern verfügbar.

Fehlerpfade testen

Führe die Validierung nach dem Ändern der Einstiegsdatei oder eines lokalen Moduls, das sie importiert, erneut aus:

failproofai policies --install --custom ./security.policies.ts --scope project

Der strikte CLI-Pfad schlägt bei fehlenden Dateien, Syntaxfehlern, nicht auflösbaren Importen, Ausnahmen auf oberster Ebene und Zeitüberschreitungen beim Modulladen fehl. Zur Durchsetzungszeit wird eine defekte benutzerdefinierte Datei protokolliert und übersprungen, damit eingebaute Richtlinien weiter ausgeführt werden können. Behandle jede Ladewarnung als Verlust der erwarteten Durchsetzung und löse in Produktionsprotokollen einen Alarm aus. Verwende global eindeutige Namen für explizite, konventionsbasierte und Cloud-verwaltete Richtlinien. Halte Richtlinienfunktionen deterministisch, begrenze externe Aufrufe mit kurzen Timeouts und gib auf jedem Pfad ein bewusstes allow, instruct oder deny zurück.

Eine benutzerdefinierte Richtlinie ist Durchsetzungscode. Teste fehlende Felder, alternative Tool-Namen und fehlerhafte Eingaben – nicht nur die erwartete Übereinstimmung.

​Richtlinie vor der Cloud-Veröffentlichung testen

​Fehlerpfade testen

Richtlinie vor der Cloud-Veröffentlichung testen

Fehlerpfade testen