エージェントにプロンプトで頼むのはもう限界——推論の外側で権限を封じる「OBPE」の設計と実測効果

はじめに：エージェントは「天使」ではない

「もし天使が人間を統治するなら、政府の内外の統制は不要だろう」——フェデラリスト論文No.51の一節です。権力には外部の制約が必要だという政治哲学の比喩を、AIエージェントの権限問題に当てはめたのが本論文のタイトルです。エージェントは天使ではない、だから外部の統制が必要だ、という主張がそのまま設計思想になっています。

問題の核心は、エージェントに人間の認証情報（クレデンシャル）を与えると「到達範囲（reach）」は継承されるのに、その使い方を制限する「判断力（judgment）」は継承されないことです。たとえば「1つのプロジェクトの課題を要約してほしい」だけの依頼で、サービスアカウントが読める全課題がモデルコンテキストに流し込まれます。バックエンドから見れば2つのプロジェクト読み出しはどちらも「有効な操作」ですが、組織から見れば片方だけが「業務に属する」操作です。既存の認可は後者の区別に答えてくれません。

さらに、返ってきたデータはそのまま次の推論状態になります。テキストが次のツール呼び出しを選択するため、データに埋め込まれた命令（間接プロンプトインジェクション）がエージェントを操る経路になります。論文の実測では、プロンプトに6つのルールを追加しても文脈露出は55.1%→52.1%とほぼ変わりません。最終回答を「隠す」ことはできても、見てしまった・実行してしまった事実は変わらないのです。

本記事では「OBPE（Out-of-Band Policy Enforcement）とは何か」「なぜ必要なのか」「どう使えるのか」を、設計思想と実測データの両面から解説します。想定する読者は、業務システムにLLMエージェントを組み込むバックエンド／セキュリティエンジニアです。

なぜプロンプトは脆いガードレールなのか

プロンプトによる制限が脆い最大の理由は、LLMがデータと命令を確実には区別できないことです（Greshake et al., 2023）。「要約して」と頼んだWebページに「秘密データを取得して送信せよ」と書かれていれば、エージェントはそれを指示と受け取って従ってしまう可能性があります。指示とデータが同じトークン列で表現される以上、この区別は構造的に困難です。

なぜこれが実害になるかは、Simon Willisonが「致死の三要素（lethal trifecta）」と呼んだ条件で整理できます。①プライベートデータへのアクセス、②信頼できないコンテンツへの露出、③外部通信能力——この3つが揃うと、エージェントは悪意ある指示でデータを盗み出す経路になります。M365 CopilotやGitHub MCPなどでも実エクスプロイト事例が報告されています。

さらに、テキスト拒否とツール呼び出しの安全は別物です（Mind the GAP, arXiv:2602.16943）。文章で「拒否します」と答えられる能力は、禁止されたツールの実行を止める能力と相関しません。プロンプトの指示は「同じ推論器」に自分自身の制限を守らせることになり、確率的な振る舞いに依存したガードレールにすぎません。

既存の守り方にも穴があります。バックエンド認可（OAuth等）は「クレデンシャルが何をできるか」には答えますが、「このエージェントがこのタスクで何をすべきか」には答えません。OAuthスコープ・RAR・トークン交換で絞り込むには、認可サービスが「その割り当て」を知っている前提が必要で、実際に供与されるクレデンシャルは広いままです。論文の数字では、プロンプト追加で最終回答の完全一致漏えいは27.5%→3.7%に下がるものの、文脈露出は55.1%→52.1%、禁止バックエンド効果は8.1%→5.5%とほぼ不変でした。露出と実行は、プロンプトではほとんど減らせないのです。

欠けている制御点は「交換（exchange）」の場、すなわち操作がバックエンドに届く前、かつレスポンスがモデルコンテキストに入る前の境界です。ここに外部の強制機構を置く——それがOBPEの発想の出発点になります。

OBPEとは何か：推論の外側に置く「信頼できる境界」

