Adversa AI、暗号化した命令でGrokのデータ外部送信を実証 Geminiでも安全ガードレールを回避|セキュリティとAIのニュース-セキュリティ対策Lab

投稿日時: 2026年08月25日更新日時: 2026年08月25日

セキュリティ企業Adversa AIは2026年8月20日、暗号化した悪意ある命令をAIのコード実行環境で復号させ、安全ガードレールを迂回する攻撃手法「Cryptographic Context Injection」を公表しました。

同社の検証では、xAIのGrokに外部Webページを要約させる場面で、ページ内に埋め込まれた暗号文をAI自身に復号させ、その結果を命令として処理させることで、ユーザー名、概算位置情報、契約プラン、会話中のユーザープロンプトなどを外部サーバーへ送信させることに成功しました。Google Geminiでは別の直接入力型の検証を行い、通常は拒否されるコンテンツ生成やシステム指示の再現につながる安全ポリシー回避を確認したとしています。

ただし、これはAdversa AIによる研究環境での実証です。実際のユーザー環境で同手法が悪用されたとの報告や、被害件数は公表されていません。また、GrokとGeminiで確認された影響は同一ではありません。

Cryptographic Context Injectionのサマリー

確認済み：Adversa AIは2026年8月20日、新たな攻撃手法「Cryptographic Context Injection」を公開しました。
確認済み：攻撃は、悪意ある命令を暗号文として入力し、AI自身のコード実行環境で復号させることで、通常の入力フィルターを通過させるものです。
確認済み：Grokでは、外部Webページを読み込ませる間接プロンプトインジェクションとして実証されました。
確認済み：Grokの検証では、ユーザー名、概算位置情報、契約プラン、会話中のユーザープロンプトなどを外部サーバーへ送信させることに成功したとAdversa AIは説明しています。
確認済み：GrokのPoCでは、外部送信の前に追加のユーザー確認や可視的な警告は表示されなかったとされています。
確認済み：Geminiでは、公開チャットのDeep Thinkingモードを対象に直接入力型の検証を行い、安全ポリシーで通常制限される出力やシステム指示の再現に成功したとしています。
確認済み：Adversa AIはxAIへ2026年6月3日に報告し、8月4日と10日にも連絡しました。8月19日時点でもGrokで再現可能だったとしています。
確認済み：xAIは報告を受領したものの、Adversa AIの公開時点で具体的な対応内容や修正時期は示されていませんでした。
確認済み：Adversa AIはGemini側の成功率が8月までに大幅に低下したとしていますが、フィルター更新、モデル変更など原因は特定できていません。
確認済み：Googleは、一般的なjailbreakや直接的なprompt injectionなどのコンテンツ関連問題をAI Vulnerability Reward Programの対象外としています。
未確認：実際の攻撃でCryptographic Context Injectionが悪用されたとの公表は確認できませんでした。
未確認：CVE番号はAdversa AIの公開資料では示されていません。
未確認：Grok側で8月20日以降に修正や追加対策が実施されたかは、公開一次情報では確認できませんでした。

項目	内容
公表日	2026年8月20日
研究者	Adversa AI / Rony Utevsky氏
攻撃手法	Cryptographic Context Injection
対象	xAI Grok、Google Gemini
攻撃の種類	暗号化された命令をコード実行環境で復号させるプロンプトインジェクション／jailbreak
Grokで確認された影響	セッション情報や会話中のユーザープロンプトを外部サーバーへ送信
Geminiで確認された影響	安全ポリシーで制限される出力の生成、システム指示の再現
Grokへの報告	2026年6月3日にxAIとHackerOneへ報告
Geminiへの報告	Googleには未報告
CVE	確認できませんでした
実攻撃での悪用	確認できませんでした
修正状況	Grokは8月19日時点で再現可能。Geminiは8月までに成功率が大幅低下

暗号文をAI自身に復号させ、ガードレールの後段へ持ち込む

Cryptographic Context Injectionのポイントは、暗号化そのものではなく、「安全フィルターが確認するデータ」と「AIが最終的に命令として処理するデータ」が異なる点です。

一般的な入力ガードレールは、AIへ渡されるテキストを解析し、有害な指示や既知のプロンプトインジェクションを検知します。一方、暗号文の状態では、元の悪意ある命令をそのまま読み取ることができません。

