Skip to main content
Failproof AI ist so konzipiert, dass ein Durchsetzungsfehler sichtbar wird, anstatt riskante Aktionen stillschweigend zuzulassen.

​
Einen Failure-Closed-Block diagnostizieren

  1. Gehen Sie zu Admin → enforcement und öffnen Sie den Rechner.
  2. Prüfen Sie dessen letzten Check-in, zugewiesene Deployment und gemeldetes Deployment.
  3. Gehen Sie zu Observe → policy und öffnen Sie die Sitzung der abgelehnten Entscheidung.
  4. Überprüfen Sie, ob der Grund auf Daemon-Erreichbarkeit, Versionsabweichung oder die Policy selbst hinweist.
Auf einem Rechner, der für die Verwendung von failproofaid konfiguriert ist, ist der Daemon der einzige Auswerter. Wenn er nicht erreichbar ist oder seine Protokollversion nicht mit der CLI übereinstimmt, schlägt die Hook-Auswertung geschlossen fehl. Die Aktion wird mit einem Hinweis abgelehnt, der den Operator auffordert, den Daemon zu überprüfen oder zu aktualisieren. Vor der Daemon-Konfiguration werten Hooks Policies prozessintern aus. Sobald die Daemon-Konfiguration gespeichert ist, fällt Failproof AI bei einem Daemon-Ausfall nicht stillschweigend auf einen zweiten Auswerter zurück.

​
Auf eine Failure-Closed-Entscheidung reagieren

  1. Führen Sie failproofai config --status aus.
  2. Wenn sich die Versionen unterscheiden, führen Sie failproofai config nach dem Paket-Update erneut aus.
  3. Wenn der Daemon nicht erreichbar ist, prüfen Sie dessen Dienststatus und lokale Logs.
  4. Setzen Sie die Agenten-Arbeit erst fort, wenn ein bekannter Policy-Auswertungspfad wieder funktioniert.
Wiederholen Sie die blockierte Aktion nicht wiederholt. Eine Failure-Closed-Antwort bedeutet, dass das System nicht feststellen konnte, ob die Aktion sicher war.

​
Ein Pack lässt sich nicht laden

Ein Rechner, der angewiesen wurde, ein Pack durchzusetzen, und es nicht ausführen kann, lehnt ab, anstatt stillschweigend fortzufahren. Der Auslöser ist eine aufgezeichnete Erwartung, niemals eine leere: Ein Rechner ohne installierte Packs ist still, während ein Pack, das deklariert wurde und sich nicht auflösen lässt – oder das weniger registriert als sein Manifest angibt – ablehnt. Die Ablehnung ist eng gefasst, anders als bei einem nicht erreichbaren Daemon. Ein Daemon, der nicht erreicht werden kann, bedeutet, dass überhaupt keine Auswertung stattgefunden hat und daher nichts als sicher eingestuft werden kann. Ein Pack, das sich nicht laden lässt, hat eine aufzählbare Menge fehlender Guards, da jede deklarierte Policy ihren eigenen match mitbringt – es lehnt daher nur die Ereignisse und Tools ab, die diese Policies abdeckten, während alles andere weiterläuft. Es wird nicht ausgelöst bei:
  • einem observe-Pack, das konstruktionsbedingt auswertet und verwirft
  • Policies, die nie übernommen oder explizit deaktiviert wurden
  • einem Pack, das der Loader nie erhalten hat, wo sich „keine Registrierungen” nicht von einem bewussten Überspringen unterscheiden lässt
  • einer Pause einer aktiven Sitzung
  • einem Load-Timeout, das vorübergehend ist – ein kurzer langsamer Festplattenmoment darf nicht ablehnen, bis ein Mensch eingreift
UserPromptSubmit instruiert statt abzulehnen, unabhängig davon, was die fehlende Policy deklariert hat. Eine pauschale Ablehnung würde dies einschließen und Sie vom Agenten aussperren, der das Problem beheben könnte.

​
Vorgehensweise

Der Befehl nennt alle installierten Packs, die sich nicht laden lassen, gibt den Grund an und beendet sich mit einem Nicht-Null-Exit-Code. Installieren Sie das Pack anschließend entweder neu (failproofai pack add <source>) oder entfernen Sie es (failproofai pack remove <publisher/name>) – durch das Entfernen wird die Erwartung zurückgezogen, und die Ablehnung endet damit.