OBPE（Out-of-Band Policy Enforcement）とは、エージェントのツールクライアントとバックエンドの間に置かれ、モデルの推論の外側（Out-of-Band）で動作するポリシー強制境界です。通常のガードレールが「プロンプトでモデルに制限を守らせる」のに対し、OBPEは「モデルが触れられない場所に制限を実装する」点が決定的に異なります。

この境界が「信頼できる」ためには、どこまでを信頼し、どこからを信頼しないかを明確に区切る必要があります。OBPEの前提では、プラットフォーム・プロキシ・コネクタ・データポリシーオーナー・バックエンドを信頼し、モデル・プロンプト・ツールが返すテキスト・エージェント作成時の引数はすべて「不信頼」とみなします。エージェントに渡るのは整形済みの結果だけであり、生のレスポンスは一度もモデルコンテキストに入りません。

設計の根幹はSaltzer & Schroeder（1975）の完全媒介（complete mediation）です。関連する全リクエストと全レスポンスが必ず境界を通ることを要求し、ツールを「非表示にする」だけでは不十分とします。呼び出し可能なツールは、実行経路そのもので強制しなければなりません。さらにアイデンティティバインディングにより、プラットフォームがエージェントの身元を（エージェント制御外の形で）ツール呼び出しに紐付け、適用するポリシーを選択します。エージェントは自分のポリシーを選べず、狭い束縛を捨ててオーナーの上限に逃げることもできません。

OBPEの責務は次の3つに整理されます。

バックエンドのクレデンシャルは境界の背後に置かれ、境界は「型付き交換」だけを扱います。自由文の最終プローズや任意テキストからの意味復元は対象外と明記されており、扱える操作を最初から構造化された形に限定することで、強制の範囲を検証可能にしています。

sequenceDiagram
    participant A as LLMエージェント
    participant G as OBPEゲートウェイ
    participant B as バックエンド
    A->>G: ツール呼び出し（型付きオブジェクト）
    alt permit（許可）
        G->>G: リクエスト整形
        G->>B: 整形済みリクエスト
        B-->>G: レスポンス
        G->>G: レスポンス整形
        G-->>A: 整形済み結果のみ
    else defer（保留）
        G-->>A: 保留中（承認待ち）
    else deny（拒否）
        G-->>A: 不透明な失敗
    end

アーキテクチャ：ゲート→リクエスト整形→レスポンス整形の3段階

OBPEは、ツールクライアントとバックエンドの間のすべての通信を、ゲート（Gate）→リクエスト整形（Request shaping）→レスポンス整形（Response shaping）の3段階で処理します。各段階の責務を順にみていきます。

コネクタ：生のツール通信を型付きオブジェクトに変換

コネクタは、生のツール呼び出しをprincipal（誰が）／action（何を）／resource（どの対象に）／records（どのレコード群）／fields（どのフィールド）の型付きオブジェクトへマッピングします。「この課題を更新する」「この顧客レコードを返す」といった意味を与えることで、後段のポリシー判定が可能になります。マッピングが呼び出し面やポリシー関連フィールドを欠く場合、その経路はモデルの対象外としてdenyするか、別途ガバナンス対象にします。

現実の課題は、ツール側に構造化された出力定義がないことです。MCPは2025年6月の仕様改訂までツール出力スキーマを持たず、2026年の測定では1,856ツール中わずか234しか出力スキーマを宣言していません。既存サーバーを使う場合は、スキーマ宣言の追加か、実際の返却と一致するミドルウェアが必要になります。

ゲート：deny < defer < permit

ゲートはデフォルトdenyから始まり、マッチするオーナールールだけがpermit（許可）の資格を作ります。deny・defer・permitの優先順位は次のとおりです。

deferではスナップショットを保持して外部の承認チャネルに委ね、エージェントは承認チャネルを読めず偽造もできません。タイムアウトするとdenyに失効します。セマンティックゲーティングの例としては、Critical課題の更新をオンコールリードの承認待ちにする、時間外の操作を保留する、累積制限を超える一連の操作を拒否する、といったものが挙げられます。エージェントにはポリシー名や内部理由は見せず、denyは「不透明な失敗」、deferは「保留中」とだけ見えます。

リクエスト整形