Adversa AIの手法では、暗号文と復号に必要な情報をAIへ渡し、AIに備わるコード実行環境で復号処理を行わせます。復号後の命令は、外部から入力されたテキストではなく、AI自身が実行したコードの出力としてコンテキストへ戻ります。

研究者は、この境界を問題視しています。外部の非信頼データとして入ってきた情報が、コード実行環境を通過したことで、AIから見て信頼度の高い内部結果のように扱われるためです。

従来のBase64や単純な換字式暗号などを利用したjailbreakとは異なり、今回の検証では強い暗号化を利用し、モデル自身の学習済み知識だけでは復号できない状態を作ることで、コード実行ランタイムを経由させています。

本記事では、実際に悪用可能な暗号文や復号処理、攻撃用プロンプトは掲載しません。

GrokではWebページ経由でデータ外部送信を実証

Grokに対する検証は、外部Webページを利用する間接プロンプトインジェクションとして実施されました。

攻撃者が用意したWebページには、暗号化された命令が配置されています。利用者がGrokに対してそのページを要約・分析するよう依頼すると、Grokがページを取得し、暗号文の復号処理をコード実行環境で行います。

Adversa AIによると、復号後の命令はGrokのセッションコンテキストから、ユーザー名、概算位置情報、契約プラン、現在の会話に含まれるユーザープロンプトを参照し、それらを外部URLのパラメータへ組み込みました。

その後、Grokが自ら外部URLへアクセスし、情報が研究者側のサーバーへ送信されたとしています。

検証では、この外部送信に対する追加確認や目立った警告は表示されなかったとされています。

ただし、「ゼロクリック」という表現には注意が必要です。利用者は攻撃用ページ上のリンクを自らクリックする必要はありませんが、Grokにページの要約や分析を依頼するという操作自体は必要です。「何もしなくても自動的に感染する」という種類の攻撃ではありません。

Geminiでは直接入力で安全ポリシー回避を確認

Geminiに対する検証は、Grokとは異なり、外部Webページを経由しない直接入力型のjailbreakです。

Adversa AIはGoogle Geminiの公開チャット、Deep Thinkingモードを対象に、暗号化されたデータをコード実行環境で復号させ、復号結果をGemini自身の処理結果のように扱わせる方法を試しました。

その結果、通常は安全フィルターによって拒否される種類のコンテンツを生成させることができたほか、別の検証ではGeminiのシステム指示を再現できたとしています。

研究者が検証した時点では、抽出されたシステム情報から対象モデルを「Gemini 3 Flash（Web）」と判断しています。

ただし、Adversa AIは8月までにGeminiに対する同手法の成功率が大幅に低下したと説明しています。研究者は、その理由について安全フィルターの更新、モデルバージョンの変更、または両方の可能性を挙げていますが、Googleからの公式説明はなく、原因は確認されていません。

そのため、「Geminiで現在も同じ条件で安定して回避できる」と断定することはできません。

GrokとGeminiで確認された影響は同じではない

今回の研究を「GrokとGeminiから同じ方法で個人情報が漏えいする脆弱性」とまとめるのは正確ではありません。

Grokでは、外部から取得した非信頼コンテンツ、コード実行、セッション情報へのアクセス、外向き通信という複数の機能が連鎖し、研究環境で実際のデータ外部送信まで確認されています。

一方、Geminiの検証は直接入力型で、安全ポリシーを回避したコンテンツ生成やシステム指示の再現が中心です。Adversa AIの公開資料では、GeminiからGrokと同様にユーザーの会話データを外部サーバーへ送信させたとはしていません。

この違いは、生成AIの安全性を評価するうえで重要です。モデル単体のjailbreakと、外部ツールや機密データへのアクセスを持つAIエージェントの侵害では、組織への影響が大きく異なります。

xAIには6月3日に報告、8月19日時点でもGrokで再現

Adversa AIは、Grokに対する問題を2026年6月3日にxAIへ報告し、同社のHackerOneプログラムにも同日提出したとしています。

xAIは報告を受領したものの、研究者によると、具体的な対応内容や修正スケジュールは示されませんでした。その後、Adversa AIは8月4日と10日にも連絡し、情報公開前日の8月19日時点でも攻撃を再現できたとしています。

8月20日の研究公開時点で、Adversa AIは実運用可能な攻撃ペイロードを公開せず、悪用を避けるため詳細を伏せています。

