Skip to main content
監査のゴールと対象集団が、別のオペレーターでも有効な検出結果の判断基準を理解できる程度に具体化されてから実行してください。

実行と確認

  1. Analyze → Audits に移動し、対象の監査を開いて run now を選択します。キューに追加されたというレスポンスが返れば、ディスパッチャーが間もなく処理を開始します。
  2. 新しいランを開き、ステータス、ウィンドウ、所要時間、検出件数、レポートを確認します。
  3. エビデンスセッションを選択して、正確なトレースを表示します。
  4. 監査ページに戻って設定を編集したり、スケジュールを無効化したり、過去のランを調査したりできます。 オープンな検出結果、前回と次回のラン状態、スイープウィンドウ、コンテキスト、今すぐ実行コントロール、ランク付きの検出結果を表示した監査詳細ページ。

実行前の確認事項

  • 選択した時間ウィンドウ内にセッションが存在することを確認する。
  • 環境およびエージェントのフィルター設定を検証する。
  • 参照コンテキストが最新の状態であることを確認する。
  • ゴールが望ましい結論ではなく、障害モードを記述していることを確認する。

ランのレビュー

まずランのステータス、セッションの対象範囲、モデル分析が実行されたかどうかを確認します。次に、各検出結果の深刻度、説明、エビデンスセッション、補足クエリ、推奨される防止策を調査します。 検出結果のステータスを使用して、承認、ミュート、却下、解決、再オープン、または作業の割り当てを行います。検出結果が却下された場合でもエビデンスは保持してください。その判断がなぜ下されたかを後から確認できます。

空のランまたは遅延したランの解釈

分析が実行されなかった場合、since_last 監査はその未分析のウィンドウを次の成功したランまで開いたままにします。スキップされた分析は障害が解消した証拠にはならないため、既存の検出結果は削除されません。

失敗通知について

ランの失敗またはモデル分析ステップの失敗が発生した場合、監査に設定されたメール受信者に通知が送られます。監査にメールチャネルが設定されていない場合、Failproof AI は組織の alerts.email_default_recipients 設定にフォールバックするため、監査が無音で壊れていても必ずエスカレーションパスが確保されます。 メールは組織レベルで有効化されており、SMTPが設定されている必要があります。設定されていない場合、失敗はログに記録されますがメールは送信されません。ランの失敗によって、監査の固定スケジュールアンカーが移動することはありません。 すべてのランは、各エージェントに使用された正確なエージェントコンテキストをコントラクトスナップショットとして保存します。後から編集を行っても、以前のランに記録されたエビデンス基準は変更されません。
未検証の検出結果から直接ブロッキングポリシーをデプロイしないでください。引用されたトレースを開き、そのルールが安全でない動作と正当な作業を正しく分離していることを確認してください。