リクエスト整形は、上流クエリを狭めるクエリ絞り込み（pushdown）、レコード数の上限（cap）、書き込み引数のクランプを行います。クエリ結合は常にconjunction（論理積）として扱われ、コネクタがそれを確立できない場合はdispatch前にdeny（フェイルクローズ）します。書き込みでは、absence-safe（省略しても保存値が変わらない）と宣言されたフィールドのみ削除を許可し、クランプは制限方向をスキーマで宣言します。デフォルト値の注入は禁止です。上限はフェッチ後にも再チェックされ、バックエンドが上限を無視しても守られます。

レスポンス整形

レスポンス整形は、行フィルタリング（オーナー条件∧エージェント条件）→フィールド除去→マスキング→エンベロープ浄化の順で実行され、エンベロープ浄化は最後に固定実行されます。構造的除去（strip）と完全リダクションだけが「その値がレスポンスに存在しない」ことを保証し、パターンマスクはベストエフォートです。カウント・カーソル・エラー・ランキング・タイミングも情報チャネルになり得るため、コネクタはこれらを整形するか、呼び出しをdenyするか、残存チャネルを文書化します。

flowchart LR
    A[ツール呼び出し] --> B[コネクタ<br>型付きオブジェクト化]
    B --> C[ゲート<br>deny / defer / permit]
    C -->|permit| D[リクエスト整形<br>pushdown / cap / clamp]
    D --> E[バックエンド]
    E --> F[レスポンス整形<br>filter / strip / mask]
    F --> G[整形済み結果のみ<br>エージェントへ]
    C -->|deny| H[不透明な失敗]
    C -->|defer| I[外部承認チャネル]

エージェントに渡るのは整形済みの結果のみで、生のレスポンスは一度もモデルコンテキストに入りません。この「交換の場」での強制が、プロンプト依存のガードレールとの決定的な違いです。

二層ポリシーモデル：オーナーが上限、エージェントは狭めるだけ

OBPEのポリシーは「オーナーポリシー」と「エージェントポリシー」の二層で構成されます。データポリシーオーナー（データ源の責任者）はオーナーポリシーで最大許可（ceiling）を設定し、permitの資格を作れるのはこのオーナー階層だけです。エージェントポリシーは、登録されたエージェントごとにオーナーの許可を「狭める」ことしかできません。エージェントビルダーはエージェントをより無能にすることはできますが、オーナーが与えなかった権限を回復することはできません。

flowchart LR
    subgraph Owner["オーナーポリシーの上限（ceiling）"]
        A["読み取り: 全課題"]
        B["書き込み: 担当課題のみ"]
    end
    subgraph Agent["エージェントポリシー（狭めるだけ）"]
        C["読み取り: 自チームの課題のみ・100件まで"]
        D["フィールド: summary のみ"]
    end
    Owner --> Agent

この二層モデルは3つの命題として形式化されています（前提O1–O5の下で）。命題1（置換不変性）は、マッチしたルールの順序を変えてもポリシープランは不変であることを保証します。これはmeet演算の可換性・結合性・冪等性によるものです。命題2（単調性）は、整形式の段階的制限を追加しても、プランの実行可能範囲・クエリ述語・保持フィールド・書き込み可能フィールドが広がらないことを示します。命題3（階層精緻化）は、エージェントポリシー付きのプランがオーナーのみのプラン以下（Π(S, A) ⪯ Π(S)）であることを主張し、エージェントが天井を広げられないことを保証します。

前提O1–O5は、①束縛IDと完全媒介、②固定されたポリシー入力とデフォルトdeny、③安定したステージ意味論（クエリは論理積、キャップは後フェッチ強制など）、④安全な書き込み方向、⑤信頼できる状態と保留コールの扱い、の5つです。なお、同一階層内でのpermit追加は「認可変更」であり段階的制限ではないため、単調性の適用外とされます。

