カレンダー招待1通で全パスワードが盗まれた——Perplexity Comet乗っ取りが突きつける問い

AIエージェントが「代わりにやってくれる」時代が始まった。ファイルを開き、メールを読み、パスワードを入力する——人間が繰り返してきた操作を、AIが引き受ける。だがその便利さの裏に、従来のセキュリティの前提を根底から覆す構造的な穴が見つかった。カレンダーの招待状1通が、その入口だった。

事実何が起きたか

セキュリティ企業Zenity Labsは、Perplexityのエージェント型ブラウザ「Comet」に、カレンダー招待などの外部コンテンツ経由でユーザーのローカルファイルや1Passwordの認証情報を窃取できる脆弱性群「PleaseFix」を発見・開示した。

読み解きなぜ重要か

AIエージェントに「代わりに操作させる」利便性が高まるほど、乗っ取られた場合の被害がユーザーの全権限に及ぶという逆説は、従来のブラウザセキュリティ（同一オリジンポリシー、CORS等）が想定していなかった脅威モデルの出現を意味する。

影響何が変わるか

この脆弱性はPerplexity固有のバグではなく、AIエージェントがユーザーの権限を継承して自律的に操作する設計そのものに内在する構造的リスクであり、エージェント型ブラウザ市場全体のセキュリティ前提が問い直される。

Overview

Zenity Labsが「PleaseFix」と名付けた脆弱性群をPerplexity Cometで発見し、2026年3月3日に公開した。
攻撃者はカレンダー招待に隠し指示を埋め込み、Cometにローカルファイルの読み取りや1Passwordの認証情報窃取を実行させることができた。
Zenity CTOは「これはバグではなく、エージェント型システムの本質的な脆弱性だ」と断定した。
Perplexityは2026年1〜2月にパッチを適用し、Brave等の競合も同種のリスクに対する独自分析を公開した。

「便利にした分だけ攻撃面が広がる」は、エージェントAIの宿命か

「バグ」ではなく「設計」の問題

今回の脆弱性が厄介なのは、修正しても終わらないところにある。Perplexityは2度パッチを当てた。1度目は迂回され、2度目で塞いだ。だが、Zenity LabsのCTO Michael Barguryは「これはバグではない。エージェント型システムの本質的な脆弱性だ」と断定している。

構造を整理する。従来のブラウザには「同一オリジンポリシー」という境界線があった。ウェブサイトAのコードがウェブサイトBのデータを勝手に読むことはできない。この「壁」が30年間、ウェブの安全を支えてきた。ところがAIエージェントブラウザは、この壁を無意味にする。エージェントはユーザーの指示に従ってサイトを横断し、ファイルを開き、パスワードマネージャーを操作する。それが「便利さ」の正体であり、同時に攻撃者が利用できる経路でもある（Brave分析）。

カレンダー招待が「武器」になる世界

攻撃の手口は驚くほど単純だった。Googleカレンダーの招待状に、人間には見えない隠し指示を埋め込む。ユーザーがCometに「この予定を確認して」と頼んだ瞬間、エージェントは隠し指示を「ユーザーの意図」と区別できず、ローカルファイルの読み取りや1Passwordの認証情報の窃取を黙々と実行する。ユーザーには正常な応答が返る。裏で何が起きているかは見えない。

注目すべきは、攻撃者がヘブライ語の指示を使うとAIの安全ガードレールをより効果的に迂回できたという報告だ。AIの多言語対応が、そのまま多言語の攻撃経路になる。能力の拡張が脆弱性の拡張と表裏一体であることを象徴している。

1Passwordとの提携が攻撃を「完成」させた

この脆弱性の深刻さを決定づけたのは、皮肉にもPerplexityと1Passwordの連携だった。Zenityの研究者がこの攻撃経路を調査し始めたきっかけ自体が、両社のパートナーシップ発表だったと報じられている。パスワードマネージャーとの統合は「毎回パスワードを入力する手間をAIが省く」という利便性のためにある。だがそれは同時に、エージェントが乗っ取られた瞬間、攻撃者がユーザーの全認証情報にアクセスできることを意味する。

ここに構造的な矛盾がある。AIエージェントは「信頼できる代理人」として設計されている。だがセキュリティの観点では、エージェントは「信頼できないエンティティ」として扱わなければならない。Perplexity自身もパッチ後にエージェントを「信頼できないエンティティ」として扱うコードレベルの制限を導入した。つまり、「信頼してください」と売りながら「信頼するな」と設計しなければならない。この矛盾は、Perplexityだけの問題ではない。

「ClickFix」から「PleaseFix」へ——攻撃対象が人間からAIに移った

先週配信した記事で、AIエージェントの自律性に組み込まれた構造的な脆弱性を取り上げた。研究レベルの問題提起だった。今回のPleaseFixは、それが実環境で具体的な攻撃チェーンとして成立することを証明した事例になる。

→ AIエージェントは暴走した、そして誰もブレーキを持っていなかった——2つの研究が暴く自律性の構造的代償

Zenityはこの脆弱性群を「PleaseFix」と名付けた。既存の「ClickFix」——ユーザーをだましてクリックさせるソーシャルエンジニアリング——との対比だ。ClickFixは人間を騙す。PleaseFixはAIを騙す。攻撃対象が人間からAIエージェントに移ったことで、ソーシャルエンジニアリングの構造そのものが変容している。

人間を騙すには、それなりの心理的テクニックが必要だった。フィッシングメールの文面を整え、緊急性を演出し、判断力が鈍る瞬間を狙う。だがAIエージェントには「疑う」能力がない。指示と情報の区別がつかない。隠し指示を見えないように埋め込むだけで十分だ。結果として、攻撃の技術的ハードルは下がり、被害の範囲はユーザーが渡した権限の総量に比例して拡大する。

この構造は、エージェント型AIが便利になればなるほど強化される。権限を多く渡すほど、多くのことを「代わりに」やってくれる。そして、乗っ取られたときの被害も、渡した権限の分だけ大きくなる。便利さと攻撃面の等価交換——これがエージェントAI時代のセキュリティの出発点になる。

→ 1.41ドルで匿名が剥がれる——あなたの別名アカウントはもう安全ではない

考える問い

あなたがAIツールに渡している権限（ファイルアクセス、メール閲覧、パスワード管理）を一覧にしたことはあるか。その権限が第三者に渡った場合、どの程度の被害が発生するか把握しているか。
カレンダー招待、メール、ドキュメント——日常的に受け取るコンテンツがすべて攻撃経路になりうる世界で、「AIに任せる」と「自分で確認する」の境界線をどこに引くか。
従来のブラウザセキュリティ（同一オリジンポリシー等）が30年かけて築いた防御が、AIエージェントの登場で無効化されつつある。次の30年のセキュリティの基盤は、誰がどのように設計すべきか。