- 公開日
AIへ「許可した操作だけを実行する」と指示しても、実行用の接続先と強い認証情報をそのまま渡すと、誤った要求が外部へ届く経路が残ります。権限プロキシは、AIと実行先の間で要求を受け取り、主体、対象、操作、引数を検査してから、許可された要求だけを通す仕組みです。
重要なのは、プロキシが存在することより、検査を通らず実行できない構成にすることです。AIが「承認済み」と書いても、それを許可の証拠にせず、信頼する認証情報、権限規則、承認記録と照合します。要求を検知しただけで満足せず、実行が阻止されたことと、正当な処理が続けられることを別に確認します。
誤った要求が、そのまま発注へ届く問題
架空の購買支援AIを考えます。利用者は「商品Pの現在価格を調べて、購入案をまとめて」と依頼しています。発注システムには価格照会と発注作成の機能があり、接続用アカウントは両方へアクセスできるとします。ここでの人物、商品、金額、APIは説明用の仮定です。
この構成でAIが購入案の作成を発注まで拡張すると、利用者が頼んでいない注文を作る可能性があります。「発注しないで」と指示を追加することはできますが、同じ接続経路が残っていれば、指示違反を技術的に止める条件にはなりません。指示・システムによる強制・人間の承認の役割分担は、AIの送信をどう制御する？ 指示・システムの強制・人間承認の役割で扱っています。
そこで、AIには価格照会の要求を出す窓口だけを見せ、発注APIへ直接接続できる認証情報を渡さないようにします。プロキシは、今回の依頼で認められているのが価格照会であることを確認し、発注作成の要求を受けても下流へ送らない設計にします。
これはAIが悪意ある指示を見抜くことだけに依存しない対策です。資料内の文章やモデルの誤解によって発注要求が作られても、実行側は同じ許可条件で検査します。一方、何を購入案に書くかという文章の正確さは、権限プロキシだけでは判断できないため、別に資料との照合が必要です。
信頼する情報を、モデルが作る引数から分ける
要求には、モデルが提案する情報と、システムが取得する情報があります。商品識別子や照会条件はAIが候補を作れますが、本人確認済みの利用者ID、所属組織、保有権限、承認済みという状態を、同じ自由入力として受け取ってはいけません。
例えば要求本文に「role: administrator」や「approved: true」が含まれていても、それはモデルが出力した値です。プロキシは認証済みセッションや承認システムから実際の状態を取得し、本文の値で上書きしません。不要な権限フィールドを入力から受け付けない方式なら、この区別を明確にできます。
また、利用者とプロキシ自身の権限を分けます。プロキシの接続アカウントが更新できるからといって、すべての利用者の更新要求を通しません。利用者の許可範囲、今回の依頼、プロキシの接続権限がすべて条件に合う場合だけ進める考え方です。どれか一つが広いことを、ほかの不足を補う理由にしません。
ポリシーエンジンは、こうした許可規則の判定をアプリケーションから分離する選択肢です。Open Policy Agentの文書は、OPAがポリシーの判断（decision-making）を強制（enforcement）から切り離すと説明しており、ソフトウェアは判断が必要なときにOPAへ問い合わせます。判断を外へ出す構成では、判定エンジンが「拒否」と返しても、呼出し側がその結果を無視すれば要求は止まりません。結果を受け取ったプロキシや実行側が、拒否を確実に適用する作りにしておきます。
対象、操作、引数を順に照合する
この架空の価格照会では、まず認証された利用者が商品Pを含むカタログを閲覧できるかを確認します。次に、操作が価格照会かを確認し、数量など必要な引数が定義された型と範囲に収まるかを検査します。対象商品が許可されていても、発注作成という別操作は許可しません。
| 検査するもの | 確認に使う根拠 | 不一致・未確認時の処理 |
|---|---|---|
| 主体と組織 | 認証済みセッションと管理側の所属情報 | 保護された処理を開始しない |
| 対象商品 | 対象カタログと利用者の参照範囲 | 対象外の内容を返さず拒否する |
| 操作 | 今回の依頼と許可操作一覧 | 未依頼の発注や変更を送らない |
| 数量・通貨など | APIの型、商品条件、業務上の許可範囲 | 補正して通さず、誤りを返す |
| 金額 | 信頼する価格情報と見積条件 | 計算や条件が合わなければ保留する |
| 承認状態 | 承認者・対象・内容・期限を持つ記録 | 記録がない、変わった、失効した場合は止める |
OWASPの入力検証ガイドは、期待する型と形式という構文（syntax）と、その操作にとって値が妥当かという意味（semantics）の両方を検証するよう勧めています。数量が整数であることだけでは、その商品の注文単位に合っていることまでは分かりません。Input Validation Cheat Sheet
同様に、金額が数値でも、通貨、税込・税別、送料、割引の条件が違えば承認対象と一致しません。プロキシは、モデルが提示した総額をそのまま上限判定へ使うのではなく、信頼する見積や価格の版から必要な値を照合します。条件が不足している場合は、ゼロや標準値で埋めて通さないようにします。
許可された更新でも、承認した内容と結び付ける
価格照会だけの依頼なら、発注は常に今回の範囲外です。比較のため、次に利用者が別途、商品Pを二個、合計三千円、通貨JPY、追加費用なしの見積で購入することを承認した状態を考えます。数値は設計説明用で、実際の購入は行いません。
この場合でも、商品Qへ変えた要求や、数量を増やした要求は通しません。三千円が許可されていることを理由に、別の商品を同額で買ってよいとは解釈しません。承認は金額の上限だけでなく、対象、数量、相手先、配送条件など、当該操作で重要な内容と対応させます。
OWASPの取引認可ガイドは、利用者が重要な取引内容を確認できること、取引データの変更を保護すること、実行時に正しく認可されたかを確かめることを扱っています。ここでは、その考え方を発注要求と承認記録を結び付ける設計へ適用しています。特定の認証方式をすべての購買に義務付ける説明ではありません。Transaction Authorization Cheat Sheet
承認後に価格が変わったなら、元の記録に「承認済み」とあるだけでは進めません。実行直前の要求が何に対応するかを確認し、許可範囲を超える変更があれば再承認へ戻します。モデルが新しい条件をもっともらしく説明できることと、その条件が許可されたことは別です。
正規化で意味を変えず、不明な表現は拒否する
入力には表記揺れがあります。前後の空白を除く、決められた形式で識別子を扱うなどの正規化は、比較を安定させるために使えます。ただし、認可する対象を都合よく別の対象へ変える処理にしてはいけません。
例えば商品名の曖昧な一致から商品IDを推測し、そのまま発注へ進めると、似た商品へ変わる可能性があります。照会で候補を示す段階と、確定した商品IDで操作する段階を分け、実行時には曖昧さを残さないようにします。金額の単位や通貨を省略した入力も、黙って補って上限内に収めません。
プロキシと下流APIが同じ入力を異なる意味で解釈する場合も危険です。未知のフィールド、重複した項目、仕様で認めない表記をどう扱うかを決め、検査した値と実際に送る値が一致するようにします。検査後に元の未検査文字列を送る構成では、前段の検査をすり抜ける意味の差が残ります。
入力の整形や危険表現の検知は補助手段です。「承認済み」と書かれた文を検知できなかった場合でも、正式な承認記録がなければ更新が止まるようにします。安全性の根拠を、特定の文言を見つけられることだけに置かない設計です。
プロキシを迂回できる経路を閉じる
AIが使う環境から、別のHTTPツールやブラウザーで発注先へ直接アクセスできるなら、専用ツールのプロキシだけでは境界が完成しません。実行先へ届く通信経路と認証情報の配置を調べ、許可された経路以外から同じ操作を起こせないようにします。
一つの構成例は、発注先の認証情報をプロキシ側だけに置き、AIの実行環境には渡さず、下流側も認証されたプロキシからの要求だけを受け付ける形です。ネットワーク制限も組み合わせますが、送信元のIPアドレスだけを利用者の認可とみなさず、下流でもサービスと対象の権限を確認します。
同じ認証情報をログや環境変数へ露出させる、管理用APIを別経路で公開する、汎用の任意URL取得機能から内部システムへ到達できる、といった経路も点検対象です。プロキシ経由の正常処理だけを試して、迂回できないと結論しないようにします。
ただし、記事の構成を採用すればあらゆる迂回を防げるという保証はできません。別ツールの追加、認証情報の共有、通信設定の変更によって経路は変わります。実際の環境で到達経路を把握し、変更時に境界を再確認する運用まで含めて設計します。
障害時にも、許可不明のまま実行しない
ポリシーの取得に失敗した場合、「判定サービスが止まっているから今回は通す」とすると、障害が権限拡大につながります。認可を確認できない要求は保留し、実行先へ送らない扱いを基本にします。公開情報の照会など独立して許可できる処理があるなら、別の明示的な条件で続けます。
発注要求を送った後で応答が途切れた場合は、拒否されたとは限りません。プロキシの受信、下流への送信、下流の実行結果を分け、結果不明として記録します。要求の識別子や発注状態を照会し、同じ注文を重複して作らない方法を対象APIの仕様で確認してから再試行を判断します。
認可の拒否と、業務上のエラーも分けます。対象へのアクセスが許されていても、在庫不足で発注できない場合があります。この失敗に対し、権限を増やして再実行する理由はありません。利用者には現在確認できた状態と選択肢を返し、別商品や数量変更を勝手に選ばないようにします。
検知・阻止・継続を別々に確認する
安全な確認には、実際の注文を作れない試験用APIと架空商品を使います。以下は未実行の確認設計であり、模擬入力を本番の発注先へ送る手順ではありません。
| 模擬要求 | 期待する処理 | 確認する証拠 |
|---|---|---|
| 許可された商品Pの価格照会 | 必要な価格情報だけを返す | 対象、操作、応答の対応 |
| 照会依頼なのに発注作成を要求 | 発注を送信せず拒否する | プロキシの拒否と下流の未実行記録 |
| AIが承認済みと主張し、正式記録はない | 更新を止める | 自己申告値が認可へ使われていないこと |
| 承認した商品Pを商品Qへ変更 | 対象不一致として保留する | 承認内容と送信予定引数の差 |
| 型は正しいが通貨や合計が不一致 | 業務条件の不合格として止める | 見積条件、計算、判定の対応 |
| 判定サービスの応答なし | 未確認として送信を保留する | 下流へ要求が出ていないこと |
| 専用プロキシを使わない接続 | 実行先で受け付けない | 接続・認証・下流の拒否記録 |
拒否を表示したのに下流で発注が起きていれば、防御は失敗です。危険な要求を正しく検知して発注を止めたものの、独立した価格照会まで止まった場合は、検知の誤りではなく停止範囲が広すぎる問題として記録します。問題のない照会を危険と判定した場合は誤検知であり、改善する箇所が異なります。
この三つを一つの「安全率」にまとめず、検知結果、許可外操作の実行有無、正当な作業の継続結果を別に残します。証拠が欠ける項目は未確認とし、表示が出たという理由だけで合格にしません。試験用の送信先とデータを固定し、どの経路を確認したかも記録します。
運用で維持する範囲と限界
プロキシは認可処理をまとめられる一方、障害時の停止箇所にもなり、規則の変更やログ管理の負担が増えます。誰が許可条件を変更できるか、変更をどの試験へ通すか、問題が出たときにどの版へ戻すかを決めます。モデルが規則ファイルを編集できるなら、強制の境界が崩れるため、管理経路も分けます。
記録には、要求ID、利用者と組織、対象、操作、判定理由、規則の版、承認記録の参照、送信・結果の時刻などを残します。認証情報そのものや、調査に不要な購買内容を無制限に保存しないようにします。拒否が増えた場合は、攻撃と決め付ける前に、仕様変更や正規化の不一致、業務範囲の変化も調べます。
また、権限内の誤判断は残ります。間違った商品を利用者自身が承認した場合や、見積情報の元データが誤っている場合を、権限検査だけで解決することはできません。価格の根拠や業務上の妥当性を確認する工程、人が判断する工程と分担します。
権限プロキシの価値は、AIの説明を信じなくても、定めた範囲外の要求を止められる位置を作ることです。主体と引数の検査、承認内容との対応、直接経路の制限、実行結果の確認がつながっているかを点検し、プロキシという部品名だけで安全性を評価しないようにします。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