実装言語にはCedar（AWS製の型付き認可言語）のpermit/forbidコアが使われ、OBPEアノテーション（@transform, @field_group, @cap_limit, @approver, @defer_timeout など）で形状化・ゲーティングを指定します。たとえばJiraの課題リストを「チーム述語＋100件キャップ＋summaryフィールド群」に絞るエージェントポリシーと、機密フィールドを除去しHighest課題の更新をdeferするオーナーポリシーの組み合わせは、「狭める」合成の具体的なイメージです。オーナーが上限を握り、エージェント側はその範囲内でしか動けない——この単方向性が、ポリシー設計の安全性の根幹です。

実装：公開されたHTTPプロキシとCedarコア

本論文の評価に使われた実装は、本番OBPE実装を簡略化した公開HTTPプロキシと、Jira／ServiceNowの制御モック、適合性（conformance）テストから構成されています。このリリース物が論文の主張の証拠であり、本番構成の説明は「設計の説明」であって評価証拠ではありません。

flowchart LR
    subgraph Release[公開リリース物]
        P[HTTPプロキシ<br>Cedarポリシーコア]
        C1[Jiraコネクタ<br>スキーマ]
        C2[ServiceNowコネクタ<br>スキーマ]
        M[Jira/ServiceNow<br>制御モック]
        T[適合性テスト<br>25義務・352セル]
        CP[コーパス]
    end
    P --> C1 --> M
    P --> C2 --> M
    T --> P
    CP --> T

適合性テストは「コードとモデルの対応」を担保します。25の義務・352セルで、全20の非等価ステージ変異と全3のフルパイプライン変異を検出できる設計です。ポリシープランが形式化した通りに実行されない場合、このテストがズレを検出します。

本番構成ではMCPレイヤにOBPEを配置し、リモートA2Aエージェントに対応します。スキーマはセキュリティ状態として扱われ、フィールドグループ・感度ラベル・absence-safe宣言がポリシーの語彙を定義します。リリース物のJira／ServiceNowマッピングは公開インターフェースからの手書きです。

静的解析の境界にも注意が必要です。Cedar Analysisはpermit/forbidコアの矛盾・非効果ルール・完全拒否を検出できますが、OBPEアノテーションや「組織の意図」は検証できません。relational noninterference（関係的非干渉性）の証明は未達であり、評価範囲外と明記されています。書き込み制御の全体像、永続的な人間承認、時系列ポリシー、集約ポリシーは本番専用の設計であり、リリース物では評価されていません。

評価：3,621試行で「57.6%→0.2%」をどう読むか

評価設計：71タスク・4モデル・3反復のペア比較

評価はJira/ServiceNowの制御モック上で実施され、71タスク・35シナリオクラスタ・4モデル（Claude Sonnet 4.6／Claude Haiku 4.5／GPT-5／GPT-5 mini）を各3反復して計3,621試行です。各試行はフレッシュなフィクスチャで初期化され、同一タスクを「プロンプトのみ」と「+OBPE」の両構成で実行するペア比較になっています。

主結果：決定的トレース失敗 57.6%→0.2%

主アウトカムの「決定的トレース失敗」は、①保護データがモデルコンテキストに入る、②最終回答に保護値が完全一致で出現する、③禁止されたバックエンド効果が完了する、のいずれかと定義されます。この割合は57.6%→0.2%に低下し、クラスタ加重ペア推定で41.2pp削減（95%信頼区間[27.7, 54.9]）。全モデルでOBPEが優位（32.4〜49.3pp）でした。

達成率低下は「仕様通り」：safe-usefulで逆転

素のタスク達成率（fulfillment）は79.1%→60.9%に下がります。これはOBPEが「すべきでない仕事」も止めた副作用で、deny 10件・defer 2件が達成不可能と判定されたためです。一方、安全かつ有用な完了（safe-useful）は22.0%→58.9%（Judge A、ペア時+21.8pp [9.5, 35.2]）、Judge Bでも54.4%（+19.1pp）と逆転します。ベースラインの「達成」の多くは、保護データに触れた不安全な完了だったことになります。

xychart-beta
    title "主指標の比較（%）"
    x-axis ["トレース失敗", "fulfillment", "safe-useful"]
    y-axis "割合（%）" 0 --> 90
    bar [57.6, 79.1, 22.0]
    bar [0.2, 60.9, 58.9]

レッドチーム・アブレーション・レビュアー比較

