エージェントを「止められる」ようにする（続編）―― 権限制御は結局、3つしかない
0. 前回の反省
前回、権限制御レイヤーの実装パターンを4つに分けて紹介した。
- 最小権限設計
- 実行直前の機械的な認可（Pre-Action Authorization）
- スコープ付き・短命なトークン（Agentic IAM）
- キルスイッチ／サーキットブレーカー
書きながら気になっていたことがある。この4つ、粒度がバラバラなのだ。
「最小権限設計」は設計思想であって仕組みではない。「スコープ付きトークン」は「誰であるか（identity）」の仕組みであって「何をしていいか（authorization）」の仕組みとは本質的に別物だ。「キルスイッチ」は事前の制御ではなく事後の保険だ。
ちょうどこの点を、2026年3月に公開された論文 Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents（Uchibeke, arXiv:2603.20953）が驚くほどきれいに整理していた。今回はこの論文の枠組みを借りて、話を絞り込みたい。
1. 結局、独立したアーキテクチャは3つしかない
この論文は、エージェントの実行時安全性（runtime safety）を担うアーキテクチャを3種類に分類している。どれか一つで全部をカバーすることはできないというのが結論だ。
| Pre-Action Authorization（事前認可） | Sandboxed Execution（実行環境の隔離） | Model-Based Screening（モデルによる検閲） | |
|---|---|---|---|
| 働く場所 | 意思決定層（実行の"前"） | 実行環境（実行の"最中"） | モデル推論層（実行の"前"） |
| 仕組み | 宣言されたポリシーとの照合 | カーネル／ハイパーバイザーでの隔離 | 軽量モデルが意図を分類 |
| 未承認の行動そのものを防げるか | できる（意味レベルで） | 限定的（リソース／ネットワークレベルまで） | 確率的 |
| 被害範囲を封じ込められるか | できない | できる | できない |
| 行動ごとの監査証跡 | 残せる（暗号署名付き） | 部分的 | 残せない |
| ビジネスルールの強制（送金上限など） | できる | できない | 限定的 |
| ゼロデイ攻撃の封じ込め | できない | できる | できない |
| プロンプトインジェクション対策 | 効く（モデルが説得されてもポリシーが拒否） | 効かない（サンドボックス内で行動自体はできてしまう） | 確率的 |
| 代表例 | OAP, PCAS | NemoClaw, E2B, Modal, ceLLMate | Google ADK Safety, Safiron |
前回の4パターンのうち、「最小権限設計」と「実行直前の機械的認可」は実質的に同じ列（Pre-Action Authorization）に属し、「スコープ付きトークン」はこの3つのどれとも異なる**「誰であるか」を扱うレイヤー**（OAuth 2.0やSPIFFEと同じ位置づけ）だとわかる。「キルスイッチ」は、この3つが失敗した後の**事後評価（post-hoc evaluation）**という第4のレイヤーに近い。
つまり前回の4分類は、正確には「3つのアーキテクチャ」＋「アイデンティティ」＋「事後保険」が混ざっていたことになる。今回はこれを整理し直す。
2. なぜ「事前認可」と「サンドボックス」は違う仕事なのか
一番誤解しやすいのがここだ。「隔離された環境で動かしていれば安全」と思われがちだが、論文は具体例で反証している。
シナリオA：プロンプトインジェクションされたエージェントが /etc/passwd を読もうとする
- 事前認可（OAP）：パスポートの許可範囲にシステムファイルの読み取りが含まれていないため、実行前に拒否される。読み取りは一度も実行されない。
- サンドボックス：ファイルシステム制限によって
/etc/passwdへのアクセスはブロックされる。ただし読み取り"試行"自体は実行され、封じ込められるだけ。 - モデル検閲：プロンプトインジェクションの組み方次第で、フラグが立つかどうかは確率的。
シナリオB：サンドボックスのネットワーク許可範囲"内"で、1回の送金上限（$100）を超える$500の決済APIを叩こうとする
- 事前認可：金額が上限を超えているため拒否される。
- サンドボックス：ネットワーク的には許可された正当な呼び出しに見えるため、$500の決済がそのまま実行されてしまう。
- モデル検閲：正当なAPI呼び出しパターンにしか見えないため、フラグは立たない。
つまり、サンドボックスは「システムを壊されない」ことは守れるが、「業務ルールを破られない」ことは守れない。逆に事前認可は「業務ルール」は守れるが、システムレベルのゼロデイ攻撃は守れない。両方必要、というのが結論だ。
3. 実際どれくらい効くのか ―― 実データ
ここが前回と一番違うところで、この論文には実際の攻撃実験の数字が載っている。
APort社が運営する vault.aport.io という、AI銀行エージェントを騙して不正送金させようとする公開CTF（Capture The Flag）で、1,151セッション・4,437件の認可判定を集計した結果が公開されている。
- 緩いポリシー（Tier 1）のとき：ソーシャルエンジニアリングの成功率は 74.6%
- 厳格なポリシー（Tier 5、$5,000の賞金付き）のとき：879回の試行に対して成功率は 0%
興味深いのは、Tier 1でもモデル自体は25.6%のケースで「これは怪しい」と送金ツールの呼び出しを拒んでいたことだ。つまりモデルのアラインメントは無意味ではない。しかし、いったんツール呼び出しが生成されてしまえば、あとはポリシーエンジンが金額や送金先を機械的にチェックするかどうかが勝負を決めていた。「説得されたかどうか」ではなく「ポリシーが許すかどうか」で結果が決まる、という前回書いた内容が、数字で裏付けられた形だ。
レイテンシも実測されていて、クラウドAPI経由の認可判定は中央値53ミリ秒（p99でも77ミリ秒未満）。ツール実行自体が数百ミリ秒〜数秒かかることを考えれば、実用上のボトルネックにはならない水準だとされている。
4. 業界の現状を示す、いくつかの厳しい数字
この論文が引用している業界調査の数字も、前回の「みんな手探り」という話を補強する材料になる。
- エンジニアリングチームの 27.2% が、フレームワーク提供の認可の仕組みを諦めて、独自のハードコードされたロジックに戻っている
- 492以上のMCPサーバーが、認証も暗号化もない状態で本番運用されていることが確認されている
- 政府機関の 90% が、AIエージェントに対する目的拘束（purpose-binding、「この権限は"この目的のためだけ"に使ってよい」という制約）の仕組みを持っていない
これは前回紹介したNISTの概念文書のドラフトが2026年2月に出たばかりという話とも符合する。標準が追いつく前に、現場は穴だらけのまま本番投入しているというのが実態のようだ。
5. では実務では何を選べばいいのか
論文の結論はシンプルで、**「本番でお金・データ・コードを扱うエージェントには、事前認可とサンドボックスの両方が最低限必要」**としている。モデルのアラインメントだけ、あるいはサンドボックスだけでは構造的な穴が残る。
これを前回のリスク別の表と重ねると、以下のように整理できる。
| リスクの種類 | 主に効く層 | 理由 |
|---|---|---|
| 出力に不適切な発言が混じる | モデル検閲（コンテンツガードレール） | 内容の問題は内容を見る層でしか防げない |
| ツールが想定外のパラメータで叩かれる（送金額超過など） | 事前認可（Pre-Action Authorization） | 意味レベルのビジネスルールはポリシーエンジンでしか強制できない |
| システムそのものを壊される／情報を持ち出される | サンドボックス（隔離実行） | ゼロデイや想定外の経路はカーネルレベルでしか封じ込められない |
| 上記すべてをすり抜けた／暴走した | 事後評価＋キルスイッチ | 最後の砦として、異常検知後に強制停止する |
4層構造として並べると、こうなる。
(1) モデルのアラインメント ← 訓練時、確率的
↓
(2) 事前認可（Pre-Action Authorization） ← 実行直前、決定論的
↓
(3) サンドボックス実行 ← 実行中、被害範囲を封じ込め
↓
(4) 事後評価 / キルスイッチ ← 実行後、パターンを見つけてフィードバック論文はこの4層のどれか一つでも欠けると「構造的な穴」が残ると明言している。アラインメントだけでは確率的な防御にしかならず、認可なきサンドボックスは"許可された範囲内での悪用"を防げず、サンドボックスなき認可はゼロデイに弱く、実行時強制のない事後評価は被害が出た後にしか気づけない。
6. 結論：「4パターンのどれを選ぶか」ではなく「4層のどこが薄いか」を見る
前回の記事は「4つのパターンから選ぶ」という書き方をしてしまったが、正確には選択の問題ではなく、積み重ねの問題だった。
- コンテンツを検閲する層（モデル検閲）
- 行動そのものを許可・拒否する層（事前認可）
- 許可された行動の被害範囲を封じ込める層（サンドボックス）
- すり抜けたものを事後に見つけて止める層（事後評価・キルスイッチ）
この4つは競合する選択肢ではなく、重ねて初めて機能する4枚のフィルタだ。自社のエージェントを点検するときの問いは「どのパターンを採用するか」ではなく、「この4層のうち、今どこが素通しになっているか」であるべきだった。
最後に、前回・前々回と同じ形で、問いを残しておきたい。
あなたのエージェントは、今のところどの層で守られていますか？ そして、まだ何も守っていない層はどこですか？
参考
- Uchibeke, U. (2026). Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents. arXiv:2603.20953. (Open Agent Passport / OAP)
- Palumbo, N. et al. (2026). Policy Compiler for Secure Agentic Systems (PCAS). arXiv:2602.16708.
- NVIDIA. NemoClaw: Enterprise security for OpenClaw agents. GTC 2026.
- Meng, L., Fernandes, E. et al. (2026). ceLLMate: Sandboxing browser AI agents. arXiv:2512.12594v2.
- Microsoft Security Blog (2026). From runtime risk to real-time defense: Securing AI agents (Microsoft Defender for AI Agents).