GeminiについてはGoogleへ個別の脆弱性報告を行っていません。GoogleはAI Vulnerability Reward Programについて、jailbreak、直接的なprompt injection、alignment問題などのコンテンツ関連問題は報奨金プログラムの対象外とし、製品内のフィードバック機能から報告するよう案内しています。

実際の攻撃や被害は確認されていない

Adversa AIが公表した内容は、研究者が管理するPoC環境での実証です。

公開資料では、第三者がCryptographic Context Injectionを悪用して実際のGrok利用者からデータを窃取した事例や、Gemini利用者に被害が発生した事例は示されていません。

また、今回の手法に対するCVE番号もAdversa AIの公開資料では確認できません。

そのため、「Grokからユーザーデータが大量流出した」「Gemini利用者の情報が漏えいした」といった表現は現時点では適切ではありません。

一方で、GrokのPoCではデータ外部送信まで成立しており、コード実行やブラウジング、外部API、業務データへのアクセスを組み合わせるAIエージェントでは、単なる不適切回答ではなく情報漏えいや不正操作につながる設計上のリスクとして扱う必要があります。

AIの入力フィルターだけでは防げない理由

今回の研究が企業のAI導入で重要なのは、禁止ワードや入力内容の検査だけでは十分ではないことを示している点です。

エージェント型AIでは、入力から最終的な操作までの間に、Web取得、メールや文書の読み込み、コード実行、データベース参照、API呼び出し、外部通信など複数の処理が入ります。

攻撃者の指示が最初の入力フィルターを回避した場合でも、本来は後段で「このデータは外部Webページ由来」「この引数は非信頼データから生成された」といった出所情報を保持し、機密情報や高権限ツールへ流れ込まないようにする必要があります。

Adversa AIは、今回の問題をモデルだけで解決するのではなく、AIエージェントを取り囲む実行基盤側で制御することを推奨しています。

セキュリティ対策Labでは、外部Webページなどに埋め込まれた命令をAIエージェントが処理してしまうリスクについて「AIエージェントを狙う間接的プロンプトインジェクション」でも解説しています。

また、Geminiで外部コンテキストからの命令がツール実行や情報漏えいにつながった別の研究については「Google、Geminiの「Gemini Trifecta」脆弱性を修正-プロンプトインジェクションで情報漏洩の恐れ」で取り上げています。

情報システム部門・AI導入担当への示唆

社内で生成AIやAIエージェントを導入している場合、今回の研究を「GrokやGemini固有の問題」として扱わないことが重要です。

外部Webページ、メール、チケット、GitHub Issue、文書など、第三者が内容を変更できるデータをAIへ読み込ませる機能がある場合、そのコンテンツはすべて非信頼入力として扱う必要があります。

特に、AIが同じコンテキスト内でコード実行、機密情報参照、外向き通信まで行える構成はリスクが高くなります。非信頼コンテンツの解析は、資格情報や高権限ツールを持たない分離された実行環境で行い、必要な結果だけを構造化データとして後段へ渡す設計が有効です。

外部通信についても、AIが任意のURLや新規ドメインへ自動接続できる状態を避ける必要があります。新しい送信先への通信、リポジトリへのpush、公開処理、外部システムへの書き込みなど、不可逆または組織外へ影響する操作ではユーザー確認を要求し、完全に自動化する場合は宛先や操作を許可リストで制限する方法が考えられます。

ログについては、ユーザーの入力とモデルの回答だけでは不十分です。AIがどのWebページやファイルを読み、どのコードを実行し、どのツールへどの引数を渡し、どの外部接続を行ったのかをセッション単位で追跡できるようにする必要があります。

また、単純な「暗号文を検知してブロックする」という対策だけでは不十分です。正当な暗号データも存在するため、Adversa AIも単一のパターンではなく、「非信頼コンテンツを取得した後にコードを実行し、その結果を使って新規の外部宛先へ通信する」といった一連の挙動を検知することを推奨しています。

AI製品を選定する際には、モデルの性能や安全フィルターだけでなく、外部データの出所を保持できるか、ツール実行前に引数の由来を判定できるか、外向き通信を制限できるか、管理者が詳細な実行ログを取得できるかといったエージェント基盤のセキュリティ機能を確認する必要があります。