20タスクへの応答適応型多ターン攻撃（Claude Opus 4.7、15ターン上限）ではトレース失敗が74.9%→0.9%に低下しました。保護機構の寄与を分解したアブレーションでは、レイヤ追加ごとに保護率が46.7%→69.4%→88.6%→100.0%と積み上がり、safe-usefulも21.8%→63.0%へ改善しています。

LLMによる事後レビュー（RQ3）との比較では、レビュアーはツール実行後にしか介入できず、トレース失敗58.6%・safe-useful 19.7%・追加モデル呼び出し930回。OBPEは0.0%・63.0%・追加呼び出しゼロで、タイミングの差が結果を分けています。頑健性も確認済みで、39試行の未完了を最悪ケースで割り当てても41.2pp→33.8〜43.1pp、1クラスタ除去で39.4〜42.4pp、モックの欠陥（116試行）除外後も40.5ppと結論は変わりません。

数字の読み方

「57.6%→0.2%」は、プロンプトでは止められなかった「コンテキストへの露出」「完全一致漏えい」「禁止効果の実行」の3経路を構造的に封じた結果です。達成率の低下を性能劣化と読むのは誤りで、安全の条件を加えると逆転すること——この点が本手法の評価の核心です。

OBPEが閉じなかった4つの穴：境界の先にある残存リスク

OBPEはトレース失敗を57.6%→0.2%に抑えましたが、境界の外にはまだ4つの穴が残ります。まず「再構成攻撃」です。1,065試行中4件で、最終回答に保護メールが完全一致で出現しました。値は一度もコンテキストに入っていないのに、可視の名前とドメイン規則から復元されたケースです。「言わない」と説明しながら漏らす事例もあり、これはプロキシの脱出ではなく「推論チャネル」の存在を示します。

次に「行数オラクル」です。マスクしたメールフィールドへの述語クエリで行数を観測し、@partner→2件、yara→1件、singh→1件と絞り込んで個体を特定した事例です。これは統計データベースのtracker問題（Denning et al., 1979）の現代版であり、決定的トレースの定義では失敗として検出されません。

3つ目は、「単一実行の整形」と「非干渉性」の違いです。構造的除去は「その値がその実行に存在しない」ことだけを保証し、「その値が他の観測可能な挙動に影響しなかった」ことは保証しません。relational noninterference（Clarkson & Schneider）は別途の証明が必要です。

4つ目は評価範囲外の領域です。書き込み制御の全体像、永続的な人間承認（ターミナルタイムアウト・承認後ディスパッチは未実装）、時系列・集約ポリシーは設計のみです。ストリーミングレスポンスやMCPのresource／prompt／sampling面も対象外です。

これらの示唆は明確です。露出制御と推論防止は別レイヤの防御が必要であり、粗いカウント・最小コホート・履歴対応のクエリ予算などの対策は本論文では未評価です。境界は強力ですが、境界だけですべてが閉じるわけではありません。

なぜ今重要なのか：エージェントセキュリティの「パラダイムシフト」

従来のエージェント防御は三層の地図で捉えられる。認可基盤（Zanzibarの関係型認可、OAuth RAR・トークン交換、IAM permission boundaries）はクレデンシャルの到達範囲を狭め、データ層（PostgreSQLの行セキュリティ、クエリ書き換え、Envoy ext_proc）はデータやHTTPトラフィックを制約し、モデル層防御（CaMeLの制御/データフロー分離、ProgentのSMTによる単調封じ込め、PAuthのタスクスコープ認可、出力レビュアー）は推論器を守る・監視する。だが、いずれも「このエージェントがこのタスクで何をすべきか」を交換の瞬間に強制する仕組みではない。

OBPEの位置づけは、これらの「置き換え」ではなく、それらを束ねる「交換の場の契約」にある。オーナー上限＋エージェント制限の二層合成と、順序非依存・非拡大の条件を形式化した点が新規性だ。論文の比較表によれば、Envoy ext_procはエージェント非アクセスを備える一方でリソース認識は部分対応、Progent/CaMeL/PAuthは境界整形や外部ゲートが部分対応に留まり、OBPEのリリース物は「エージェント非アクセス・決定的・リソース認識・境界整形・外部ゲート」のすべてを備える。

