Skip to main content
Öffne Verwaltung → Schlüssel und bestätige, dass der Maschinenschlüssel aktiv ist und die Berechtigung events:add besitzt. Öffne dann Beobachten → Ereignisse, erweitere den Zeitraum und entferne Umgebungs- und Agenten-Filter. Falls Ereignisse vorhanden sind, suche nach der Sitzungs-ID und prüfe anschließend Beobachten → Sitzungen auf Gruppierungen. Falls keine Ereignisse vorhanden sind, diagnostiziere den Failproof-Daemon über die CLI.Der Live-Ereignisstream mit seinen primären Filtern und aktuell eintreffenden Agenten-Ereignissen.
Entferne Filter unter Beobachten → Ereignisse und suche nach der genauen SDK-Sitzungs-ID. Falls nichts erscheint, untersuche den SDK-Spool und den Failproof-Daemon auf dem Quellrechner.
Öffne Admin → Durchsetzung, wähle den Rechner aus und vergleiche dessen zugewiesene, gemeldete und vorherige Versionen. Bestätige, dass der Deployment-Geltungsbereich den Rechner einschließt und sein Schlüssel policies:pull besitzt. Die Erfassung kann funktionieren, auch wenn die Richtlinienübertragung fehlschlägt.
Öffne Admin → Durchsetzung und prüfe den Zeitpunkt der letzten Aktivität und die gemeldete Version des Rechners. Falls der Rechner veraltet ist, handelt es sich um ein lokales Daemon-Problem. Schwäche die bereitgestellte Richtlinie nicht allein deshalb ab, um einen nicht verfügbaren Daemon zu umgehen.
Für eine Cloud-erstellte Richtlinie: Öffne Admin → Richtlinien-Editor, wähle den Entwurf aus und prüfe Validierungsfehler vor der Veröffentlichung. Für eine lokale Richtlinie: Validiere sie über die CLI und öffne anschließend Beobachten → Richtlinie nach einer Testaktion, um zu bestätigen, dass Entscheidungen ankommen.
Öffne Analysieren → Audits, wähle den Lauf aus und prüfe, ob die Modellanalyse ausgeführt wurde. Vergleiche anschließend Geltungsbereich und Zeitfenster mit Beobachten → Sitzungen und öffne repräsentative Traces aus dieser Population.Ein Nullergebnis ist nur dann aussagekräftig, wenn die Analyse erfolgreich durchgeführt wurde. Falls die Analyse übersprungen oder fehlgeschlagen ist, liefert der Lauf keine Ergebnisse und hält das nicht analysierte Zeitfenster für einen künftigen erfolgreichen Lauf offen. Falls die Modellanalyse deaktiviert ist, liefert das Audit ebenfalls keine Ergebnisse, da der deterministische Anmeldedaten- und PII-Scan nur Statistiken erfasst, aber keine Befunde mehr meldet.Das Audit-Formular, in dem Umgebung, Agent, Kadenz und Sweep-Zeitfenster die Sitzungspopulation definieren.
Öffne eine abgeschlossene Sitzung und prüfe, ob eine manuelle Evaluierung erfolgreich ist. Im gehosteten Cloud-Betrieb gibt es derzeit keine Steuerung des Evaluator-Endpunkts im Dashboard; der Server-Operator muss dies konfigurieren.
Nutze den Organisations-Umschalter und bestätige den erwarteten Slug sowie die Berechtigungen, bevor du die Ergebnisse mit der CLI vergleichst.
Öffne Beobachten → Richtlinie, bewahre die Entscheidung und die verknüpfte Sitzung und identifiziere die False-Positive-Bedingung. Öffne dann Admin → Durchsetzung und setze die betroffenen Rechner auf die vorherige Version zurück. Erstelle eine engere Version im Richtlinien-Editor, teste sie auf einem kleinen Geltungsbereich und erweitere ihn erst, wenn legitime Arbeit erfolgreich ausgeführt wird.
Wenn du den Support kontaktierst, gib die CLI-Version, das Harness, die Umgebung, die relevante Sitzungs- oder Deployment-ID sowie die Ausgabe von failproofai config --status (ohne vertrauliche Informationen) an.