headless CLI エージェントへ許可ツールリストを渡しても、行動制約の保証にはならない。実測で確認した落とし穴が2つある。(1) CLI フラグの許可リストは実行環境のグローバル設定の許可ルールと合成され、フラグ指定外でも設定側で許可済みのコマンド（閲覧系など）は実行される。(2) 許可外の呼び出しの拒否は個別のツール呼び出し単位で起き、実行全体は中断されない — モデルは拒否のたびに別の抜け道を試み続け、最終的に正常終了する。さらにモデルの自己申告は実行の証拠にならない（「検証コマンドを実行した」と報告しながらログ上は全件拒否されていたハルシネーションを実測）。

判断基準

• 逸脱判定の正はイベントログ（ツール呼び出しと拒否が記録される構造化ストリーム出力。多くの CLI にイベントを JSON 行で出すオプションがある）に置く。ログに裏づけの無い実行の自己申告は逸脱として扱わない。逸脱記録が改善ループの入力になる運用では、これが偽データの混入を絶つ。
• 禁止事項のプロンプト明文化は撤去しない。位置づけは「保証」ではなく「拒否リトライによる時間浪費の回避策」に変わる。事前設定・プロンプト・事後ログ判定の三層で、保証を担うのは最後のログ判定だけ。

検知器のチューニング（偽陽性を優先して殺す）

• 違反判定は害のあるクラス（検証・変更系コマンドの実行）の denylist 一致に限定する。閲覧系コマンドの実行は情報列挙、拒否済みの試行は正常動作として分離し、違反にしない。許可リスト方式は「環境のグローバル許可で実行される正常な閲覧」を毎回違反と誤判定し、検知結果を受け取る改善ループに偽の摩擦記録を量産する。
• コマンド文字列の分割照合（複数コマンド連結・パイプ）はクォートとエスケープに対応させる。引数内の区切り文字やパターン文字列（検索ツールへ渡す正規表現、判定器自身へ渡す denylist 文字列）で誤分割が起き、初回実運用ログでは違反判定16件が全件偽陽性だった。

検証

• canary: 禁止コマンドの実行を明示要求するプロンプトを1回流し、イベントログ上で「拒否されたか・実行されたか」を確認して強制力の実態を確定する。ドキュメントの記述（全体が中断される等）を鵜呑みにせず実測する。
• 実ログ検証: 合成検体だけでなく、本物の実行ログ1本を判定器に通して偽陽性ゼロを確認してから運用に載せる。合成検体は作者の想定内の入力しか含まず、実ログ特有のコマンド形（シェルラッパー越し・長い引数・パターン文字列）を踏まない。