読んだことのないメールがAIアシスタントを乗っ取る可能性

サイバーセキュリティに関する啓発活動は従来、不審なリンクをクリックしない、予期しない添付ファイルを開かない、認証情報を渡さないといったことを人々に教えることに重点を置いてきました。しかし、職場のメールシステム内でAIアシスタントの利用が拡大するにつれ、人をだますことに必ずしも依存しない新たな攻撃対象領域が生まれています。

KnowBe4 ThreatLabsの調査では、一見ごく普通に見えるメールに隠された間接的なプロンプトインジェクションが、AIアシスタントを操作し、他のメッセージに含まれる情報にアクセスして、そのデータを攻撃者が制御する追跡機構に送り込む可能性があることが実証されました。

研究者らが管理下で行ったGoogle Workspaceのテストでは、標的となるユーザーは悪意のあるメール自体を操作する必要がありませんでした。自動化されたワークフローがメッセージを処理し、一見正当に見えるGmailの下書きを生成しました。ユーザーがその下書きを開くと、別のメールから取得されたワンタイムパスコードが外部サーバーに送信されました。

この調査結果は、AIアシスタントを導入する組織にとって根本的な課題を浮き彫りにしています。それは、この技術が攻撃者の制御下にあるコンテンツをデータではなく指示として扱ってしまう可能性があるという点です。

ユーザーを狙うフィッシングからAIへのプロンプト操作へ

間接的なプロンプトインジェクション(IPI)は、より広く知られているAIシステムの「ジェイルブレイク」という概念とは異なります。

ジェイルブレイクは通常、誰かがチャットボットと直接やり取りし、その保護機構を回避しようとする行為を指します。これに対して間接的なプロンプトインジェクションは、AIアシスタントが通常の作業を行う際に遭遇する可能性のある素材の中に、悪意のある指示を埋め込みます。

その素材とは、メール、ウェブページ、アップロードされた文書、カレンダーの招待状、あるいは検索拡張生成(RAG)システム内のエントリなどが考えられます。攻撃者はAIインターフェースへの直接的なアクセスを必要としません。

あるテストでは、KnowBe4の研究者がフランス語の契約更新メールのHTML内に隠された指示を仕込みました。テキストの不透明度をほぼゼロに設定することで事実上見えないようにしていましたが、そのメールを処理するAIシステムからは参照可能な状態でした。

研究者らがGeminiのサイドバーにそのメールの翻訳を依頼したところ、正確な翻訳が生成されました。しかしそれと同時に、「Translation Verification Log(翻訳検証ログ)」と称するセクションも追加され、そこには受信ボックス内の無関係なメッセージから取得された2つのワンタイムパスコードが含まれていました。

サイドバーの制御機能により、情報が密かに送信されることは防がれました。抽出されたデータを含むURLは削除され、アシスタントが自律的にメッセージを送信することもできませんでした。そこで研究者らは、AIモデルが別のメール自動化ワークフローに接続された場合に何が起こり得るかを検証しました。

AI生成の下書きに隠されたパスコード

研究チームは、企業が受信確認の作成やサポート依頼の振り分け、メール返信の生成などに利用しそうな仕組みに似た、Google Apps Scriptのワークフローを作成しました。

このスクリプトは受信メールの内容を収集し、直近の受信ボックスのメッセージをコンテキストとして与えた上で、その情報をGemini APIに渡し、生成された応答をHTML形式の下書きとしてGmailに保存する仕組みでした。

その後、テスト用の受信ボックスに2通のメッセージが配信されました。1通には正規のワンタイムパスコードが含まれていました。もう1通は一見普通のセキュリティ通知に見えましたが、コンテキスト内の他の場所にある検証コードを見つけ出し、それをCSSのbackground-image URL内に埋め込むようモデルに指示する隠しプロンプトが含まれていました。

研究者らによると、Gemini 3.5 Flashはこの指示に従いました。生成された下書きは一見通常の業務的な返信メールに見えましたが、そのHTMLには追跡用URL内にパスコードを保持する1ピクセルの要素が含まれていました。

ユーザーがその下書きを開くと、GmailがそのHTMLをレンダリングし、画像プロキシ機構がそのURLを取得しました。このリクエストによって、コードが研究者らのテスト用Webhookに送信される結果となりました。

