銀行AIにおける間接的プロンプトインジェクション：Bunqのケーススタディ

間接的プロンプトインジェクションにより、攻撃者は信頼された銀行インターフェースを武器化できる

間接的プロンプトインジェクションは、大規模言語モデル（LLM）が、取引明細などの信頼できないデータを、受動的な情報としてではなく、一連の指示として解釈した場合に発生します。欧州第2位のデジタル銀行であるBunqのセキュリティ評価において、Blue41は、悪意のあるアクターが、取引リファレンスフィールドに細工されたペイロードを含む極めて少額の銀行送金（例：€0.02）を行うことができることを実証しました。被害者が銀行のAIアシスタントに最近の取引を要約するよう依頼すると、アシスタントはこのペイロードを取得し、それを実行してしまい、銀行自身のアプリケーション内で非常に信頼性の高いスピアフィッシング攻撃を開始する可能性があります。

攻撃のメカニズム

この攻撃は、マルウェア、デバイスへのアクセス、初期のソーシャルエンジニアリングを必要としないため、従来のセキュリティ境界を回避します。データ取得とモデル実行の間の信頼境界の失敗を利用します。

攻撃のワークフロー

ペイロードの配信: 攻撃者はターゲットに少額の資金を送金します。取引明細には、LLMの挙動を乗っ取るように設計された隠されたプロンプトインジェクション・ペイロードが含まれています。
ユーザーによるトリガー: 被害者は、「最近の取引を表示して」といった日常的なクエリを使用して、銀行のAIアシスタントとやり取りします。
コンテキストの取得: AIアシスタントは、攻撃者の送金を含む取引履歴を取得し、このテキストをLLMのコンテキストウィンドウに投入します。
実行: LLMは注入された指示を処理します。Bunqのデモンストレーションでは、アシスタントは偽の再認証リクエストを提示するように操作され、銀行からの正当な通知のように見えました。

このレスポンスは公式の銀行アプリから生成されるため、また実際の口座詳細を参照できるため、フィッシングの試みは標準的なメールやSMSよりも大幅に信憑性が高くなります。

なぜ従来のガードレールが失敗するのか

標準的な入力フィルタやプロンプトインジェクション分類器は、間接的インジェクションに対しては不十分なことが多いです。なぜなら、悪意のある意図は、データフィールド単体では明らかにならないからです。

「ジェイルブレイク」の試みは、「以前の指示をすべて無視せよ」といった明らかなフレーズを使用することがありますが、高度な間接的インジェクションは、期待されるデータ形式に紛れ込むように細工されています。危険性は、データがアシスタントの特定のシステムプロンプトとユーザーのクエリと組み合わされたときにのみ現れます。その結果、静的なテキスト分類では、正当な取引明細と、休眠状態の指示ペイロードを確実に区別することはできません。

AIエージェントのリスクを軽減するための戦略

金融サービスにおけるAIアシスタントのセキュリティ確保には、単一のフィルタではなく、多層防御のアプローチが必要です。Blue41は、主に4つの制御レイヤーを推奨しています。

1. コンテキストの最小化

LLMに不要なデータフィールドを渡さないようにします。特定のユーザークエリに答えるために取引明細が必要でない場合、モデルに到達する前にコンテキストから削除すべきです。

2. 明示的なデータと指示の分離

アーキテクチャは、取得されたデータを信頼できないものとして扱う必要があります。これには、データを指示から明確に区別するための技術を使用し、取得されたコンテンツが実行されるべきではなく、要約または報告されるべきであることをモデルに理解させる必要があります。

3. 出力とアクションの制約

AIアシスタントは、独立した非AIによる検証ステップ、または宛先の厳格な許可リスト（allow-list）なしには、外部リンクの生成、認証情報の要求、またはワークフローの開始といった、影響力の大きいアクションを実行することを制限されるべきです。

4. ランタイム・ビヘイビア・モニタリング

すべての可能なペイロードを防止することは非現実的であるため、セキュリティチームは異常な挙動を監視すべきです。侵害の指標（Indicators of compromise）は以下の通りです：

外部URLの突然の生成。
通常レスポンスに含まれる情報の抑制。
ツールやAPIコールの不自然なパターン。
アシスタントの確立された行動プロファイルからの逸脱。

コミュニティの視点と技術的批判

この脆弱性の公開は、重要な金融インフラにおけるAIの必要性と安全性について、技術的な観察者の間で大きな議論を巻き起こしました。

アーキテクチャ上の懸念

一部の批評家は、取引明細のリストのような決定論的なデータを表示するためにLLMを使用することは、固有のアーキテクチャ上の欠陥であると主張しています。ある観察者は、「データベースのクエリ結果を表示することは、確率論的な推論を必要としないタスクに対して、不必要なリスクを導入することになる」と指摘しています。

古典的な脆弱性との比較

業界の解説者は、間接的プロンプトインジェクションをSQLインジェクションの再来と例えています。SQLインジェクションがユーザー入力がコードとして扱われたときに発生したのと同様に、プロンプトインジェクションは、取得されたデータが指示として扱われるときに発生します。

実用性とリスク評価

一部の懐疑論者は、現実世界での影響を、ユーザーが知らない人からお金を受け取り、その特定の取引についてAIに積極的に質問しなければ攻撃が成立しないという点から、疑問を視います。しかし、反対の議論は、銀行アプリのインターフェースに対する高い信頼度があるため、フィッシングの成功率が従来のメソッドよりも大幅に高くなる可能性があるということです。

"I feel like as long as this is the case, we'll never have secure LLMs... how do you plan on separating data from instructions?"

この根本的な問いは、生成AIアプリケーションにおける「データ vs コード」の境界に関する継続的な課題を浮き彫りにしています。