ハッカーたちが金融AIアシスタントを騙す新たな手口

ブログ,サイバーセキュリティ

攻撃者はもはや銀行員を騙す必要はありません。メールや文書に隠された指示によって、金融AIアシスタントに資金の送金や顧客データの漏洩を行わせることが可能になります。この攻撃の仕組みと、金融機関がどのように防御しているかについて解説します。

byMilena Baghdasaryan

最終更新日:
7 読了時間：約7分
ハッカーたちが金融AIアシスタントを騙す新たな手口

主なポイント

  • ハッカーたちは、金融AIアシスタントを乗っ取るために、日常的な文書に間接的なプロンプト注入型ペイロードを積極的に仕込んでいます。
  • 人間を騙す従来の詐欺とは異なり、この攻撃は、疑いも抱くことなく即座にコマンドを実行する自動化されたAIを標的としている。
  • 資金の移動、ワークフローの開始、あるいは規制対象の顧客データへのアクセスが可能なAIエージェントは、攻撃者にとって最も価値の高い標的となります。
  • システムによるプロンプトだけではエージェントのセキュリティを確保できないため、厳格な最小権限の原則と、人による承認の義務化が不可欠である。
  • これらのペイロードの主な配信手段は電子メールであるため、AIがメッセージを処理する前にその正当性を確認するためには、DMARCの厳格な適用が求められます。

実環境のコンテンツを調査していたセキュリティ研究者たちが、最近、憂慮すべき事実を突き止めました。彼らは、人間ではなく、そのテキストを読み取るあらゆるAIエージェントを対象に書かれた隠された指示を発見したのです。そのうちの1つは、決済機能を持つAIアシスタントに、5,000ドルの固定額での取引を確実に実行させるよう特別に設計された、完全に悪用可能なペイロードでした。これは管理された実験室でのデモンストレーションではなく、実環境で発見された実際のペイロードでした。

この10年間、金融機関は、説得力のあるメールに惑わされないよう従業員を教育するために莫大なリソースを費やしてきました。ところが今、そうした金融機関の多くが、まさにその受信箱にAIアシスタントを連携させています。これらのアシスタントはあらゆるメールを読み込み、何も疑うことなく、多くの場合、それを利用する従業員の権限に基づいて動作しています。

この手法は「間接プロンプト注入」と呼ばれています。これは、金融詐欺の手口に大きな変化をもたらすものです。以下では、この攻撃の仕組み、銀行が実際にどのような脆弱性にさらされているか、2026年に研究者が実際に実証したこと、そしてこれを阻止するために必要なアーキテクチャ上の対策について解説します。

「プロンプト注入」とは何ですか？

プロンプトインジェクションとは、攻撃者がAIシステムを操作して意図しないコマンドを実行させることを指します。ダイレクトインジェクションは、ユーザーがチャットウィンドウに直接悪意のある指示を入力した場合に発生します。間接的なプロンプトインジェクションは、はるかに危険です。これは、受信メール、添付された請求書、ウェブページなど、アシスタントが自動的に読み込む外部コンテンツの中に指示が隠されている場合に発生します。

これが機能する根本的な理由は単純です。現在のAIシステムは、指示とデータを確実に見分けることができないからです。アシスタントが取り込むすべての文書は潜在的な入力として扱われるため、外部ファイルはどのようなものであっても攻撃の媒介となり得るのです。

なぜ金融AIアシスタントが高価値な標的となるのか

フォースポイントのシニアセキュリティ研究者、マユール・セワニ氏はこの問題を的確に言い表しています。すなわち、影響度は権限の大きさに比例するというのです。会議の議事録を要約するだけのAIアシスタントは、リスクが低いと言えます。一方、メールの送信、ワークフローの起動、あるいは資金の移動ができるアシスタントは、極めて重要で、影響の大きい標的となります。

現在、金融業界全体で導入が進んでいるアシスタントは、ますます後者のタイプになってきています。これらは顧客記録の検索、コンプライアンス文書の解析、社内ワークフローの起動を行い、導入環境によっては決済システムに直接アクセスすることもあります。

小売業界において、注入された指示は単に書類を漏洩させるだけかもしれません。しかし、銀行業界では、同じ注入された指示によって、資金の移動が行われたり、厳格な規制の対象となる顧客データが流出したり、あるいは「顧客確認（KYC）」のコンプライアンス判断が歪められたりする可能性があります。

