ポリシールール
AI ツールの振る舞いを制御する CEL ベースのポリシールールを作成・管理します。
ポリシー とは、Edison Watch がすべての AI ツール呼び出しに対してリアルタイムで評価するルールです。アクションのブロック、セッションへのタグ付け、アクセス制御レベルの設定などを、AI ツールの設定を変更することなく行えます。
Policies ビュー
サイドバーの Policies を開きます。ページは 2 つのパネルに分かれています。
- 左サイドバー - すべてのルールをステータスごとに分類した一覧と検索ボックス。
- 右パネル - 選択されたルールの詳細。
サイドバー上部のサマリーストリップには、enabled、tentative、disabled の各ルール数がひと目で分かるように表示されます。
ルールのステータス
| ステータス | 意味 |
|---|---|
| enabled | ルールはアクティブで、一致するすべてのツール呼び出しに適用されます。 |
| tentative | ルールは評価されますがログに記録されるだけで、アクションは適用されません。新しいルールを安全にテストするのに役立ちます。 |
| disabled | ルールは保存されていますが評価されません。 |
ルールのフェーズ
各ルールは 2 つのフェーズのいずれかで実行されます。
| フェーズ | 実行タイミング | ブロック動作 |
|---|---|---|
| pre | ツール呼び出しの実行前。 | 実行を防止します。 |
| post | ツール呼び出しの完了後。式の中でツールの result が利用できます。 | 呼び出しは既に実行されています - 結果は AI に返す前にエラーに置き換えられ、機密の出力の流出を防ぎます。 |
CEL 式のコンテキスト
ルールは CEL (Common Expression Language) で記述されます。式は、現在のツール呼び出しを表す 4 つのトップレベルオブジェクトに対して評価されます。
| 変数 | フィールド | 備考 |
|---|---|---|
principal | user_id、email、roles | 呼び出しを行うユーザー。roles はそのユーザーのカスタムロール名のリストです。 |
resource | type、name、server | 呼び出されている対象。type は "tool"、"resource"、または "prompt" です。 |
tool | args、input_schema、output_schema、result | result は post フェーズでのみ設定されます。 |
session | has_private_data_access、has_untrusted_content_exposure、has_external_communication、highest_acl_level、tool_history、tags | 現在のセッション状態。3 つの Lethal Trifecta フラグを含みます。 |
式が true に評価されると、ルールのアクションが適用されます。
アクション
| アクション | 効果 |
|---|---|
block | ツール呼び出しの実行を防止し、AI にエラーを返します。 |
mark_private | セッションにプライベートデータが含まれているとフラグを立てます。 |
mark_untrusted | セッションに信頼できない外部コンテンツが含まれているとフラグを立てます。 |
mark_write | セッションで書き込み操作が行われたとフラグを立てます。 |
set_acl | セッションの ACL レベル (PUBLIC、PRIVATE、SECRET) を設定します。 |
add_tag | フィルタリングや監査のために、セッションにキーと値のタグを追加します。 |
allow_override | 他のルールがブロックしても、呼び出しを明示的に許可します。 |
ルールのスコープ
ルールは特定のプリンシパルとリソースにスコープできます。
- プリンシパルスコープ - 全ユーザーをグローバルに対象にする、特定のロール、または特定のユーザーを対象にします。
- リソーススコープ - 特定のサーバー、要素タイプ (tools/resources/prompts)、または名前パターンを対象にします。
スコープを指定しないルールは、すべてのプリンシパルとリソースに適用されます。
優先度とオーバーライド
同じツール呼び出しに複数のルールが一致した場合、一致したすべてのルールのアクションが適用されます。優先度は block と allow_override の相互作用を決定します。
blockは、一致するallow_overrideルールが 同等以上 の優先度を持つ場合にのみキャンセルされます。- そうでなければ、ブロックが優先されます。
| 一致するルール | 優先度 | 結果 |
|---|---|---|
block + allow_override | 100 vs. 100 | ✅ 許可 (override ≥ block) |
block + allow_override | 100 vs. 99 | ❌ ブロック (override < block) |
block のみ | 任意 | ❌ ブロック |
ブロック以外のアクション (mark_*、set_acl、add_tag) は、ルールが一致するたびに適用され、この解決ルールの影響を受けません。
ポリシーの作成
- 左サイドバーの Create Policy をクリックします。
- テンプレートピッカーからテンプレートを選ぶか、ゼロから作成します。
- ルール名、CEL 式、フェーズ、優先度、アクション、スコープを入力します。
- ルールを保存します。
有効化する前のルールのテスト
ルールエディタには evaluate パネルがあり、合成コンテキスト - principal、resource、tool args、session フラグ - に対して CEL 式を実行できます(ルールを保存せずに)。これを使って、式が期待通りのケースに一致するか、どのアクションが発動するかを確認できます。
実際のトラフィックに対して緩やかにロールアウトするには、ステータス tentative でルールを保存します。一致はサーバー側で ⚠️ TENTATIVE match - would apply actions: ... のようにログに記録されます。現在、tentative ヒット用の専用ダッシュボードビューはないため、サーバーログまたは SIEM を確認してください。信頼できる段階になったらルールを enabled に昇格させます。
編集と削除
サイドバーでルールを選択し、詳細パネルで Edit または Delete をクリックします。