/<org-slug>/audits（サイドバー → analyze → audits）で、audits:read / audits:write 権限によって制御されています。
実行の仕組み
各実行は、決定論的なベース層とエージェント的な調査層の2層構成になっています。1. ポリシーパス（決定論的）
モデルが動作する前に、監査は対象ウィンドウに対してSQLポリシーチェックの小規模なカタログを実行します。これは既知の問題パターンにフラグを立て、一致したイベントの件数やセッションを報告する有界集計クエリです（一致したテキスト自体は報告しません）。カタログには以下が含まれます。- イベントペイロード内のシークレット／認証情報漏洩 — AWSアクセスキー、
sk-…APIキー、PEM秘密鍵、JWT／ベアラートークン、KEY=…形式の認証情報代入。 - プロンプトインジェクションのマーカー — “ignore previous instructions”、“reveal your system prompt” など類似表現。
- PII — SSN形式の数値（ヒューリスティック）。
- ツール権限の拒否およびツール呼び出しのループ暴走。
policy のフィンディングとして永続化され、常に表示されます（1回の実行あたりの上限でトリミングされることはありません）。また、AIエージェントの最初の手がかりとして渡されます。この層はモデルを必要としないため、AIエージェントが利用できない場合でも監査は最重要のセキュリティシグナルを生成します。
2. エージェント的調査（AI）
次に監査は自律型信頼性エージェントを実行します（ダッシュボードアシスタントと同じClaude Agent SDKサービスを使用し、監査専用のプロンプトが設定されています）。監査のスコープ（選択されたエージェント×環境）と時間ウィンドウが与えられると、エージェントは以下を行います。- アナリティクステーブルに対して読み取り専用のSQLクエリを実行する。
- 代表的なセッショントランスクリプトをいくつか読み込む。
- 必要に応じて、SQLでは表現できない分析（エラーのクラスタリング、分布の計算、取得済みペイロードの精査など）のために、ネットワークアクセス・ファイルシステムアクセスなし、シークレットスクラブ済みの隔離されたインPodサンドボックス内で短いPythonスクリプトを作成して実行する。
- 証拠のある改善点を記録する。
- 推奨事項（具体的な変更内容 — プロンプトの調整、ツールスキーマの修正、リトライポリシー、ガードレール、評価カバレッジの拡充など）
- 期待される効果と工数の見積もり（低 / 中 / 高）
- 重大度 —
big（オペレーターへの通知が必要）、medium（実行レポートに含める）、small（ダッシュボードのコンテキスト） - 安定したフィンガープリント（問題のカテゴリ＋スコープから生成され、今回の実行のセッションには依存しない）。これにより、証拠が変わっても同一の問題が実行をまたいで追跡される。
- 単純な決定論的監視で再発を検知できる場合は、ワンクリックで作成できるアラートの提案。
AIレイヤーはオプションですが推奨されます。 監査パイプラインにAIエージェントが設定されていない場合でも、実行は行われ、ポリシーフィンディングは永続化されます。エージェント層については、黙って合格とするのではなく、「分析利用不可」と正直に報告します。
障害モード
改善提案は組織の持続的な障害モードカタログに分類されます（新しいモードの提案も可能）。モードによりパターンに実行をまたいだ安定したIDが付与され、長期的な再発追跡が可能になります。トリアージのライフサイクル
フィンディングページ（/audits/<id>/findings/<finding-id>）では：
| アクション | 効果 |
|---|---|
| acknowledge（確認） | フィンディングを表示したまま優先度を半分にする。 |
| resolve（解決） | 修正済みとしてマークする。パターンが後日実際に再発した場合はnewとして再オープンされる — リグレッションは目立つ形で通知され、静かに履歴に埋もれることはない。 |
| mute（ミュート） / dismiss（却下） | 永続的な抑制：パターンのフィンガープリントが記録され、実行をまたいでも二度と表示されない。mute は「既知・許容済み」に、dismiss は「有用でない」場合に使用する。 |
| reopen（再オープン） | 抑制／解決をクリアし、パターンを再度ランキング対象にする。 |
top_k）で監査ごとに制御されます。ポリシーフィンディングはセキュリティ上重要であるため上限をバイパスし、常に表示されます。上限によって除外されたものは実行の統計にカウントされます — 静かに破棄されるものはありません。
スケジューリング
- 頻度（
schedule_interval_secs）：1時間ごとから1週間ごと。デフォルトは毎日。監査はアラートよりも意図的に粗い粒度になっています — エージェント的調査はウィンドウ全体をスキャンし、実行に数分かかります。 - ウィンドウ：固定のローリングルックバック（例：「各実行で過去7日間をスキャン」）または前回実行以降（デフォルト）のいずれか。後者は前回の成功実行が終了した時点から引き継ぎ、境界イベントを取りこぼさないよう小さなオーバーラップがあります。
- 次の実行は前回実行が完了してから1インターバル後にスケジュールされるため、実行が遅くなっても同じ監査が並行して実行されることはありません。
- 監査ページの今すぐ実行ボタンで即時実行をキューに入れられます。
モデルの選択
監査を作成する際に、オペレーターがエージェントサービス用に設定したモデルの一覧から調査に使用するモデルを選択できます。モデルが1つだけ設定されている場合はキャプションとして表示され、複数ある場合は選択できます。未設定の場合は設定済みのデフォルトが使用されます。通知
実行によって新しいフィンディングが見つかると、監査は組織に設定されたチャンネルに通知します。アラートパイプラインと同じalerts.enabled_channels ゲートと設定を使用します。
- Slack — 重要な（
big）新規アイテムの概要とディープリンク。 - Email — 新しい改善提案（重大度上位、各アイテムの推奨事項、ディープリンク）を一覧にした監査レポート。監査にemailチャンネルが設定されており、新規フィンディングが1件以上ある場合に送信される。
設定リファレンス
監査定義はダッシュボード（/audits/new）またはAPIで管理します。監査ごとの設定には、スケジュールの頻度とウィンドウ、スコープ（{"environments": [...], "agent_ids": [...]}）、感度（low / medium / high）、通知チャンネル、1実行あたりのフィンディング上限（top_k）、モデル（llm_budget.model 経由）が含まれます。オペレーターレベルのサーバー設定（タイムアウト、サンドボックス、エージェントサービスURL）は deployment.md に記載されています。
API
すべてのエンドポイントは組織スコープで、標準のベアラーキー認証を使用します（api-keys.md を参照）。| エンドポイント | 権限 | 目的 |
|---|---|---|
GET /audits · POST /audits | audits:read / audits:write | 監査定義の一覧取得 / 作成。 |
GET / PUT / DELETE /audits/:id | read / write / write | 監査の参照、編集、削除。 |
POST /audits/:id/run | audits:write | 監査を即時実行キューに入れる。 |
GET /audits/:id/runs | audits:read | 実行履歴（ウィンドウ、ステータス、統計、フィンディング数）。 |
GET /audits/findings | audits:read | 組織全体のフィンディング。audit_id、status でフィルタリング可能。優先度順にソート。 |
GET /audits/findings/:fid | audits:read | フィンディングの詳細（推奨事項、証拠、優先度）。 |
POST /audits/findings/:fid/status | audits:write | トリアージ：{"action": "ack" | "mute" | "dismiss" | "resolve" | "reopen" | "assign"}。 |