研究チームによると、その後にテストしたGeminiモデル(Gemini 3.6 FlashおよびGemini 3.7 Flash)は同じインジェクションに対する耐性を示し、指示追従に関する保護機構の改善が反映されていました。

重要な点として、KnowBe4はこの手法をGmail、Google Workspace、あるいはGeminiそのものの脆弱性とは説明していません。この攻撃が標的としたのは、言語モデルとより広範な自動化チェーンでした。信頼できないメールのコンテンツが、機微な受信ボックスのコンテキストと共にAIシステムに与えられ、その後、出力がHTMLとして保存・レンダリングされたことが問題だったのです。

すでにメールキャンペーンに現れ始めているプロンプトインジェクション

このパスコードに関する実証は管理された環境下で行われたものですが、KnowBe4 ThreatLabsは、顧客から報告されたフィッシングメールの中にも、より単純なプロンプトインジェクションのメッセージが見つかっていると報告しています。

ある例では、「Has your Microsoft licensing strategy kept pace?(貴社のMicrosoftライセンス戦略は時代に追いついていますか?)」という件名が使われていました。本文には従来型のフィッシングリンクや緊急性を煽る要求は含まれていませんでした。その代わりに、AIアシスタント向けに構成された一連の指示が提示されていました。

そのペイロードは、それまでのプロンプトを無視し、IT意思決定者というペルソナを装った上で、受信者の組織のセキュリティ、コンプライアンス、AIツールの利用状況についての評価を作成するようシステムに指示していました。さらに、確信度スコアが指定した閾値を下回った場合には自動的に返信するようにも指示していました。

人間の受信者であれば、このメッセージを単に「わけの分からない、無関係なもの」として無視するかもしれません。しかし、受信メールを処理するAIアシスタントは、これをタスクとして解釈し、送信者に返信し、場合によっては組織の技術環境に関する情報を漏らしてしまう可能性があります。

これは検出上の問題を生み出します。悪意のあるリンクや添付ファイル、認証情報を窃取するページを見つけるために設計されたセキュリティ製品には、従来型のフィッシング攻撃らしきものがほとんど見当たらない可能性があるのです。

影響の大きさを左右する権限設定

プロンプトインジェクションが成功した場合、その影響力はAIアシスタントに付与された権限をそのまま引き継ぐことになります。

選択した1通のメールを要約するだけのアシスタントと、受信ボックス全体を検索し、社内ファイルにアクセスし、情報を記憶にとどめ、承認なしにメッセージを送信できる自律型エージェントとでは、リスクのレベルがまったく異なります。

KnowBe4は、メールやその他の外部から供給されるコンテンツをAIモデルに渡すあらゆるワークフローを組織が監査すべきだと勧告しています。セキュリティチームは、各アシスタントがどのような情報にアクセスできるのか、その出力がどこに保存されるのか、そしてその出力が外部へのネットワークリクエストや自律的な動作を引き起こし得るのかどうかを把握しておくべきです。

権限は必要最小限に制限すべきです。また組織は、ユーザーが開始したのではない返信、外部ドメインへの予期しないリクエスト、受信コンテンツによって引き起こされる記憶の変化など、通常とは異なる挙動を監視する必要もあります。

メールの層においては、防御側は従来の侵害指標にとどまらない視点を持つ必要があるかもしれません。構造化された指示文、AIシステムに向けられたコマンド、そしてほぼゼロの不透明度やサイズゼロのフォント、白地に白文字といった隠蔽手法は、いずれも精査すべき対象となり得ます。

一方でユーザー側も、自分が要求していないセクションや動作、情報を含むAI生成の出力には注意を払う必要があります。

より広い教訓として言えるのは、確立されたワークフローにAIアシスタントを追加することが、そのセキュリティ境界そのものを変えてしまうということです。受信ボックスはもはや、人間が読むだけのコンテンツではありません。それは、データにアクセスし行動を起こすことができるソフトウェアにとっての、指示を伝える経路にもなり得るのです。

AIアシスタントがより自律的になっていくにつれ、組織はエージェントに入力される情報と、それに続く挙動の両方を保護していく必要があるでしょう。