Skip to main content
監査のゴールと対象範囲が十分に具体化され、別のオペレーターが有効なファインディングとはどのようなものかを理解できる状態になってから実行してください。

実行と検査

  1. Analyze → Audits に移動し、監査を開いて run now を選択します。キューに入ったという応答は、ディスパッチャーがまもなく開始することを意味します。
  2. 新しい実行を開いて、ステータス、ウィンドウ、所要時間、ファインディング数、レポートを確認します。
  3. エビデンスセッションを選択して、正確なトレースを開きます。
  4. 監査ページに戻り、設定の編集、スケジュールの無効化、または過去の実行の検査を行います。 オープンなファインディング、前回と次回の実行状態、スイープウィンドウ、コンテキスト、今すぐ実行コントロール、およびランク付けされたファインディングを含む監査詳細ページ。

実行前の確認事項

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

実行のレビュー

まず実行ステータス、セッションカバレッジ、モデル分析が実行されたかどうかを確認します。次に、各ファインディングの重大度、説明、エビデンスセッション、サポートクエリ、提案された防止策を検査します。 ファインディングのステータスを使用して、承認、ミュート、却下、解決、再オープン、または作業の割り当てを行います。ファインディングが却下された場合でも、エビデンスは保持してください。それがその決定を下した理由を説明するものだからです。

空の実行または遅延した実行の解釈

分析が実行されなかった場合、since_last 監査はその未分析ウィンドウを次の成功した実行まで開いたままにします。スキップされた分析は障害が消えたという証拠ではないため、既存のファインディングは廃止されません。

失敗通知について

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