金融機関が実際にエクスポージャーを抱えている場合

AIエージェントに銀行システムへのアクセス権限を与えると、脅威モデルは一変します。以下の表は、現在金融機関がさらされている具体的な業務分野を詳述したものです。

活動地域攻撃ベクトルビジネスへの潜在的な影響
決済業務承認または開始権限を持つアシスタントが、隠されたテキストを含む受信指示文書を読み取る。エージェントは、人間のオペレーターの権限を利用して、攻撃者の口座へ資金を送金させられるように仕向けられる。
顧客のオンボーディングおよびKYC提出された文書の要約を担当するアシスタントに、重大なリスクの指摘を隠蔽または改ざんするよう指示する隠されたテキストが与えられる。高リスクのクライアントがコンプライアンスチェックを回避している。コンテンツの抑制を目的としたペイロードは、すでに実環境での事例として報告されている。
カスタマーサービス顧客から送信されたサポートチケットやチャットメッセージを通じて、インジェクション攻撃の指令が届きます。この悪意のあるプロンプトは、AIアシスタントに付与されたサービスデスクの特権を利用してコマンドを実行します。
社内ナレッジ検索取引書類、信用情報ファイル、または取締役会資料にアクセスできる担当者が、悪意のあるリンクや文書を開いてしまう。このAIは、アクセス権限のある機密情報を収集し、攻撃者が管理するサーバーへ送信する。
ベンダーとの連絡侵害された第三者から送信される受信メールには、隠されたペイロードが埋め込まれています。攻撃者は、信頼度が最も高い受信チャネルを悪用し、ベンダーの請求書を処理するようにプログラムされたエージェントに、指示を直接送り込みます。

2026年に研究者たちが実際に実証したこと

この脅威はもはや理論上の話ではありません。セキュリティ研究者たちは、2026年に実際の企業環境においてこれらの脆弱性が実際に悪用されている実態を詳細に記録しています。

Forcepointが確認した実環境でのペイロード10件（2026年4月）

2026年4月23日、Forcepointの研究チームは、実環境で検出された10件の間接的なプロンプト注入型ペイロードに関する調査結果を公表した。これらのペイロードには、コンテンツの非表示、アトリビューションの乗っ取り、開発者ツールに対するUnixコマンドの実行、APIキーの窃取などが含まれていた。銀行にとって最も重大な点として、この調査では、決済機能を統合したAIエージェントを標的とした決済詐欺用ペイロードについて詳述されていた。 このペイロードには、5,000ドルのPayPal取引を確実に実行するための命令が埋め込まれていた。Sewani氏は、これを無害な研究用プローブではなく、即時実行を目的とした「武器化されたペイロード」であると特徴づけた。

Microsoft Copilotに対するReprompt攻撃（2026年1月）

2026年1月15日、Varonis社は「Reprompt」攻撃の詳細を明らかにした。これは、Microsoft Copilotを標的としたワンクリック型のデータ流出チェーンであった。この攻撃では、URLパラメータを利用して指示を注入していた。アシスタントに対し、安全対策の障壁を迂回するために操作を繰り返すよう指示し、攻撃者が制御するサーバーとの間で継続的なやり取りを確立することで、データを流出させていた。 この攻撃は、メールで送信された一見正規のものに見えるCopilotのリンクを介して行われ、被害者はクリックするだけで攻撃に巻き込まれる仕組みでした。マイクロソフトは速やかにこの脆弱性に対するパッチを適用し、Microsoft 365 Copilotのエンタープライズ版は影響を受けなかったと報じられていますが、この攻撃の手口は、エージェントが騙されさえすれば、アクセス可能な内部コンテキストを喜んで引き渡してしまうことを証明するものでした。

より大きな傾向

これは特定のベンダーだけの問題ではありません。エージェント型コーディングツールに対しては、ソースコードのコメントを悪用したインジェクション攻撃が実際に成功した実証例があり、また、主要な複数のモデルにおいて、ガードレールの迂回手法が広く報告されています。

これは、標的が異なる「ビジネスメール詐欺」です

間接的なプロンプト注入攻撃のパターンは、ビジネスメール詐欺（BEC）と機能的に同一です。一見すると完全に正当に見える不正な指示が届き、誰かがそれに従ってしまいます。決定的な違いは、その「誰か」が今やソフトウェアであるという点です。AIには躊躇もなければ、何かがおかしいという直感もなく、電話をかけてCFOに不審な依頼を確認しようという本能もありません。

