拒否優先のパーミッション評価とは、ツールを利用するエージェントのための安全上の姿勢であり、拒否ルールが常に許可ルールに優先し — 許可ルールのほうがより限定的である場合でさえそうであり — 明示的なルールに一致しないアクションはデフォルトで許可されるのではなく人間にエスカレーションされる。したがって、「すべてのシェルコマンドを拒否する」といった広い拒否は、「npm test を許可する」といった狭い許可によって覆されることがない。Dive into Claude Code：現在および将来の AI エージェントシステムの設計空間 はこれを Claude Code のデフォルトの安全上の姿勢と位置づけ、第二の原則である多層防御と組み合わせている。多層防御のもとでは、複数の独立した仕組みが並行して適用され、そのいずれもがアクションを阻止できる。
用法
同論文が分析したシステムでは、この手法は 7 つの独立した層として実現されており、リクエストは該当するすべての層を通過しなければならない。一律に拒否されたツールは、モデルが試みる前にモデルの視野から取り除かれる。拒否ルールは許可ルールより先に評価される。有効なパーミッションモードが、明示的なルールに一致しないものの基本的な扱いを決める。ML 分類器は、ルールシステムなら許可するリクエストを拒否することがある。承認されたシェルコマンドであっても、ファイルシステムとネットワークへのアクセスを制限するサンドボックス内で実行されることがある。セッション単位のパーミッションは、再開やフォークの際には復元されない。そしてフックが介入して判定を変更したり確定させたりできる。ルールはツールレベルとコンテンツレベルの両方で照合されるため、パターンはツール全体ではなく特定のコマンドプレフィックスを対象にできる。
拒否はハードストップではなくルーティングのシグナルとして扱われる。モデルはその理由を受け取り、アプローチを見直し、次の反復でより安全な代替策を試みる。そのため、強制は単にエージェントを停止させるのではなく、その振る舞いを方向づける。分析した論文は、この手法を、モデルは信頼されない一方で開発者のマシンは信頼されるという脅威モデルの表れとして提示している。また、この手法は人間に関する知見にも動機づけられている — 承認疲れ（Approval Fatigue） を参照。監督者が習慣的にプロンプトを承認している状況でも安全であり続けなければならないシステムは、その監督者の注意力に依存することはできないからである。
適用される場面
この手法は、推論と強制が別々のコードパスを占め、侵害されたり敵対的に操作されたりしたモデルがチェックを覆せないハーネスを前提とする。分析されたシステムでは、モデルが外界と接する唯一のインターフェースは構造化されたツール利用プロトコルであり、ハーネスは実行前にそれを検証する。これは取りうるいくつかの立場の一つにすぎない。同論文はこれを、個々の呼び出しを評価するのではなくエージェントの実行環境全体をサンドボックス化するコンテナベースの隔離や、変更を制限する代わりに元に戻せるようにするバージョン管理ベースのロールバックと対比している。そのトレードオフは、個々のアクションに対するきめ細かな制御と引き換えに単純さを失うことである。
その中心的な弱点は、著者ら自身が指摘している。多層防御は各層が独立に失敗するという前提に立っているが、性能上あるいは経済上の制約を共有する層は同時に劣化しうる。著者らが引用するセキュリティ研究によれば、50 を超えるサブコマンドを含むコマンドでは、サブコマンドごとの拒否ルールのチェックではなく、単一の汎用的な承認プロンプトにフォールバックしていた。サブコマンドごとの解析がインターフェースのフリーズを引き起こしていたためである。著者らはまた、層構造の描像では捉えられない時間的な隙間も報告している。対話的な信頼ダイアログが表示される前、プロジェクトの初期化中に実行されるコードは、評価パイプラインの外側に完全に置かれてしまう。したがって著者らは、問うべきは単一の層が回避されうるかどうかではなく、いくつの独立した層が同時に失敗しなければならないか、そしてそれらが失敗モードを共有しているかどうかだと論じている。ここでの説明は、単一のシステムの特定のバージョンを対象にした 1 件のソースコードレベルの研究に基づくものであり、エージェント間の測定に基づく比較によるものではない。
関連用語
承認疲れ（Approval Fatigue）、ガードレール、サンドボックス化、ヒューマン・イン・ザ・ループ、Claude Code