プロンプト注入は入力検査だけで防げない、AIエージェントの守り方

AIエージェントへのプロンプト注入は、入力フィルターだけで完全に防ぐことを目標にしてはいけない。実装上の答えは、外部コンテンツに悪意ある命令が混ざることを前提に、入力、コンテキスト、権限、実行、出力、監査の6層で被害経路を断つことだ。

優先すべきなのは、ツールと権限を絞り、重大操作を明示承認の対象にすることだ。その後に入力検査、命令とデータの分離、出力検証、監視を加える。検知をすり抜けても、送信、削除、購入、公開、機密情報の取得へ進めない境界を先に作る。

1．入力層：外部コンテンツを未信頼として扱う

利用者が入力欄に書く直接注入だけを検査しても足りない。OWASPの防御指針 は、Webページ、文書、メールと添付ファイル、コードコメントなどに命令を隠す間接注入を挙げ、入力検証に加えて出力監視、最小権限、人による承認などを示している。検索結果、RAGで取得した文書、ツールの戻り値も、信頼済みの命令として扱わない。

入口では文字コードを正規化し、不可視文字や難読化、危険なHTML・Markdown、既知の命令上書き表現を検査する。ただし、フィルターの判定は安全証明ではなくリスク信号にすぎない。通過したデータにも未信頼の区分と取得元を付け、後工程で出所を判定できるようにする。

• 利用者の指示と取得した本文を別フィールドで受け渡す
• 外部文書から抽出する情報の形式と長さを用途ごとに制限する
• 検査できない形式、破損ファイル、過度に難読化された内容は隔離する

2．コンテキスト層：命令とデータを分け、秘密を置かない

システム指示、利用者の依頼、外部データ、ツール結果を構造化し、外部データには「処理対象であり、実行すべき命令ではない」という役割を与える。外部文書を読む処理と、権限付きツールを選ぶ処理を分け、前者にはツールや認証情報を渡さない構成も被害経路を狭める。

ただし、分離だけを最終防衛線にはできない。2026年5月17日に公開された AbdelnabiとBagdasarianのプレプリント は、情報の流れや文脈上の規範を操作する攻撃を命令・データ分離で検知できない場合があり、規則を厳しくすると正当な処理も妨げ得ると論じている。これは、モデルによる文脈理解だけに認可を任せず、後段で権限と操作を強制的に制約すべき理由になる。

APIキー、パスワード、他利用者の会話、内部設定はプロンプトへ常駐させない。秘密は実行時に専用の保管先からツール側が取得し、モデルには値そのものではなく、利用できる操作と必要な引数だけを示す。

3．権限層：攻撃が成功しても届かない範囲を作る

早期に実装効果を得やすい対策は、エージェントが持つ能力そのものを減らすことだ。OWASPのExcessive Agency解説 は、過剰な機能、権限、自律性を根本原因として挙げ、不要なツールの削減、機能の細分化、最小権限、下流での認可、高影響操作への利用者承認を対策としている。

汎用シェル、任意URL取得、自由なSQL実行のような開放型ツールは避け、「指定フォルダーの文書を読む」「下書きを保存する」といった単目的APIに置き換える。読み取りと書き込みには別の認証主体を使い、トークンは利用者、テナント、対象資源、操作、期限で制限する。データベースの参照だけが必要なら、更新や削除の権限を同じ接続に持たせない。

4．実行層：ツール呼び出しをポリシーと承認で止める

モデルが生成したツール名や引数は、命令ではなく未信頼の提案として扱う。実行ゲートでスキーマ、型、対象ID、許可された宛先、利用者の権限、元の依頼との一致を検証し、下流システムでも呼び出しごとに認可する。モデル自身に「この操作は許可されているか」という最終判断を委ねない。

削除、外部送信、購入、公開、権限変更、機密データの読み出しには、実行前のプレビューと明示承認を置く。承認画面にはモデルが作った抽象的な説明ではなく、実行系が保持する操作名、対象、送信先、変更差分、扱うデータを表示する。例えばメール要約エージェントは通常時を読み取り専用とし、送信が必要な場合だけ別フローで本文と宛先を利用者が確定する。

さらに、1セッション当たりの操作回数、送信件数、取得量、費用に上限を設ける。連続失敗、権限外資源への接触、依頼と無関係なツールへの切り替えを検出したら、自動継続せず停止状態へ移す。

5．出力層：返答をそのまま表示・実行しない

注入がモデルまで到達すると、返答に外部送信用URL、機密情報、危険なHTML、後続ツールへの命令が混ざり得る。画面表示前にHTMLとMarkdownを無害化し、リンク先や埋め込み資源を制限する。個人情報や秘密の検査も、入力側だけで終わらせず出力境界で行う。

後続処理へ渡す値は自由文から推測せず、定義済みスキーマに適合した項目だけを採用する。不明なフィールド、余分な引数、許可リスト外のURLや識別子があれば拒否し、安全そうな値を推測して補完しない。応答検査に別のモデルを使う場合も誤判定は残るため、決定的な認可やスキーマ検証の代わりにはしない。

6．監査層：異常を見つけ、止め、再現する

監査ログには、入力の来歴とハッシュ、適用したポリシーの版、モデルが提案した操作、実際に許可された操作、引数、承認者、下流システムの結果を関連付けて残す。秘密や本文を無制限に記録するのではなく、調査に必要なメタデータとマスキング済み情報に絞り、ログ自体へのアクセスも制限する。

拒否率の急変、通常と異なるツール列、短時間の大量取得、別テナントへの参照、同じ操作の反復を監視する。しきい値を超えたらトークンを失効させ、実行キューを止め、人の確認へ切り替える。停止措置は管理画面だけに依存せず、ツールゲートや認証基盤からも強制できるようにする。

実装は次の順で進めると、検知精度の向上を待たずに危険範囲を縮められる。

1. 不要なツールを外し、読み取り専用を標準にする
2. 重大操作に実行ゲートと明示承認を置く
3. 外部データを分離し、秘密をモデルのコンテキストから除く
4. 入力と出力の検査、スキーマ検証を追加する
5. 監査ログ、異常検知、レート制限、停止手順を整える
6. 直接注入と間接注入のテストを継続し、失敗時の境界を確認する

評価対象は、攻撃文を何件見つけたかだけではない。検知を通過した場合でも、越権操作が下流の認可で拒否されるか、秘密がコンテキストに存在しないか、重大操作が承認待ちで止まるかを確認する。プロンプト注入を完全に見抜くことより、見抜けなかった一件を事故へ発展させない設計が、AIエージェントの実用的な防御になる。