幸いなことに、金融機関がすでにBEC対策として実施している管理措置は、この新たな問題にも直接適用できます。帯域外検証、支払いや受取人の変更に対する複数人による承認、および単一の自動処理に対する厳格な上限設定は、依然として最善の防御策です。AIエージェントは、これらの既存の管理措置の範囲内で動作しなければならず、決してその範囲外で動作してはなりません。

制御：AIエージェントの爆風半径を縮小する

セキュリティアーキテクトやリスク管理チームは、AIエージェントを巡る構造的な統制策を構築する必要があります。金融プラットフォームのセキュリティを確保するには、システムのプロンプトだけに頼ることはできません。

制御原理実践的な導入セキュリティ目標
最小権限の原則支払、送付、および承認の権限を厳格に制限する。ほとんどのアシスタントには読み取り権限のみを付与し、侵害された場合に引き起こし得る被害を最小限に抑えるようにしてください。
ヒューマン・イン・ザ・ループ重大な影響を及ぼすアクションについては、必ず人間の承認を義務付ける。セキュリティの境界は、そのアクションそのものに設定してください。金銭の支払いについては、必ず人が「承認」をクリックする必要があります。
コンテンツに対するゼロトラスト取り込まれたすべての文書（PDF、電子メール、ドキュメント）を、信頼できないユーザー入力として扱う。エージェントが、外部ファイルから取得した生のテキストを検証せずに実行することを防止する。
API およびツールのロギングエージェントが具体的に何を読み取り、何を実行したかについて、厳格な監査証跡を維持する。インシデント対応調査の過程において、フォレンジック情報の迅速な可視化を確保する。
厳格なエグレスフィルタリング未知または信頼できないIPアドレスへのアウトバウンド接続を遮断します。攻撃者が制御するサーバーに到達してデータを持ち出すことを前提とする、「Repromptチェーン」のような攻撃を阻止する。
統合ワークフローAIエージェントを、現在の支払い管理フレームワークに統合してください。既存のセキュリティチェックを迂回する、並行して行われる未検証の承認プロセスの発生を防ぐ。

検知については現実的に考えるべきです。既知のプロンプトインジェクションのトリガーフレーズを含んだ受信ドキュメントをフィルタリングしても、それは単なる一時的な妨げに過ぎません。攻撃者は単にペイロードの表現を変えるだけでしょう。

この状況から、プロンプトだけで抜け出すことはできません

AIエージェントがテキストによって誘導される限り、永続的な制御手段は構造的なものに限られます。エージェントに許可される動作、アクセス可能なシステム、そして人間の介入が厳密に必要とされるアクションを、物理的に制限しなければなりません。システムのプロンプトやベンダーによるガードレールを改善すれば、攻撃のコストは確実に高まりますが、その脆弱性の種類そのものを排除することはできません。 規制対象の金融機関にとって、この違いは、監査人に証明できる制御と、機能しているかどうかを推測することしかできない制御との違いに他なりません。

上司たちが示唆していること

規制当局はこの変化に細心の注意を払っている。FINRAの「2026年人工知能（AI）主要トピックに関するガイダンスおよび監督報告」では、特に「エージェント型AI」が独自の監督リスクカテゴリーとして明確に挙げられている。これらのシステムは単にテキストを生成するだけでなく自律的な行動をとるため、企業は完全な監査証跡を維持し、実行前に人間によるチェックポイントを設ける必要がある。またFINRAは、「シャドウAI」のリスクや、サードパーティのAIプラットフォームをハイリスクベンダーとして扱う必要性についても強調している（Smarshによる二次報道で詳述されている）。

OCCもまた、銀行向けの包括的なAIモデルガバナンスに関するガイダンスが間もなく発表される見通しであることを示唆しています。さらに、FS-ISACは、敵対的AIの分類やベンダー評価などを網羅した、金融セクター向けのAIリスクに関する一連のホワイトペーパーを公表しました。これらのホワイトペーパーは2024年2月に発表されたものであり、「エージェント型AI」の流行以前に作成されたものである点に留意が必要ですが、金融セクターの基礎知識を身につける上では依然として有用です。

管理職とセキュリティアーキテクトが求めているのは、根本的にはまったく同じこと、すなわち、重大な結果をもたらすAIの行動に対して、実証可能な人間の監督を行うことです。この規制上の整合性こそが、セキュリティ責任者がこうした統制策を構築するための資金を確保する上で、最も強力な内部的な論拠となります。

