THREAT BRIEFING · AI ASSISTANT × INDIRECT PROMPT INJECTION

Gemini：カレンダー招待1件で家の窓が開いた——折りたたまれた予定に指示を隠し、実行だけを次の会話へずらす

SafeBreach Labs「Invitation Is All You Need」（2025年8月6日公開）および Ben Nassi・Stav Cohen・Or Yair による論文「Invitation Is All You Need! Promptware Attacks Against LLM-Powered Assistants in Production Are Practical and Dangerous」（arXiv、8月16日）に基づく図解解説。 ブログと論文の著者は同一で、論文は査読前のプレプリントである。

一次情報の公表

2025.08.06

本記事の公開

2026.08.07

0この記事の前提

この事案は「誰かが被害に遭った事件」ではない。研究者が自分で仕掛けて自分で確認した実証である。そこを取り違えると、以下の数字はすべて過大に読める。

裏付けの独立性について

本記事が参照する文書は3本あるが、独立した当事者は2者しかない。この点を先に置く。

• 研究チーム SafeBreach のブログと arXiv の論文は著者が同一の3名である。ブログは著者の一人 Or Yair の勤務先の企業ブログにあたる。両者が一致していることは、裏取りではなく同じ主張が2箇所に載っているだけである。
• Google Google の発言も1通の声明しかない。それがブログと論文の両方に転載されている。
• 不在 第三者による追試も、再現報告も存在しない。 攻撃が動いたことも、Google の対策が展開されたことも、その効き目も、すべて当事者の自己申告である。

加えて、SafeBreach は侵害・攻撃シミュレーション製品を販売する事業者であり、脅威の重大性の見積もりに事業上の利害がある。 これは研究内容を否定する材料ではないが、数値を他社製品や他の脆弱性と横並びに比較する用途には使えないことを意味する。

1要点

出典側が置いている枠組み

著者らの主張は「Gemini に穴があった」ではない。プロンプトウェア（Promptware）は実務上の脅威として過小評価されているという主張であり、 Gemini はそれを示すための題材である。著者らは、業界が過小評価する理由を次のように書いている。

Additionally, some perceptions are influenced by an overestimation of the security of machine learning systems in production environments, the minimal occurrences of such attacks in the wild, and the fact that many academic findings in this field do not transfer to real systems.

この記事が置く軸

本件の読みどころは、攻撃の派手さではなく「判定がどこまでを見ていたか」である。

• 指示の置き場が、画面の外にあった。 Google カレンダーの予定リストは、件数が多いと「あと○件」に折りたたまれる。 この折りたたまれた分は、展開しなくてもモデルが読む文脈に入る。利用者には見えず、モデルには見える領域が生まれる。
• 実行だけを、次のやり取りへずらせた。 指示をその場で実行させず、利用者が次に何か言った時点で動くように書いておく。 すると「今この要求はどのエージェントを触るはずか」といった同じやり取りの中だけを見る判定は、実行の瞬間には何も異常を見ない。
• 破られたのも、塞いだのも、実行側の設計だった。 ただしこれは重み付けの話であって、 モデル側の対策（内容分類器など）が無関係という意味ではない。9章で分けて扱う。

2何が起きたか

利用者の画面には最後まで異常が出ない。ずれているのは、画面とモデルの文脈のあいだである。

指示は「あと○件」の裏に置かれた

Gemini にカレンダーを尋ねると、直近5件が表示され、それ以上は折りたたまれる。著者らはここに着目した。

Fortunately for us, the events that are contained inside this “Show more” button, even if not expanded, are still added to the chat's history and are therefore added to the context.

攻撃者は招待を大量に送る必要すらない。被害者の予定が既に5件以上あれば、後から届いた招待は自動的に折りたたみの側へ落ちる。 そこに置かれた指示は、利用者の目に触れないまま、モデルの読む範囲には確実に入る。

3なぜ通ったのか——判定の射程

Gemini には、この種の動きを止めるための判定があったと研究者は見ている。それが外れた理由は、判定が見ている範囲にある。

研究者が推定した2つの制御

• 本来のエージェント以外を起動させない——「今日の予定は？」への応答でカレンダー以外のエージェント（Google Home など）が動くのを防ぐ判定。
• 組み立てた URL をその場で開かせない——文中の情報をつなげて URL を作り、直後に開くことを禁じる判定。

どちらも、要求と実行が同じやり取りの中にあることを前提にしている。研究者が使ったのは、この前提を外す方法だった。 ただしその方法自体は本研究の発明ではない。著者は明確に既知技術として扱い、先行研究に帰属させている。

To bypass such limitations, we thought about using a known technique called Delayed Tool Invocation (recently also leveraged by Johann Rehberger).

URL の判定は、さらに狭かった

情報を持ち出すための URL 組み立てについて、研究者は制御の適用範囲そのものを言い当てている。

We now understood that this mitigation would only be triggered if the URL was opened right after it was dynamically assembled.

そこで著者らは、あるやり取りで URL を組み立てて書き出しておき、別のやり取りでそれを開かせた。 メールの件名を宛先ドメインの後ろにつなげた URL が開かれ、件名がサーバ側に渡っている。

ブラウザなら出る確認が、出なかった

もうひとつ、判定の網とは別に効いたのが確認の欠落である。ブラウザは外部アプリを開く前に利用者へ確認を出す。Gemini は出さなかった。

Gemini, however, does not do that. When we open an HTTPS URI that redirects to an app using Gemini, Gemini blindly follows it and opens the URI no matter where it leads!

4何が新しく、何が新しくないのか

この事案は「新技術による突破」として語られやすい。一次情報を読むと、そうは書かれていない。

