AIブラウザ（エージェントブラウザ）——Perplexity の Comet、OpenAI の ChatGPT Atlas に代表される、AIが「見るだけでなく操作する」ブラウザが2025〜26年に一気に広がりました。ページを要約するだけでなく、リンクをクリックし、フォームに入力し、ログイン済みのサービスを横断して作業をこなす。便利さの裏で、セキュリティ研究者からは「Webの信頼モデルを根底から崩す」と強い警告が出ています。
OpenAI 自身が「プロンプトインジェクションは、詐欺やソーシャルエンジニアリングと同様、完全に“解決”されることはおそらくない」と述べ（2025年12月）、Gartner は企業に対し「セキュリティが成熟するまで利用をブロックすべき」と勧告しました。本記事は、なぜAIブラウザが危ないのか、実際に成立した乗っ取りの具体例、そして使う側がとるべき防御を整理します。
根本原因：間接プロンプトインジェクション
AIブラウザの弱点は、ほぼ一点に集約されます。「ユーザーの指示」と「Webページの中身」を区別せずに、まとめてAIへ渡してしまうことです。
Brave の分析によれば、ユーザーが「このページを要約して」と頼むと、Comet はページの内容をそのままLLMへ送り込み、どこまでが利用者の指示で、どこからが信頼できないページ由来かを区別しない。つまり攻撃者は、ページの中に「AIへの命令」を仕込んでおくだけで、AIをその通りに動かせます。これが間接（インダイレクト）プロンプトインジェクションです。
命令は人間に見えない形で隠せます——白背景に白文字、HTMLコメント、Redditのネタバレ（spoiler）タグなど。人は気づかず、AIだけが読みます。しかも、攻撃者が直接管理していないユーザー投稿（コメント欄やレビュー）にも仕込めるため、攻撃面は極めて広くなります。
実例1：要約ボタン一つで乗っ取られる（Brave のPoC）
Brave が公開した実証では、攻撃の起点はなんとReddit のコメントでした。流れはこうです。
- 攻撃者が、ネタバレタグで隠した指示を含むコメントを Reddit に投稿しておく。
- 被害者がそのページで Comet の「現在のページを要約」ボタンを押す。
- Comet は隠された指示を正規の命令として解釈し、次を自動実行する：
- ユーザーの Perplexity アカウントページへ移動し、メールアドレスを取得。
- 細工したドメイン（末尾ドットの悪用）にアクセスしてワンタイムパスワード（OTP）の送信をトリガー。
- ログイン済みの Gmailを開いて、届いた OTP を読み取る。
- 取得したメールアドレスと OTP を、元の Reddit スレッドに投稿して攻撃者へ送信。
被害者がしたのは「要約ボタンを押した」ことだけ。にもかかわらず、多要素認証を含むアカウント乗っ取りが完結します。OTP すら、AIが本人のログイン済みメールから読み取ってしまうため、TOTPベースのMFAでは防げません。
実例2：ゼロクリック乗っ取り（Zenity の PleaseFix / CometJacking）
Zenity Labs は2026年3月、PleaseFix と名付けた一連の重大脆弱性を公表しました。要約ボタンすら不要なゼロクリックの手口です。
- カレンダー招待を悪用：悪意あるプロンプトを仕込んだ正規のカレンダー招待を送るだけ。AIブラウザが予定を読み込んだ瞬間に指示が発火し、ローカルファイルシステムへアクセスし、ディレクトリを辿り、ファイルを読んで外部サーバへ送信した。
- パスワードマネージャの乗っ取り：ユーザーが 1Password 等にログイン済みなら、AIブラウザも同じ権限を持つ。攻撃者は間接プロンプトで設定やパスワードを密かに変更し、シークレットを抽出しながら、画面上は「無害な応答」だけを返させることができた。
- CometJacking：LayerX は、隠れた MCP API を悪用して1クリックで Comet を“裏切らせる”手口を報告。Zenity も同様に、隠れたコマンド実行経路の存在を指摘している。
これらは個別バグとして修正されていますが、Zenity は「個別パッチでは終わらない、エージェントブラウザに内在する構造的リスク」だと結論づけています。
なぜ Same-Origin Policy も CORS も効かないのか
ここがAIブラウザ最大の論点です。従来のブラウザは、Same-Origin Policy（SOP）と CORSによって「あるサイトのスクリプトが、別オリジン（別サイト）のデータに勝手に触れない」よう厳格に隔離してきました。Webセキュリティはこのオリジン分離を土台に組み立てられています。
ところがAIブラウザのエージェントは、ユーザー本人として、すべてのタブ・すべてのログイン済みセッションを横断して動きます。Gmail も銀行も社内SaaSも、本人の権限で正規にアクセスできる。Brave の言葉を借りれば、「SOP や CORS は事実上、無意味になる」。攻撃者は一つのサイトに命令を仕込むだけで、AIを介して本来は触れないはずの別オリジンのデータに到達できてしまうのです。
構図は MCP のセキュリティ と同じ根を持ちます。「外部から受け取ったコンテンツを、そのままAIの“指示”として扱う」——この信頼境界の崩壊が、AI時代に共通する脆弱性です。
図解案：AIブラウザの信頼境界
【従来ブラウザ】 オリジンごとに隔離（SOP/CORS）
サイトA ┊ サイトB ┊ Gmail ┊ 銀行
└─ 互いに直接アクセス不可（壁あり）
【AIブラウザ】 エージェントが本人として全部を横断
サイトA(攻撃者の命令を仕込む)
│ 間接プロンプトインジェクション
▼
[AIエージェント] ── 本人の権限 ──┬─▶ Gmail（OTP読取）
▲ ├─▶ 1Password（秘密抽出）
│ ページ内容=指示として混入 └─▶ 任意サイトへ送信(窃取)
└ 「壁」が消える ＝ SOP/CORS 無効化使う側・守る側の対策
Brave が提案する設計レベルの防御
- 入力の分離：ユーザーの指示とページの中身を明確に分け、ページ由来は常に「信頼できない入力」として扱う。
- 出力の検証：AIの行動が、本当にユーザーの依頼に沿っているかを実行前に独立して検査する。
- 機微な操作のゲート：メール送信・認証情報へのアクセス・送金など重要操作は、実行直前に毎回ユーザーの明示確認を求める。
- モードの分離：エージェント機能を通常閲覧から隔離し、視覚的にも区別して、何気ない閲覧中に誤発動しないようにする。
利用者・企業がいま取れる現実的な対策
- 機微なアカウントと同居させない：AIブラウザで Gmail・銀行・パスワードマネージャにログインしたまま使わない。エージェント用と日常用でブラウザ／プロファイルを分ける。
- 自動実行の権限を絞る：エージェントに「確認なしで操作させる」設定を避け、機微な操作は人間承認必須にする。
- 信頼できないページでエージェントを動かさない：掲示板・コメント欄・知らないサイトで「要約して」「手伝って」を不用意に使わない。
- 企業はポリシーで制御：Gartner の勧告どおり、業務端末では当面用途を限定するか利用を制限し、エージェントのアクセス範囲・ログ・データ持ち出しを監視する。
- 認証を強くする：OTP を読み取られても被害が出にくいよう、フィッシング耐性のある FIDO2/Passkeyや、重要操作の追加確認を組み合わせる。
まとめ
AIブラウザの危険性は、特定のバグというより「AIが本人として全オリジンを横断する」という設計そのものに根ざしています。間接プロンプトインジェクションは、ClickFixのような人間を騙す攻撃と違い、AIを騙して本人の権限を乗っ取る。だからこそ SOP/CORS という従来の壁が効かず、OpenAI 自身が「完全には解決できない」と認めています。
当面の合言葉は「便利さと権限を切り分ける」。機微なログインと同居させない、機微な操作は人間が承認する、信頼できないページでエージェントを走らせない——この3点を守るだけで、最悪の乗っ取りはかなり避けられます。同じ「外部入力＝指示」の問題は MCPのセキュリティ や Langflowの事例 にも通じるので、AIを業務に組み込む前に合わせて押さえておくと安全です。
※ 本記事の脆弱性名・PoC・各社の見解は、Brave／Zenity Labs／LayerX 等の公表内容および報道に基づきます。各製品は対策が日々更新されるため、利用時は最新の公式情報をご確認ください。