メール認証の活用場面

メール認証では何ができないかを明確に述べておくことが重要です。p=rejectに設定された DMARC は、プロンプトの注入を防ぐことはできません。また、メッセージの内容を検査することもなく、AI エージェントに許可される動作を制限することもありません。

しかし、銀行のAIアシスタントに対して成功する可能性が最も高いインジェクション攻撃は、CFOや取引銀行、あるいは信頼できる決済代行業者からのもののように見せかけたものです。信頼できないコンテンツがこうしたAIシステムに到達する主な経路は電子メールです。公開された「Reprompt」チェーンも、メールに添付されたリンクを通じて送信されました。AIエージェントが人間の監視を一切受けずにメールを処理する場合、送信者の真正性は、処理プロセスにおける信頼の指標として、まさに最後の砦となります。

金融サービス業界は、あらゆる業界の中でもDMARCの導入率が最も高い業界の一つですが、残念ながら、その適用状況は最も不十分な業界の一つでもあります。AIを受信トレイに連携させる場合、厳格なメール認証の実施はもはや任意の措置ではありません。この攻撃経路のセキュリティ対策に関する詳細については、当社の調査レポート『金融サービス業界におけるフィッシング』および『金融機関におけるDMARC』をご覧ください。

結論

過去10年間、金融分野におけるメールセキュリティの最大の弱点は、悪意のあるリンクをクリックしてしまう従業員でした。しかし現在、各機関は、そのまさに同じ受信トレイを、あらゆるメールを読み取り、一切疑うことなく、実際のシステム権限を保有するソフトウェアに委ねています。こうした自動化されたエージェントを悪用するために特別に作成された最初のペイロードは、すでに実環境で活動しています。

この課題の解決には、多層的なアプローチが必要です。AIエージェントが物理的に実行できることを制限し、重大な影響を及ぼすアクションについては人間の関与を確保し、これらのエージェントを既存の決済管理体制に組み込み、エージェントに送信されるデータについては厳格な認証を行う必要があります。
当社のDMARCレコードチェッカーでドメインのセキュリティ状況を点検するか、金融サービス向けソリューションページをご覧になり、受信チャネルのセキュリティ対策について詳しくご確認ください。

よくあるご質問

「プロンプトインジェクション」とは、簡単に言うとどのようなものですか？

これは、ハッカーが文書や電子メールの中に秘密の指令を隠し込むサイバー攻撃です。AIアシスタントがそのファイルを読み込むと、知らず知らずのうちに隠されたコマンドを実行してしまいます。

プロンプトを投入することで、AIアシスタントに送金させることができますか？

はい。AIエージェントに決済システムへのアクセス権限が与えられており、かつ「人間による承認」の制御が欠如している場合、隠された指示によって、そのエージェントに不正な送金を強要することが可能です。

プロンプトインジェクションは実際の攻撃で利用されたことはあるか？

はい。2026年4月、研究者らは実環境において10種類の異なる間接プロンプトインジェクション型ペイロードを確認しました。その中には、5,000ドルのPayPal取引を実行するように特別に設計されたものも含まれていました。

プロンプトインジェクションは、ビジネスメール詐欺とどう違うのですか？

攻撃の手口は似ていますが、被害者は異なります。攻撃者は、人間の従業員を騙して送金させるのではなく、要求を即座に実行する自動化されたAIソフトウェアエージェントを騙すのです。

銀行はAIエージェントに対してどのような管理措置を講じるべきか？

銀行は、最小権限の原則を徹底し、重大な影響を及ぼすすべてのアクションについて人的承認を義務付け、厳格なネットワーク送信フィルタリングを実施し、エージェントが行うすべてのAPI呼び出しをログに記録しなければならない。

DMARCやメール認証は、プロンプトインジェクションを防ぐことができますか？

いいえ、DMARCでは、メールの内容に隠されたプロンプトが含まれているかどうかを検査することはできません。しかし、DMARCは、なりすましメールがAIに届くのをそもそも阻止するため、この攻撃の主要な侵入経路を排除することができます。

プロンプト注入

最新記事 by Milena Baghdasaryan(全て見る)
最終更新日:
DNSセキュリティのベストプラクティス：包括的なセキュリティ強化チェックリストDNSセキュリティのベストプラクティス