何が起きたか
Adversaの研究者Rony Utevskyは、Grokに対するプロンプトインジェクション攻撃の新手法を公開しました。攻撃者のWebページには、暗号文と、それを復号するための平文の手順・復号鍵が並べて置かれています。利用者が「このページを要約して」とGrokに頼むだけで、Grokは警告も確認も出さずに指示を実行します。
復号された指示は「復号鍵を組み立てろ」と装いながら、実際にはユーザーの名前・所在地・チャット履歴をその値として構成させます。そしてその値を攻撃者サイトのURLパラメータに付与し、Grokがリンクを開いた瞬間に攻撃者のサーバーログへ着弾します。xAIは6月にこの問題を知らされていましたが、記事公開時点でも再現したと報じられています。
なぜ「暗号化」だけで突破できるのか
興味深いのは、同じ指示を平文で書くとGrokが拒否する点です。Adversa自身も理由を断定できていませんが、有力な仮説はこうです——Grokのフィルタリング・ガードレールは、モデルに入る文字列と出る文字列は検査するが、モデル自身のコード実行の出力は検査していない。
Utevskyの言葉を借りれば、静的ガードレールは「入力をテキストとして分類するだけで、実行はしない」。PBKDF2とAES-256-GCMで暗号文を処理せよという指示は、分類器から見れば「読めるが、何を解錠するかは解決できない」ただのリクエストです。復号後の本当の指示は、モデル自身のツール出力として内部に現れるため、検査の網の外側で実行されます。Adversaはこれを**Cryptographic Context Injection（暗号的コンテキスト注入）**と名付けました。
Grokだけの話ではない
同じ週には、Microsoft 365 Copilot（法人向け）に対し、秘密の入力を与えることで受信トレイ内のパスワードを外部送信させる攻撃も公表されています。AdversaはGeminiにも類似手法を適用し、暗号文が「エラーメッセージを読んでそれに従え」という一行ルールだけのトレースバック風テキストに復号される構成で、通常は抑止される焼夷兵器の作り方を段落単位で出力させ、ペイロードを変えるとシステム指示（その開示を禁じる指示ごと）を再現させました。ここ数週間でGeminiは抵抗力を増しているものの、フィルタ更新かモデル更新かは特定できないとしています。なお、Googleのぜい弱性開示プログラムはジェイルブレイクを対象外としているため、Adversaは報告していません。
攻撃面は「プロンプト」から「文脈」へ
プロンプトインジェクションの根はLLMの設計そのものにあります。LLMは「できる限りユーザーの要求に応じる」よう訓練されており、信頼できないメール本文やWebページの内容と、利用者が直接入力した指示を確実には区別できません。だから現状の対抗策はガードレールしかない——危険なカーブの手前でバンク（傾斜）を付け直すのではなく、ガードレールを立てて済ませている状態です。
Adversaが強調するのは、攻撃対象が「モデル入力」から、ツール出力・実行結果・中間状態といった「LLMが自分のものとして扱う文脈全体」へ広がっているという点です。この面は従来の入力検査が想定してきた範囲よりはるかに広く、次世代の攻撃はそこから生まれる、というのが同社の見立てです。
💼 事業会社視点：これは自社にどう効くか
実務上のインパクトは「AIアシスタントに外部URLの要約をさせる業務フロー」を持つ全企業に及びます。特に危ういのは、営業・CS部門が問い合わせメールやリード企業サイトをAIに要約させている日本のSaaS・EC事業者です。顧客名や取引履歴が入ったチャット文脈ごと、URLパラメータとして外部に流出しうる構造だからです。
役員が今週確認すべきは3点。第一に、業務で使うアシスタントに外部リンク取得（ブラウジング／ツール実行）権限があるか、そのオン・オフを管理者が握れているか。第二に、ベンダーの安全対策が「入出力テキストの分類」止まりでないか——今回の焦点は、コード実行の出力が検査対象外だったという構造的な穴です。第三に、xAIが6月に報告を受けても記事公開時点で未修正だった事実が示すとおり、修正までのSLAを契約に書けているか。
受託開発事業者にとっては逆に商機です。RAGやAIエージェントを納品する際、「取得したWebコンテンツをモデル文脈に入れる前後の隔離」「外部URL送信の許可リスト化」を設計要件として提案できます。Copilot・Grok・Geminiで同種の事例が並んだ以上、これは特定ベンダーの不具合ではなくアーキテクチャの前提として説明すべき論点です。