産業への含意も顕在化している。Redpanda Agentic Data PlaneはMCP/A2A/OTel対応、OIDCアイデンティティ、OBO認可、不変監査ログを備えて同思想を製品化しており、MCPエコシステムのガバナンス標準化の流れにつながる。

本質は「エージェントは確率的であり、認証情報は本質的に広い」という構造にある。モデルがいくら賢くなっても境界は必要で、モデル改良と境界整備は直交する投資となる。エージェント時代のセキュリティは、モデルを信頼するかではなく、交換の場に信頼できる境界を設計できるかにかかっている。

どう使えるか：導入を検討するエンジニアへの実務ガイド

OBPEを導入する際に最初に理解すべき原則は「スキーマはセキュリティ状態である」ことです。境界はツール呼び出しを型付きオブジェクト（操作・リソース・レコード・フィールド）に変換してからポリシーを判定するため、このマッピングが実装とズレていれば、どんなに厳しいポリシーも意味を持ちません。導入時は名前付きオーナーを決め、ポリシーとスキーマを同時にロールアウトし、ロールバック手順と変更レビューを用意します。

導入の5ステップ

1. ツール面の監査：既存のツールがどの型付き操作・リソース・フィールドにマップされるかを一覧化する
2. オーナーポリシーの天井設定：データ源の責任者が最大許可（ceiling）を定義する
3. エージェントポリシーの絞り込み：タスクごとにスコープ・キャップ数・保持フィールドを狭める
4. 適合性テスト：ポリシープランと実コードの対応を検証する
5. 監査ログ設計：承認・拒否・変換を記録する（機密値をログに複製しない）

flowchart LR
    A[ツール面の監査] --> B[オーナーポリシー<br>天井設定]
    B --> C[エージェントポリシー<br>絞り込み]
    C --> D[適合性テスト]
    D --> E[監査ログ設計]

MCPサーバーを選ぶ・自作するときの3条件

MCPサーバーを選ぶ・作る場合は、①出力スキーマ（outputSchema）を宣言している、②機密フィールドをレスポンスに出さない、③入力を有限の許可リストで制限できる、の3点を満たすものを選びます。2026年の測定では1,856ツール中234しか出力スキーマを宣言しておらず、この有無が現実的な選定基準になります。

導入前に認識しておく制約

ポリシーオーナーの「組織的意図」が正しいかは静的解析では検証できず、天井の設定は人間の責任です。フィルタ済みビューを「全体」と誤認させるなど、整形がエージェントを誤導することもあります。監査・承認ログは労働者の活動を記録するため、アクセス制限・保持期間・雇用判断への不使用などの倫理面の設計が必要です。承認量の増加は承認疲れ（approver fatigue）でdeferが形骸化するサインなので、ポリシー見直しのトリガーにします。

小規模環境での試し方

ホームラボや検証環境では、論文とともに公開されたHTTPプロキシと制御モックを使えば、モデル呼び出しなしで適合性テストと基本ベンチマークを再現できます。まずdeny・defer・permitの合成挙動を体感し、その上で本番のコネクタマッピングを追加するのが現実的な進め方です。

よくある質問

OBPEはプロンプトインジェクション攻撃を完全に防げるのですか？

いいえ。「値がコンテキストに入らない」「禁止効果が実行されない」ことは構造的に保証できますが、可視情報から値を再構成する推論チャネル（1,065試行中4件）や行数オラクル（1件）は残ります。論文も「単一実行の整形は非干渉性ではない」と明言しており、完全な防御ではなく「決定的な漏えい経路を封じる」仕組みと理解するのが正確です。

OBPEは既存の認可基盤（OAuthやIAM）の代わりになるのですか？

いいえ。OAuthスコープやIAM permission boundariesは「クレデンシャルの到達範囲」を狭める仕組みで、OBPEはその前提の上に「このエージェントがこのタスクで何をすべきか」の交換時強制を追加します。論文も「OBPEはこれらの仕組みを置き換えない」と述べており、認可基盤と併用して初めて機能します。