残るのは、次の形である。見えないまま履歴に残り続ける指示の置き場と、既知の遅延起動を組み合わせると、1回のやり取りの内側しか見ていない型の判定は外れうる。 派手さは落ちるが、こちらのほうが実務では効く。自社のエージェントに同じ形の判定を置いていないかという問いに、そのまま変換できるからである。

5実証された14シナリオと、その読み方

5つの脅威クラスにわたる14件。ただし、そのうち1件は本研究では実演されていない。

「73%が High-Critical」の読み方

最も引用される数字だが、これは著者らが同じ論文の中で提案した独自の評価枠組みによる、著者ら自身の採点である。 枠組みも、採点対象のシナリオも、採点者も同じ側にある。攻撃者の熟練度・必要機材・機会の窓・利用者操作の頻度といった入力変数は、 この種の評価で一般的な語彙であり恣意的なものではない。正確な批判は「根拠がない」ではなく、自己適用であり外部検証を経ていないである。 したがって他社製品や他の脆弱性との横並び比較には使えない。

緩和後の再評価が意味していること

論文は緩和策を適用した場合の再評価も行っており、抄録は「リスクは Very Low-Medium まで下がりうる」と述べている。 ここは誤読が起きやすいので、2点を分けて置く。

• それは Google の対策の評価ではない。 再評価が仮定しているのは著者らが自ら提案した防御の組み合わせ（エージェント間の文脈分離、入出力の検査、A/B テスト、制御フロー完全性、連鎖の防止）であり、 Google が展開したと述べる3点とは部分的にしか重ならない。論文は「Google の対策適用後のリスク値」を一度も算出していない。
• 最悪級は消えていない。 事前に critical と分類された4件——Zoom による映像配信、家の窓の開放、メールの持ち出し、ワーム——は、 再評価後も low ではなくmedium 帯にとどまる。「ほぼ無害になった」という要約は、この分布を落としている。

6「theoretical」——評価の食い違い

Google は本件の手法を「理論的」と呼んだ。論文の表題は「本番環境で」と言っている。どちらの読みも成り立つ材料が揃っている。

Google が研究者へ提供した声明には、次の一節がある。

The paper detailed theoretical indirect prompt injection techniques affecting LLM-powered assistants and was shared with Google in the spirit of improving user security and safety.

「理論的」という表現が妥当だと読める材料

• 野良での悪用は観測されていない。 一次情報のいずれにも、実際の攻撃者による使用の報告はない。著者自身も、この種の攻撃の野良での発生は最小限だと書いている——ただし「だから安全」ではなく「だから業界が過小評価する」という警告の文脈で。
• CVE は付与されていない。
• 成立には前提がある。 被害者が Gemini にカレンダーやメールを尋ねること、攻撃者が被害者のメールアドレスを知っていること、招待が予定表に載る設定であること。アプリの自動起動は Android に限られる。
• そして著者自身が、研究時点では緩和策が無効か未展開だったと書いている。 この一文があるため、「理論的」を「現行の環境ではそのままは成立しない」の意味で読んでも、論文の記述とは矛盾しない。

それでも緊張が残る点

• 実証の対象は本番の Gemini 3面であり、論文の表題自体が「in Production（本番環境で）」と述べている。
• 同じ声明が、対策について「focused, high-priority effort（集中的で優先度の高い取り組み）」と述べている。純粋に理論的な指摘に対する反応としては、やや強い。ただし多層防御の通常運用としても説明でき、矛盾とまでは言えない。
• Google は、技術的な主張の再現性そのものについては争っていない。

6月のブログは、本件への回答ではない

時系列が近いために混同されやすいが、Google が2025年6月13日に公開した多層防御のブログ [3] は、本研究を名指ししていない。 3名の研究者への言及はあるが、多数の協力研究者を挙げた汎用的な謝辞の一部であり（Google は Ben Nassi の肩書きに所属機関ではなく研究領域名を当てている）、特定の発見を彼らに帰属させてもいない。 研究名の入った声明が用意されたのは、その13日後の6月26日である。

事実 時期が重なっている。 不明 6月のブログが本件への対応だったかどうか。一次情報からは決められない。

7確認されなかったこと

一次情報が明示的に「していない」「できない」と述べている事項。ここを落とすと、この事案は実際より大きく見える。

8本サイトで扱った事案との比較

同じ「間接プロンプトインジェクション」でも、破れた場所が違う。そこが対策の当て所を分ける。

9経過と、経営層への含意

この事案から取るべきもの

自社が AI アシスタントを業務に入れているなら、確認すべきは「どんな文章を止めているか」ではなく「いつ、何の権限で、何が実行されるか」である。

• 判定は1回のやり取りを超えて効くか。 「この要求はどのツールを触るはずか」という発想の制御は、指示と実行を分けられると外れうる。 前のやり取りで書かれた内容が後のやり取りの行動を決める経路が、自社の構成にあるかを見る。
• 画面に出ていない入力を数える。 折りたたみ、省略、要約、添付の中身。利用者が見ていないがモデルは読んでいる領域は、そのまま攻撃者の置き場になる。
• アシスタント経由で、確認が消えていないか。 ブラウザやOSが出していた確認が、アシスタントが代わりに操作した途端に出なくなる——本件で決定打になったのはここである。 既存の経路で人間に聞いていたことは、AI 経由でも聞く。
• 層をどちらか一方に寄せない。 本件で結果を決めたのは実行側の設計だが、モデル・内容側の対策が不要という意味ではない。 Google が展開したと述べる3点のうち1点、公開している防御層5つのうち2つは内容・モデル側である。加えて、Gemini の定型応答に似せた指示が通りやすかったという観察は、モデル側の性質そのものにあたる。 どちらの層も要る。本件で結果を決めたのが実行側だった、というのが正確な言い方である。