たった0.01ユーロの送金が銀行AIを乗っ取る？巧妙な攻撃手法を徹底解説

驚くべきことに、わずか0.01ユーロ（1セント）の銀行送金を利用するだけで、銀行のAIエージェントをハッキングし、不正な操作を引き起こす可能性があることが判明しました。この脆弱性は、AIが取引データに含まれるメタデータや特定の処理フローをどう解釈するかという仕様の隙を突いたものです。銀行システムでAI導入が進む今、セキュリティ担当者必読の最新の脅威トレンドです。

AIさん、お疲れ様。せっかくSQLインジェクションをほぼ撲滅したと思ったら、あなたがそれを復活させてくれるなんて！

本人の承諾なしに、しかも責任を負う立場のくせに、個人の資産管理にAIを突っ込むなんて、正直レベルが違う無責任さだと思う。

間接的なプロンプトインジェクションを解決する単一のコントロールは存在しない

いや、あるよ。AIエージェントを取り外すってやつだ。これで解決。

これはかなり興味深いな。記事を読む前は、銀行が本人確認のために最近の取引内容（どこでいくら使ったか、みたいな）を聞いてくるような、パスワードやPINの再設定時の話かと思った。フィッシャーがわざと少額を振り込んでおいて、銀行が「最近の取引額は？」と聞いてくることを悪用するんじゃないかってね。他にも住所や電話番号などの個人情報があれば、パスワードをリセットしてアカウントを乗っ取れるわけだ。顧客がACHやZelleでの未承認入金をブロックしていれば防げるかもしれないけど。当然ながら、銀行は入金記録を単独の認証方法に使うのは避けるべきだし、他の複数の証拠と組み合わせるべきだね。

これが彼らの使ったフィッシング攻撃と同じ手口かな？もし違うなら、脆弱性が2つあることになって、片方はまだ修正されていないってことになるね。

この一文がすごく印象に残った。

通常のテキストに見えても、LLMのコンテキストウィンドウに入れられた途端、モデルはそれをデータではなく命令として解釈してしまう可能性がある。

これが解決しない限り、安全なLLMなんて一生実現しない気がする。誰かがプロダクトにAI機能を加えるという話をするたびに感じる不安を、まさに一言で言い当ててる。今後のAI議論で「どうやってデータと命令を分離するつもり？」という基準として使わせてもらうよ。

この手のプロンプトインジェクション、自分が嫌いな会社の顧客フィードバックフォームでも使えるってことだよね？

いや、あまりにも馬鹿げていて、なんでこんな記事を書いたのか理解に苦しむよ。

この攻撃手法はあまりにも明白だし、バリエーションも何百回と議論されてきた「やってはいけない例」の典型だ。銀行の「技術」コンサルタントが、さも自分たちのスキルと献身の証かのようにこれを披露しているのを見ると、その銀行自体が大丈夫なのかと疑いたくなるね。

そもそも、なぜエージェントは「最近の取引を見せて」というクエリの結果をわざわざLLMに送る必要があるの？これはLLMによる解釈や意思決定なんて必要ない、完全に決定的（deterministic）な結果なのに。

最近はコード内にif文を書くと融通が利かないと考え、条件分岐のロジックをすべてLLMに丸投げする人が増えているのは分かるけど、データベースのクエリ結果を表示するのにまでLLMを噛ませる理由がさっぱり分からない。

なぜこんなことが可能なのか推測だけど、おそらく外部からのメッセージが「ユーザー」として追加されてしまい、直接の命令として認識されるからじゃないかな。

これはみんなが思っている以上にありがちな、業界全体で共通の古典的な問題だよ。簡単な解決策もちゃんとあるはずだ。

この記事で、彼らが実際にどんな修正を施したのか書かれていないのが腹立たしい。