出力レビュアー（LLMによる事後チェック）とOBPEはどちらが優れているのですか？

タイミングが本質的に異なります。レビュアーはツール実行後にしか見られず、すでにコンテキストに入ったデータや実行済みのバックエンド効果は取り消せません（実測でトレース失敗58.6%、追加モデル呼び出し930回）。OBPEは送信前・返却前に強制し、実測でトレース失敗0.0%、追加呼び出しゼロでした。事後チェックは補助的な監視として位置づけるのが現実的です。

オープンソースで試せますか？

はい。論文は匿名アーティファクトとしてHTTPプロキシ・モック・コネクタスキーマ・ポリシーバンドル・適合性テスト・コーパスを公開しています（usenixsecurity_2027_obpe）。READMEの手順に従えば、モデル認証情報なしで全表を再生成できます。

本番導入の際に必要なものは何ですか？

①ツールと型付きオブジェクトの完全なコネクタマッピング（出力スキーマの宣言を含む）、②オーナーポリシーの天井設定とスキーマの変更管理、③アイデンティティバインディングと完全媒介、④監査ログと承認チャネルの設計、の4点が必要です。書き込み制御・永続承認・時系列ポリシーは本論文のリリース物では未評価なので、本番適用前に個別の検証が必要です。

まとめ

エージェントに認証情報を渡すだけの運用は、もはや安全とは言えない。プロンプトへの指示追加は、同じ推論器に自分自身の制限を守らせる「脆いガードレール」にすぎず、実測でも文脈露出は55.1%→52.1%、禁止されたバックエンド効果は8.1%→5.5%とほぼ不変だった。「見せないで」「実行しないで」と頼むだけでは、見てしまった事実も実行してしまった影響も変わらない。

OBPE（Out-of-Band Policy Enforcement）は、モデルの推論の外側に置く信頼できる境界である。ツールクライアントとバックエンドの間の「交換」を型付き操作として媒介し、データポリシーオーナーが設定する上限（ceiling）の下で、エージェントポリシーは許可を狭めることしかできない。この二層合成が順序非依存・非拡大であることを形式化し、適合性テストでコードとモデルの対応まで検証した点が新規性の中核だ。

実測の効果は明確である。3,621試行でトレース失敗は41.2pp削減（57.6%→0.2%、95%信頼区間[27.7, 54.9]）、安全かつ有用に完了するsafe-usefulは22.0%→58.9%（+21.8pp）に向上し、追加のモデル呼び出しはゼロだった。応答適応型の多ターン攻撃（レッドチーム20タスク）でも74.9%→0.9%に抑えている。

ただし、境界の外にはまだ穴が残る。可視情報から値を復元する再構成攻撃や、行数を観測して個体を特定する行数オラクルといった推論チャネルは閉じられておらず、書き込み制御・永続承認・時系列ポリシーは未評価である。「単一実行の整形」と「非干渉性」の間には、依然として距離がある。

エージェント時代のセキュリティは「モデルを信じない」ことから始まる。モデル改良と並行して、交換の場に信頼できる境界を設計し、誰が何を上限とするかを明文化することが、本番運用の前提になるだろう。

参考ソース

• Marc Millstone, Tyler Akidau, Johannes Brüderl, Marat Pekker, "If Agents Were Angels, No Governance Would Be Necessary: Out-of-Band Policy Enforcement at a Trusted Tool Boundary", arXiv:2608.27646（2026年8月27日投稿） — https://arxiv.org/abs/2608.27646
• 同論文 全文HTML版 — https://arxiv.org/html/2608.27646v1
• Agentic AI needs governance it can't ignore（Redpanda, 2026年8月3日） — https://www.redpanda.com/blog/agentic-data-plane
• Mind the GAP, arXiv:2602.16943 — https://arxiv.org/abs/2602.16943

関連記事

• AIエージェントの安全を実行時に担保する「Aegis」— モデルは提案し、ランタイムが判断する新しいガバナンスアーキテクチャ
• Semantic Overlaysの衝撃——「トークンでは偽れない帯域外チャネル」でプロンプトインジェクションを根絶する