[検討] forbidden の扱い — 論文は priority 最高値、laarma は priority システム外の独立チェック

[y-nakata]

これは何か

forbidden（コンテキスト評価を要さない絶対禁止）を、決定エンジンの中でどう位置づけるかの思想差を検討する Issue。論文は forbidden を「非常に高い priority のルール」として同一 priority 空間の中で表現するが、laarma は denied_tools / privilege_scope を priority システムの外側の独立した事前チェックとして実装している（#112 Phase A の設計判断）。この差を将来見直すか、laarma の現行を正典として維持するかを検討する。

発端

Phase B の記法対照（docs/design/policy-match-notation.md）で、論文の Policy Structure 実例を確認したところ、forbidden が priority で表現されていた。論文の実例:

policy: block_drop_database
match:
  action.tool == "database"
  AND action.operation == "execute"
  AND action.params.query MATCHES "DROP\s+DATABASE"
decision: DENY
priority: 1000        # ← forbidden を priority 1000 として表現
reason: "Forbidden: DROP DATABASE"

一方、context-dependent deny の実例は priority: 100。つまり論文は forbidden も context-dependent も同じ priority 空間に置き、forbidden に非常に大きな値（1000）を与えることで「常に勝つ」を表現している。

これは laarma の #112 Phase A 実装と思想が異なる。laarma は:

• denied_tools（絶対禁止ツール）と privilege_scope（権限スコープ）を、rules の priority 解決の外側にある独立した事前チェックとして評価する。
• 根拠（policy_engine.py の設計コメント）: R3 / Table I の "Forbidden" 分類——コンテキスト評価が完全に無視される唯一の分類——に対応するため、priority システムの「内側の最高値」ではなく構造的に「priority システムの外側」に置く。数値 priority を持たないハードコードの事前チェックは、priority=MAXINT の StaticRule よりも誤設定の余地がなく、fail-closed な安全境界として監査しやすい。

論点（結論なし）

1. どちらが正しいのか、そもそも「正しさ」の問題なのか。 論文の priority 1000 方式と laarma の priority 外方式は、同じ「forbidden は常に勝つ」を別の構造で実現している。挙動は同じで、表現が違うだけとも言える。思想差を実装差として埋める必要があるのか、それとも laarma の選択を正典化して論文との差を記録するに留めるか。
2. laarma 方式の利点（現状の主張）の検証。 「priority 外の独立チェックの方が誤設定の余地がなく監査しやすい」は妥当か。論文方式（priority 1000）だと、うっかり priority 1001 のルールを書くと forbidden を上書きできてしまう危険がある——これが laarma が priority 外に出した理由。この利点は本物か。
3. 論文方式の利点。 forbidden を priority 空間に統一すると、記法が一つになり（全ルールが同じ構造）、公式ガイドや他実装との互換が取りやすい。laarma の「denied_tools は別構造・rules は別構造」という二重構造は、記法統一の観点では不利。
4. エコシステム互換（[検討] ポリシー match 記法を公式（aarm.dev）方式へ寄せるリファクタ #121 と接続）。 [検討] ポリシー match 記法を公式（aarm.dev）方式へ寄せるリファクタ #121（記法を公式方式へ寄せるか）と連動する。公式ガイドは priority も forbidden の扱いも明示していないため、論文が唯一の規範。記法全体を公式/論文に寄せるなら、forbidden の表現もこの論点に含まれる。

進め方

急がない。#112 Phase A で laarma は既に priority 外方式で動いており、実害は無い。本 Issue は「論文との思想差を記録し、将来見直すか否かを判断する」ための棚卸し。#121（記法リファクタ）を検討する際に、forbidden の表現もそこに含めて一緒に判断するのが効率的かもしれない（#121 とマージするか独立に扱うかも論点）。

関連

• 記法方針の土台: docs/design/policy-match-notation.md（三者対照。§5 で本差分を「別 Issue 送り」と記録）
• [検討] ポリシー match 記法を公式（aarm.dev）方式へ寄せるリファクタ #121（記法を公式方式へ寄せるリファクタ。forbidden の表現もそこに含まれうる）
• [実装] 決定層を (a, C) ポリシー評価エンジンに組み替える — LLM ベース IntentAlignment の除去（#94 後継） #112（Phase A で denied_tools / privilege_scope を priority 外の独立チェックとした設計判断）
• 論文解釈: docs/aarm/classification-and-policy-model.md（Table I の Forbidden 分類）
• 参照: AARM 論文 arXiv:2602.09433（Policy Structure 実例。forbidden = priority 1000 / context-dependent = priority 100）
• laarma_sdk/src/laarma/policy_engine.py（denied_tools / privilege_scope の priority 外事前チェック）