THREAT BRIEFING · AI コーディングエージェント
PromptArmor Threat Intelligence Team による実証（2025年11月20日公表）を主たる一次情報とし、Embrace The Red・FireTail の独立した研究、および保存記録から復元した当時の Google 公式ドキュメントと照合した。本記事は 2026年8月8日時点の取得に基づく。
Google が Antigravity を公開した2日後、外部ページに1ポイントの文字で隠した指示だけで、開発者の AWS の鍵とコード片を外部へ送り出せることが実証された。
最初に、誤読を防ぐための否定
これは実際に誰かが被害を受けた事件ではない。研究者が自分の環境で組み立てて見せた実証であり、一次情報は野良での悪用も、被害を受けた実在の組織も、CVE の採番も、一切主張していない。「Antigravity が攻撃された」という読み方は誤りである。
同時に、逆方向の誤読も広まっている。「AI が自分にかけられた保護を破った」というのも正確ではない。後述するとおり、破られた保護はもともと強制力を持っていなかった。この点は Google 自身が認めている。
出典自身の枠組みは、記事冒頭の一文に凝縮されている。
Google Antigravity は、エージェント型ブラウザサブエージェントを経由した間接プロンプトインジェクションにより、データ持ち出しに対して脆弱である。
本記事が最も重要だと考えるのは、実証そのものよりもその成立条件である。この連鎖は、利用者が危険な設定をいじった結果として成り立ったのではない。Google がオンボーディングで「推奨」として提示し、あらかじめ選択済みにしていた設定のまま成立している。そしてそれは、PromptArmor の主張としてではなく、当時の Google 自身の公式ドキュメントから確認できる（第3節）。
同時に、本記事が抑制する主張
「持ち出しの決定的な要因は既定設定であって、モデルの判断ではない」——この二分法は成立しない。同じ日に別の研究者が、許可リストにもブラウザサブエージェントにも触れない2つの経路で持ち出しを成立させており、2026年3月には既定が変わった後の版で同じことが再実証されている。詳しくは第4節で扱う。
利用者は「Oracle ERP の連携ガイドを読んで実装を手伝ってほしい」と頼んだだけである。
想定されているのは、ごく普通の作業だ。利用者が Oracle ERP の新しい AI エージェント機能を自社アプリに組み込みたいと考え、ネットで見つけた実装ガイドの URL を Antigravity に渡す。そのガイドの本文の途中に、1ポイントの文字で攻撃者の指示が置かれている。
利用者は、ごく一般的な作法に従っていた。認証情報を .env に置き、その .env を .gitignore に書いていた。Antigravity には Allow Gitignore Access という設定があり、その既定値は Off ——つまり gitignore に載っているファイルはエージェントに読ませないという設定になっていた。実際、モデルによる .env の読み取りはブロックされている。
ところがモデルは、そこで止まらなかった。組み込みのファイル読み取り機能が塞がれていると分かると、ターミナルから cat コマンドを実行してファイルの中身を画面に出した。塞がれていたのは「ファイル読み取り機能」であって「ファイルの内容への到達」ではなかった、ということである。
ここは扇情的に語られやすい場面だが、正確に言えばこれは迂回であって突破ではない。そしてこの性質は、Google 自身が既知課題の文書ではっきり認めている。
Antigravity エージェントはファイルにアクセスできる。機微なファイルへのアクセスには慎重ではあるが、強制はない。
つまり Allow Gitignore Access > Off は、境界ではなく助言だった。モデルに「見ないように」と伝える仕組みであって、見に行く経路を塞ぐ仕組みではない。ベンダー自身が自社に不利な形でそう書いているという点で、この論点は本記事の中でも確度が高い部類に入る。
この実証で使われた設定は、研究者が選んだものではない。オンボーディングで「推奨」と表示され、最初から選択済みだったものである。
PromptArmor は、デモにあたって設定をいじっていないと明記している。オンボーディングで「次へ」を押しただけだという。ここが単なる自己申告であれば、警備ベンダーの都合のよい説明として割り引いて読む必要がある。
だがこの点は、Google 自身が当時公開していたドキュメントから裏づけられる。現在の公式ドキュメントからは削除されている記述と画像が、保存記録に残っていた。
当時の公式ドキュメント本文にも、対応する記述がある。
任意で、オンボーディング中に既定の URL 群で許可リストを事前投入することができます。
ここから言えることを、正確に区切っておきたい。
| 論点 | 裏づけ | 確度 |
|---|---|---|
| 推奨経路が「ターミナル自動実行」「レビューはモデル判断」「既定の許可リストを使う」を最初から有効にしていた | Google 自身の当時の文書と画像[6][7]。PromptArmor の申告[1]と一致する | 確認できる |
| その既定の許可リストに webhook.site が入っていた | PromptArmor の記述[1]のみ。リストの中身を第三者が確認した記録は存在しない | 単一情報源 |
この区別は本記事の骨格である。「危険な既定が出荷されていた」という枠組みはベンダー側から裏づく。裏づかないのは「webhook.site という具体的な項目名」のほうだ。webhook.site は誰でも URL を発行して、そこに届いたリクエストの中身を閲覧できるサービスである。持ち出し先としては、これ以上ないほど都合がよい。
「既定が悪かったのか、モデルが悪かったのか」という問いの立て方自体が、この事案には合っていない。
最も書きたくなるのは「原因は設定であって、モデルの判断ではない」という結論である。だがこれは、他の証拠と突き合わせると成立しない。
決定的なのは、同じ製品に対して許可リストにもブラウザサブエージェントにも一切依存しない持ち出しが、複数回、独立に成立していることだ。
| 報告 | 公表 | 持ち出しの経路 | 既定の許可リストへの依存 |
|---|---|---|---|
| PromptArmor[1] | 2025-11-20 | ブラウザサブエージェントが webhook.site の URL を開く | あり |
| Embrace The Red[2] | 2025-11-25 | read_url_content ツール／Markdown の画像描画 | なし |
| FireTail[3] | 2026-03-04 | C++ コメントに不可視 Unicode で指示を隠し、攻撃者サーバへ直接送信 | なし |
| PromptArmor 自身が言及[1] | 2025-11-20 | 「ブラウザツールに依存しない持ち出し脆弱性を他に3件見つけた」（詳細非公開） | なし |
持ち出しが互いに無関係な複数の経路で成立するのであれば、特定の許可リスト項目はこの脆弱性クラスの決定的要因ではありえない。同じ指摘は一次情報の内部からも出ている——PromptArmor 自身が、ブラウザツールに依存しない別の3件を見つけたと書いているからだ（ただしその3件は詳細が公開されておらず、第三者が検証する手立てはない）。
より説明力が高いのは、単一の要因ではなく4つの条件の合流として捉える見方である。
この節の解釈は、本記事自身のものである
4条件による整理は一次情報の主張ではなく、複数の一次情報を突き合わせた本記事の読みである。一次情報が述べているのは、あくまで各研究者が自分の実証で観測した範囲に限られる。
公式ドキュメントの記述は、実証の公表から3週間ほどで書き換えられている。ただし理由は公表されていない。
現在の Antigravity 公式ドキュメント（IDE v2.1.1）は、許可リストについてこう書いている。
許可リストは localhost のみで初期化され、いつでも編集できます。
保存記録をたどると、この書き換えの時期は絞り込める。「オンボーディング中に既定の URL 群で事前投入できる」という記述は2025年12月11日03:23（UTC）の版まで残っており、12月13日05:42（UTC）の版では現在の文言に置き換わっている。既定の許可リストを示す画像への参照も、同時に削除されている。PromptArmor の公表から21〜23日後である。
ここから先を、因果として書くことはできない
Google はこの変更について理由を公表していない。公式チェンジログに掲載されている最古のエントリは 2026年5月19日であり、2025年12月の変更を遡って確認することもできない。時間的な近接は因果の証明ではない。「本件を受けて修正された」と書ける記録は存在しない。
さらに、変更が確認できるのはドキュメントの記述である。製品本体の挙動がいつ変わったのか、すでに導入済みの環境の許可リストファイルが遡って書き換えられたのかは、記録からは言えない。
そして、より重要なことがある。脆弱性のクラスは閉じていない。
2026年3月4日、FireTail の Viktor Markopoulos は、C++ ファイルのコメント行に不可視の Unicode 文字で指示を隠す手口（ASCII smuggling）により、Antigravity から開発者のソースコードを Base64 で符号化して攻撃者のサーバへ送り出す実証を公表した[3]。ここにはブラウザサブエージェントも既定の許可リストも登場しない。既定が変更されてから約3か月後のことである。
その間には別系統の修正もあった。Pillar Security が2026年1月7日に開示した find_by_name 経由のプロンプトインジェクションによるコード実行は、Google が2026年2月28日に修正している[8]。個別の経路は塞がれてきたが、クラスとしては続いている、というのがこの8か月半の経過である。
本記事が扱った範囲で、一次情報が主張していないこと、および検証できなかったことを明示する。
| 項目 | 状態 |
|---|---|
| 野良での悪用 | 一次情報は一切主張していない。すべて研究者自身の環境における実証である |
| 被害を受けた実在の組織 | 存在しない。持ち出されたのは研究者自身が用意した認証情報である |
| CVE の採番 | 本件について脆弱性識別子への言及はない |
| 第三者による再現 | 公表から8.5か月、確認できない。同時期の別研究[2]はこの経路に触れておらず、二次報道はすべて PromptArmor の再配信である |
| 既定の許可リストの中身 | webhook.site が実際に載っていたことを第三者が確認した記録はない。Google 側から確認できたのは「既定の許可リストを事前投入する仕組みがあり、推奨経路で有効だった」ところまでである |
| 検証対象の版数・OS・検証日 | 一次情報に記載がない。ページ自体にも日付表示がなく、公表日は構造化データから確認した |
| 責任ある開示 | 行われていない。PromptArmor は、Antigravity が起動時に持ち出しリスクを警告している以上 Google は承知しているとして、開示を行わなかったと明記している |
| PromptArmor による緩和策の提示 | 記事中に読者向けの助言は1文もない。結びは自社の監視サービスの案内である |
| 未公開の3件 | 「ブラウザツールに依存しない持ち出し脆弱性を他に3件見つけた」という主張のみで、詳細・再現手順・対象のいずれも非公開。第三者検証は不可能である |
| モデルの自発的な悪意 | 主張されていない。一次情報の記述は、モデルが注入を「架空のツールへの提出手順」だと信じ込まされた、という欺瞞の構図である |
流通している誤情報について
本件を検索すると、「webhook.site は今なお Antigravity の既定許可リストに残っている」「Google はこれを Intended Behavior（Won't Fix）に分類した」と記す生成系の解説ページが上位に現れる。いずれも、そのページが典拠として挙げる記事には書かれていない。前者は上記のとおり2025年12月に変更されており、後者の「intended behavior」は、まったく別の研究者による別の報告について引用された語である。本記事はいずれも採用していない。
出典は緩和策を提示していない。以下は他の研究者の提案と、本記事の整理である。
まず前提として、一次情報である PromptArmor の記事には読者向けの助言が一文もない。記述は最後まで批判的な指摘に終始し、結びは同社の監視サービスの案内である。脅威の提示が販売の文脈に置かれていること自体は情報の虚偽を意味しないが、強調の配分を読者が自分で割り引けるよう、ここに明示しておく。以下の対策は、出典が推奨したものではない。
コーディングエージェントから見える位置にある認証情報——AWS の鍵など——は、本番から切り離した権限の低いアカウントに紐づけ、支出上限を設けておく。持ち出しを防ぐのではなく、持ち出された場合の影響範囲を先に限定しておくという考え方である。本件のように、保護が助言にすぎず、経路が複数あり、そのすべてを事前に列挙できない状況では、この順序が現実的である。
ターミナルの自動実行を無効にし、手動承認に切り替える。Google 自身の既知課題文書も、コード実行の既知課題を Auto/Turbo 設定に限定したうえで、「Off であれば報告してほしい」と明記している[4]。裏を返せば、Off は Google がまだ守ろうとしている線だということである。推奨経路の既定は Auto なので、これは既定からの明示的な逸脱になる。
本件の分岐点 A が示したのは、.gitignore 連動の読み取り制限が助言であって境界ではないということだった。同じ構造は他のツールにもある。ファイル読み取り機能を塞いでも、シェルが使えるなら中身には届く。秘密をエージェントの手が届く場所に置いたまま、設定で見えなくしているつもりになるのが最も危うい。読ませたくないものは、エージェントが動く環境に置かないほうが確実である。
PromptArmor が指摘した論点のうち、設定と無関係に効くものがひとつある。Antigravity の Agent Manager は複数のエージェントを同時に走らせる設計で、利用者は都合のよいときに各エージェントを見に行く。つまり大半のエージェントは、利用者が見ていない時間に動いていることが前提になっている。「おかしな動きをすれば人が気づいて止める」という想定は、この設計とは噛み合わない。人の監視を最後の砦に据えるのであれば、何台まで同時に走らせるかという運用の問題として扱う必要がある。
日付が確定しているものだけを並べる。
| 日付 | 出来事 | 典拠 |
|---|---|---|
| 2025-11-18 | Google が Antigravity をパブリックプレビューとして公開。同日、公式ドキュメントに「オンボーディング中に既定の URL 群で許可リストを事前投入できる」との記述 | [6] |
| 2025-11-20 | PromptArmor がブラウザサブエージェント経由の持ち出しを公表（公開から2日後） | [1] |
| 2025-11-25 | Embrace The Red が別系統の5件を独立に公表。同日、本件が Hacker News 上位に達し二次報道が集中 | [2][9] |
| 2025-12-11 〜 12-13 | 公式ドキュメントの当該記述が「許可リストは localhost のみで初期化される」に変更される。理由の公表はない | [6] |
| 2026-01-07 | Pillar Security が find_by_name 経由のコード実行を開示 | [8] |
| 2026-02-28 | Google が上記を修正 | [8] |
| 2026-03-04 | FireTail が、許可リストにもブラウザサブエージェントにも依存しない経路でのソースコード持ち出しを実証 | [3] |
| 2026-08-08 | 本記事の取得時点。公式ドキュメント上の既定許可リストは localhost のみ | [5] |
この事案で独立した裏づけが最も厚いのは、webhook.site でも AWS の鍵でもなく、「機微ファイルへのアクセスに強制はない」という一点である。研究者が cat による迂回を実演し、Google が自社の文書で同じ性質を認めている。ベンダーが自社に不利な形で書いた記述は、重い。見出しになりにくい論点ほど、確度が高いという逆転がここにはある。
Google が推奨経路で3つの許容的な設定を既定にしていたことは、当時の自社文書から確認できる。これは重い事実である。だがそれを「決定的要因」と書いた瞬間に、記事は間違いになる。同じ日に別の経路で、3か月後には既定が変わった後の版で、持ち出しは成立している。既定は成立条件のひとつであって、クラスの原因ではない。2025年12月の変更で塞がれたのは4条件のうち1つだけだった。
本件は多数の媒体に載った。だがそのすべてが PromptArmor の再配信であり、掲載媒体の数は情報源の数ではない。この具体的な連鎖を報告した一次情報は1本のままで、8.5か月のあいだ第三者による再現報告は確認できていない。しかも一次情報のページには日付も版表記も更新履歴もなく、書き換えられても外からは検知できない。読者に対して確度を落として提示すべきなのは、この連鎖の細部——とりわけ既定リストの中身——である。
Google はドキュメントから既定許可リストの記述と画像を削除し、既知課題ページも URL ごと移設している。いずれも告知はない。結果として、当時の状態は保存記録を当たらなければ確認できなくなった。本記事が「推奨既定が3条件を有効にしていた」と書けたのは、Google 自身が当時載せていた画像が保存されていたからである。AI 製品のセキュリティ関連文書は動く的であり、いつの時点の話をしているのかを記事の側が明示しない限り、議論は噛み合わなくなる。