AmazonとGoogleのブラウザエージェント、完璧な解決策のないプロンプトインジェクション問題に直面

AmazonとGoogleのブラウザエージェントはいま、同じジレンマに直面している。自律性が高まるほど、プロンプトインジェクション攻撃が被害を及ぼす余地も広がる。新たな保護策が導入されているにもかかわらず、研究者は通常のWebページ、メール、フォーム、ソーシャル投稿を通じてエージェントを誘導する手法を見つけ続けている。この弱点は、単一のパッチで解消できる通常のブラウザバグではなく、AIブラウザ設計における恒常的な制約になりつつある。

差し迫った懸念は、AIエージェントが読むコンテンツ内に悪意ある指示が隠される間接プロンプトインジェクションだ。こうした指示はユーザーの依頼と競合し、エージェントの次の行動に影響を与え得る。従来のブラウザは悪意あるコンテンツを表示するだけだが、エージェント型ブラウザはそれを解釈し、別のサービスへ移動し、ユーザーの権限で行動できる。

この違いにより、AmazonとGoogleは、Microsoft、OpenAI、Anthropic、Perplexity、専門のブラウザベンダーを巻き込む、より広範なセキュリティ競争の中に置かれている。各社はWeb全体で有用なタスクを完了できるエージェントを目指している。しかし、追加される権限の一つひとつが、エージェントが従うべき相手を誤認した際の影響を拡大する。

不穏な結論は、ブラウザエージェントが使い物にならないということではない。ベンダーがプロンプトインジェクション検出を完全なセキュリティ境界として扱えない、ということだ。企業は、何らかの悪意ある指示がすり抜けることを前提に、侵害されたエージェントが到達、変更、開示できる範囲を制限しなければならない。

AmazonとGoogleのブラウザセキュリティ競争で何が変わったのか

プロンプトインジェクションは、理論上のモデル弱点から、運用上のブラウザセキュリティ問題へと移行した。

セキュリティ研究者は、従来のコード実行経路を悪用せずに、悪意あるコンテンツがエージェントを別の方向へ誘導できることを繰り返し示してきた。攻撃者が狙うのは、モデルによるコンテンツの解釈だ。隠された指示は、Webページ、メール、文書、さらにはユーザーインターフェース要素にも現れ得る。

エージェントが認証済みのブラウザセッションを利用できる場合、攻撃は深刻になる。受信トレイを読み、別のタブを開き、フォームを送信し、接続済みサービスから情報を取得する可能性がある。通常のタスクでは便利に見える行為が、攻撃チェーンの有用な構成要素になり得る。

Zenityの研究者は、このより広い種類のエージェント型ブラウザの弱点をPleaseFixと表現した。テストでは、Webサイトやローカルリソース間を移動する際に、エージェントが自然言語の目標に従う仕組みを対象とした。ブラウザセキュリティに関する調査結果によると、研究者は設計や保護策の違いを確認した一方で、商用エージェント型ブラウザ全体で攻撃経路を特定した。

重要な変化は、攻撃者の経路にある。従来のブラウザ攻撃は、多くの場合、ソフトウェアの脆弱性、悪意ある拡張機能、盗まれた認証情報、または欺瞞的なクリックに依存する。プロンプトインジェクションは、エージェントが通常の依頼の中で処理することを期待されていたコンテンツから始まり得る。

ユーザーはアシスタントに商品ページの要約を依頼するかもしれない。そのページには、視覚的には隠されていてもモデルには利用可能な指示が含まれている可能性がある。攻撃者は、公開投稿、ニュースレターフォーム、ブラウザツール経由で取得されるコンテンツにも指示を埋め込める。

これは、注入されたすべての指示が成功することを保証するものではない。モデル、分類器、権限システム、アクションチェックによって、多くの試みを阻止できる。しかし、こうした制御は、文言、見せ方、タイミング、文脈を変化させられる適応的な敵対者を相手に機能する必要がある。

Google自身の測定結果も、この変化を裏付けている。同社のセキュリティチームは、既知の間接プロンプトインジェクションパターンについて公開Webコンテンツをスキャンし、2025年11月から2026年2月にかけて、悪意ある検出件数が相対的に32%増加したと報告した。同社はまた、攻撃に似た無害なテキストも相当量見つかったとしており、信頼性の高い分類を複雑にしている。

このWeb脅威に関する研究が重要なのは、ブラウザ防御が相反する二つの誤りに対処しなければならないからだ。悪意あるコンテンツを見逃せば、エージェントは操作され得る。過度に積極的にブロックすれば、通常のページや正当な指示が利用不能になる。

Amazonは、大衆向けブラウザではなく、クラウドエージェントプラットフォームを通じてこの問題に取り組んでいる。Bedrock AgentCore Browserは、サイトの閲覧、フォームの完了、情報の抽出を行うエージェント向けに、隔離された環境を開発者へ提供する。基盤となるブラウザセッションが隔離されていても、こうした機能はエージェントを信頼できないコンテンツにさらす。

したがってAmazonとGoogleの比較は、二つの異なる配布モデルを反映している。Googleは人々が直接利用するブラウザにエージェント機能を追加している。Amazonは、企業が独自のブラウザ自動化を構築するためのインフラを提供する。両社とも、オープンWeb上のコンテンツと特権を持つエージェントの行動との衝突を管理しなければならない。

ブラウザエージェントが古いセキュリティ境界を弱める理由

中核的な弱点は、一つのモデルが共有された推論プロセスを通じて、信頼された指示と信頼できないデータを受け取るときに現れる。

Webブラウザは何十年もかけて、Webサイト同士を分離してきた。同一オリジンポリシーは一般に、あるオリジンが別のオリジンから機密情報を自由に読み取ることを防ぐ。サンドボックス、権限プロンプト、プロセス分離、コンテンツセキュリティポリシーが、さらなる障壁を加えている。

AIエージェントは、ユーザーがタスク実行を許可することで、こうした境界をまたげる。一つのページを読み、別のサービスを参照し、結果を組み合わせることができる。この能力は製品の中心的な利点だが、同時に悪意あるコンテンツが制御を試みる橋渡しにもなる。

モデルが同一オリジンポリシーを直接破る必要はない。ユーザーに利用可能な正規のブラウザ機能を使えるからだ。悪意あるページがエージェントを説得して受信トレイを開き、メッセージを読み、情報を送信させた場合、個々の手順はすべて認可済みに見える可能性がある。

これはしばしば「混乱した代理人問題」と呼ばれる。信頼されたコンポーネントには正当な権限があるが、攻撃者がそれを操作し、誤った目的のためにその権限を使わせる。ブラウザエージェントは、この代理人を会話的、確率的、かつ複数ステップの計画が可能な存在にする。

オープンソースのブラウザエージェントに関する研究では、このパターンが認証情報の露出や不正な操作につながる可能性が示されている。ある学術研究は、ブラウザ自動化フレームワークにおけるプロンプトインジェクション、ドメイン検証の回避、認証情報の流出を報告した。そのブラウザエージェント分析には、開示済みの脆弱性と動作する概念実証も含まれていた。

エージェントがタスク間で記憶を保持する場合、問題はさらに大きくなる。悪意ある指示は、必ずしも即時の被害を引き起こす必要はない。保存された文脈を改変したり、誤解を招く設定を作成したり、機密リソースが利用可能になった後の判断に影響を与えたりする可能性がある。

視覚理解は別の経路をもたらす。スクリーンショットを解釈するエージェントは、画像やインターフェース要素に埋め込まれた指示に遭遇する可能性がある。生のページテキストだけをフィルタリングしても、マルチモーダルモデルが知覚できるすべてのメッセージを捕捉できるわけではない。

攻撃者は、「以前の指示を無視する」といった明白な表現も避けられる。悪意ある手順を、ユーザー本来の目的に必要な一部として見せかけることができる。たとえばニュースレターへの登録依頼は、データ取得や別のツールを開くための口実になり得る。

この手法が重要なのは、多くの防御がユーザーの目標と悪意ある指示との衝突を探すからだ。攻撃者は代わりに、悪意ある行動をその目標と整合しているように見せかけられる。文言は不審でなくなっても、求められる機能は危険なままだ。

プロンプトインジェクションは、SQLインジェクションと一つの重要な点で異なる。ソフトウェアは、厳格な構文とパラメータ化クエリによって、SQLコマンドとデータを分離できる。自然言語エージェントは文脈的な解釈に依存するため、指示と情報の間に明確な技術的境界が常に存在するわけではない。

構造化メッセージと来歴ラベルは、この分離を改善できる。開発者は、どのコンテンツがユーザー、Webページ、ツール、アプリケーションから来たものかを示せる。しかし、タスクが外部コンテンツの意味に依存する場合、モデルは依然としてそれを解釈する必要がある。

BrowseSafeとして発表された研究は、ブラウザエージェント内のプロンプトインジェクションリスクを評価し、現実的な環境における防御を検証した。この研究は、検出が役立つ一方で、最終的な影響を決めるのはブラウザアーキテクチャと権限設計だという新たな合意を反映している。

これが、完璧な分類器でも問題全体を解決できない理由だ。分類器も曖昧な言語を処理し、攻撃者は新たな変種を試せる。防御側には、一つの誤った判断でユーザーのブラウザセッション全体が解放されないよう、複数の独立した制御が必要だ。

AmazonとGoogleの防御は完璧な検出より制御を選ぶ

AmazonとGoogleは、一つのプロンプトインジェクションフィルターに依存できないため、多層防御を構築している。

Googleは、エージェントの行動がブラウザに到達する前に確認するアーキテクチャを説明している。同社のUser Alignment Criticは、提案された行動がユーザーの明示した目標と一致するかを評価するために設計された、独立したコンポーネントだ。この分離は、主エージェントが自らの危険な解釈を承認することを防ぐのに役立つ。

Googleは、オリジン情報、アクション確認、モデル訓練、検出システムも活用している。機密性の高い操作には、ユーザーによる明示的な承認が必要になる場合がある。ブラウザはエージェントに届く情報を制限し、認証情報の周囲にセキュリティ境界を維持できる。

エージェント型Chromeの設計でGoogleは、信頼できないWebコンテンツへの露出が本質的な間接プロンプトインジェクションリスクを生むと認めている。この表現は重要だ。同社はこの問題を、継続的な緩和策を必要とするアーキテクチャ上の脅威として提示している。

アクション確認は、重要な手順の前に人間の判断を取り戻すため有用だ。ユーザーは、予期しない購入、メッセージ送信、ログイン、データ転送を拒否できる。しかし、頻繁なプロンプトは日常化し、Cookie通知や権限ダイアログで見られるのと同じ疲労を生み出す可能性もある。

したがって確認は、意味のある移行に焦点を当てる必要がある。新しいドメインへのデータ送信は、ページのスクロールよりも厳しい精査に値する。パスワードマネージャーを開くことは、公開見出しの抽出よりも大きなリスクを伴う。画一的な承認モデルは、異なる行動を同等であるかのように扱ってしまう。

Amazonは、管理対象ブラウザ環境を巡るポリシー強制を重視している。Bedrock AgentCoreを利用する開発者は、エージェントの閲覧先を制限するChromeエンタープライズポリシーを適用できる。これらのルールは、エージェントのプロンプトや推論とは独立して、ブラウザ層で機能する。

この違いは重要だ。モデルは操作され得るが、決定論的なネットワークまたはブラウザポリシーは、禁止された送信先を依然としてブロックする。Amazonのブラウザポリシー制御により、構築者はエージェントが作業を開始する前に、許可する場所とブロックする場所を定義できる。

許可リストは、限定的な企業ワークフローにおける露出を大幅に減らせる。調達エージェントであれば、承認済みサプライヤーのポータル群だけにアクセスできればよいかもしれない。カスタマーサービスエージェントなら、サポートプラットフォームと社内ナレッジシステムだけを必要とする場合がある。

一般的な調査では、こうした境界を維持するのが難しくなります。製品比較やニュース追跡を担うエージェントには、幅広いウェブアクセスが必要です。タスクがオープンであるほど、厳格なアクセス先許可リストの有用性は低下します。

隔離は、もう一つの層を提供します。管理されたブラウザセッションなら、エージェントの活動を従業員の日常的なブラウザプロファイルから分離できます。エージェントが侵害されても、ユーザーが利用できるあらゆるCookie、開いているタブ、保存済み認証情報、拡張機能を自動的に引き継ぐべきではありません。

隔離は、指示が悪意あるものかどうかを判断するものではありません。誤った判断の後に利用可能となるリソースを制限します。これは、コンテナ、仮想マシン、権限を限定したサービスアカウントを支えるのと同じ実践的な考え方です。

最小権限は、このアプローチをツールとデータにも拡張します。公開ページを読むだけのエージェントに、メール送信の権限を与えるべきではありません。取引の下書きを作成するエージェントに、それを承認する権限を与えるべきではありません。文書を読むエージェントが、接続されたすべてのフォルダに自動的にアクセスできるようにすべきでもありません。

したがって、AmazonとGoogleの防御アプローチは共通の原則に収束します。モデルは今後も誤りうるため、セキュリティはモデルの外部に存在しなければなりません。ブラウザポリシー、ID境界、承認ゲート、ログ、隔離されたセッションは、検出で防げなかったエラーを封じ込めることができます。

真のトレードオフは、能力と封じ込めの間にある

プロンプトインジェクションの影響を確実に減らすあらゆる防御は、エージェントの自律性の一部も制限します。

ブラウザエージェントは、サービス間を自由に移動し、コンテキストを記憶し、複数ステップのタスクを完了できるほど有用になります。同じ能力は、攻撃者が影響を及ぼせる判断の数も増やします。セキュリティ上のトレードオフは、製品の価値提案そのものに組み込まれています。

旅行の手配を依頼されたエージェントを考えてみましょう。航空券を検索し、ホテルを比較し、カレンダーを確認し、ポイント情報を取得し、予約の準備を行うかもしれません。外部コンテンツが計画を逸らせば、エージェントは個人情報を露出させたり、攻撃者が管理する行き先を選択したりする可能性があります。

厳格に封じ込められたシステムなら、エージェントを読み取り専用の検索に限定することで、この結果を防げます。しかし、その場合は予約を完了できなくなります。購入権限を追加すれば利便性は戻りますが、誤った行動の影響も大きくなります。

同じパターンは企業内にも当てはまります。営業エージェントは、顧客アカウントを調査してアウトリーチ文面を下書きするだけなら、大きなリスクはありません。メッセージ送信、顧客記録の更新、社内文書の添付を許可すれば、より価値の高い自動化が実現する一方、障害の影響範囲も広がります。

このため、プロンプトインジェクションは能力とセキュリティの問題として評価すべきです。チームは、悪意ある指示を受け入れた後にエージェントが何を実行できるのかを問う必要があります。モデルの攻撃成功率も重要ですが、許容される結果のほうがさらに重要です。

読み取り専用の要約ツールがもたらすリスクは、決済システムに接続されたエージェントのリスクとは異なります。どちらも誤解を招く出力を生成する可能性があります。しかし、追加の制御なしに誤った解釈を外部取引へと変えられるのは後者だけです。

ベンダーは、安全性向上の証拠として高い検出率を宣伝することがあります。こうした結果は有益になりえますが、テストセット、攻撃者の知識、モデルのバージョン、許可されたツールに依存します。適応的な攻撃は、ベンチマークに含まれていないケースを狙うことができます。

偽陽性も運用コストを生みます。防御モデルは、インジェクションの試みと似ている正当なコンテンツを拒否するかもしれません。セキュリティチームは感度を上げて見逃しを減らせますが、その場合、ユーザーはブロックされるタスクや不要な確認により多く直面します。

エージェントの能力は変化し続けるため、設計上の問題に固定的な終着点はありません。ページ要約に対してテストされた安全策が、ビジュアルナビゲーション、ファイルダウンロード、OSのダイアログ、新しいツールプロトコルとのやり取りまで自動的にカバーするわけではありません。

ブラウザの更新によって、新たな挙動が導入されることもあります。モデルのアップグレードは、エージェントによる曖昧な指示の解釈を変える可能性があります。接続先サービスは、ブラウザベンダーがインターフェースを管理しないまま新しいアクションを公開することがあります。セキュリティテストは、単一のモデルスナップショットではなく、システム全体を追う必要があります。

サードパーティーの拡張機能や統合は、さらに状況を複雑にします。エージェントに見えるコンテンツを拡張したり、新たな実行経路を提供したりできるためです。企業はメインブラウザを慎重に構成していても、広範なページアクセス権を持つ拡張機能を見落とすかもしれません。

したがって、懐疑的な見方が必要です。多層防御はリスクを低減しますが、「安全なエージェント」に関する公的な主張を免疫のように解釈すべきではありません。企業は、テスト環境、ブロックされたアクション、ユーザー確認のルール、残存する攻撃対象領域を開示すべきです。

同時に、すべてのAIブラウザを一律に安全でないと断じるのも、判断を単純化しすぎています。リスクは、エージェントの権限、アクセス可能なデータ、隔離、タスクに依存します。制約されたリサーチアシスタントは、購入エージェントが適さない場合でも、低リスク環境に適合しえます。

セキュリティチームには、包括的な一つの承認ではなく、導入クラスが必要です。低リスクのエージェントは、隔離された読み取り専用セッションで動作できます。中リスクのシステムは、人間のレビュー向けにアクションを下書きできます。高リスクのワークフローでは、モデルの外部で決定論的な認可を求めるべきです。

この構造は、トレードオフが消えたふりをするのではなく、それを受け入れます。ユーザーは引き続き自動化の恩恵を得られますが、自律性が高まるのは、周辺の制御がモデルの失敗を吸収できる場合に限られます。

プロンプトインジェクション問題による圧力を受けるのは誰か

ブラウザベンダーは注目を集めますが、実務上の負担の多くを負うのはエンタープライズのIDチームとアプリケーションチームです。

Googleは、すでに価値あるセッションを含むブラウザプロファイルを持つユーザーを保護しなければなりません。Chromeはエージェントをメール、カレンダー、文書、ショッピングアカウント、職場ツールに接続できます。そのため、一つのインターフェースがさまざまな信頼ドメインを露出させる可能性があります。

Amazonの顧客は、異なる責任に直面します。Bedrock AgentCoreは管理されたコンポーネントと制御を提供しますが、エージェントがアクセスできる宛先、ID、ツール、データを最終的に決めるのは開発者です。安全なサービスでも、安全でないアプリケーション構成を支えうるのです。

Microsoft、OpenAI、Anthropic、Perplexityも同じ競争圧力に直面しています。ユーザーはブラウザエージェントにより多くの仕事を処理することを期待する一方、セキュリティ研究者は新しい能力の一つひとつを検証します。より広範な自動化を許容する競合の隣では、制約の多い設計は有用性が低く見える可能性があります。

この競争サイクルは、企業がガバナンスを更新するより速いペースで、ベンダーに権限拡大を促す可能性があります。新しいエージェント機能は、別のアプリケーションであれば必要となる調達レビューを回避し、馴染み深いブラウザや生産性ツールを通じて導入されることがあります。

セキュリティチームは、エージェント機能を製品名ではなく能力として棚卸しすべきです。重要な問いは、認証済みセッション、ローカルファイル、接続アプリケーション、メモリ、メッセージング、ダウンロード、コード実行へのアクセスに関わります。

アプリケーションの所有者も、ウェブページコンテンツを再考する必要があります。社内ダッシュボードは、かつて主に人間の閲覧者向けに設計されていました。エージェントがそのテキストを情報と潜在的な指示の両方として扱うなら、コンテンツの来歴はアプリケーションセキュリティの一部となります。

IDチームは、エージェントが人間の認証情報を共有するのか、独自のサービスIDを受け取るのかを決めなければなりません。共有セッションは便利ですが、説明責任を弱めます。個別のIDは、より厳格な権限、明確なログ、迅速な無効化を支えます。

開発者には、エージェントが何を見て、なぜ行動したのかを説明するイベント記録が必要です。通常のブラウザ履歴は訪問ページを示しますが、エージェントのアクションの背後にある正確なコンテンツ、モデル判断、ツール呼び出し、認可までは記録しない可能性があります。

インシデント対応者も別の困難に直面します。エージェントは有効な認証情報と正規のブラウザ機能を使うため、成功したプロンプトインジェクションは通常のユーザー活動に見えることがあります。検出では、意図、連続性、宛先、データ移動を分析しなければなりません。

従業員にも、より明確なシグナルが必要です。エージェントがいつページを読み、別のサービスへ移行し、私的情報にアクセスし、不可逆的なアクションを準備するのかを把握できるべきです。小さなアニメーションアイコンでは、信頼状態の移行全体を伝えられません。

エンタープライズの購入担当者は、コンテンツが視覚的、難読化、多言語、または複数ステップに分散している場合に防御がどう機能するかをベンダーに尋ねるべきです。また、セキュリティチェックがメインエージェントから独立して実行されるか、モデル変更後もポリシーが強制可能なままであるかも確認すべきです。

最も強力な評価には、組織の実際のワークフローに対する敵対的テストが含まれます。汎用ベンチマークでは、すべての社内アプリケーション、データソース、権限の組み合わせを再現できません。レッドチームは、悪意あるコンテンツを変化させながら、現実的な目標をテストすべきです。

調達契約にも明確なインシデント条項が必要です。購入者は、ログの保持期間、脆弱性開示、モデル更新の運用、安全でない構成に対する責任を理解すべきです。プロンプトインジェクションは、ベンダーの挙動と顧客設計の境界をまたぎます。

モデル更新だけで、この共同責任の問題を解決できる企業はありません。ベンダーは強制可能な制御を提供し、顧客はそれらを具体的なタスクに合わせて構成しなければなりません。両者には、制御が連携して機能することを示す証拠が必要です。

Amazon、Google、AIブラウザベンダーの次の動向

次の段階は、プロンプトインジェクションが排除されたという約束ではなく、封じ込めの証拠によって評価されます。

最初のシグナルは、ベンダーがブラウザの完全なワークフローを対象にした再現可能な評価を公開するかどうかです。テストには、隠されたページテキスト、画像、タブ間アクション、保存済みメモリ、接続アカウント、複数ステップの意図操作を含めるべきです。単一の拒否ベンチマークでは、視野が狭すぎます。

結果では、検出と影響を分けるべきです。要約に影響を与える攻撃と、データを送信したり購入を完了したりする攻撃は異なります。購入者は、エージェントが敵対的コンテンツに従う頻度と、結果として生じるアクションをどの制御が阻止するのかの両方を知る必要があります。

二つ目のシグナルは、決定論的な制限の利用がより広がることです。Amazonのブラウザポリシーは、モデルの推論にかかわらず宛先をブロックできるため、一つの例になります。Googleのアクションチェックと権限ゲートも、ユーザーとの整合性をめぐって関連する役割を果たします。

こうした制御が、きめ細かなレベルで構成しやすくなるかを見守るべきです。企業には、宛先、データの機微性、アクションの種類、ID、タスクに基づくポリシーが必要です。ブラウザ全体を対象とする単一のオン・オフスイッチでは、こうした違いを表現できません。

三つ目のシグナルは、ベンダーが新たに開示された攻撃チェーンをどのように扱うかです。脆弱性クラスが残る場合でも、迅速なパッチは依然として重要です。リリースノートでは、修正が検出、権限範囲、隔離、基盤となるエージェントアーキテクチャのいずれを変更するのかを説明すべきです。

エージェントの挙動は非決定的であるため、研究者は今後も変種を見つけ続けるでしょう。一つのフレーズやウェブページパターンをブロックするパッチでは、異なるコンテキストにまたがる意図の衝突には対処できません。持続的な改善には、信頼できない経路から能力を取り除くか、独立した認可を追加する必要があります。

Googleが報告した悪意あるウェブパターンの増加は、この取り組みに緊急性を与えます。同社のスキャンでは攻撃の高度化はなお限定的でしたが、活動の増加は、攻撃者に導入済み製品を試す機会をより多く与えます。ブラウザエージェントの採用拡大は、成功する手法の価値を高めます。

AmazonとGoogleの競争は、ユーザーがどのような安全性の妥協を受け入れるかも明らかにするでしょう。Googleは個人が確認できる場所であるChrome内に確認を直接配置できます。Amazonは開発者にインフラポリシーを提供できますが、それらのポリシーをどこまで制限的にするかは顧客ごとに決める必要があります。

エンタープライズ導入における短期的な標準は、シンプルであるべきです。エージェントを隔離し、固有のIDを与え、宛先を制限し、ツールを最小化し、重大なアクションの前に承認を求めることです。信頼できないコンテンツと特権的な挙動の間にある、すべての移行を記録してください。

ナレッジワーカーは、可能な限り機密性の高いアカウントを実験的なエージェントセッションの外に置くべきです。また、提案されたメッセージ、取引、ダウンロード、データ転送は確認する必要があります。ブラウザの更新も重要ですが、それだけで根本にある解釈上の問題を解消することはできません。

開発者は、あらゆるウェブページ、メール、アップロードされた文書、取得したノートを信頼できない入力として扱うべきです。主力モデルはいずれ、その一部を誤分類すると想定しなければなりません。その後に何が起きるかは、モデルの外部にある制御機構が決定すべきです。

完璧な解決策は存在しないという結論は、不都合なものです。なぜなら、それは導入時に問うべきことを変えるからです。チームは、ブラウザエージェントがプロンプトインジェクションに対して完全に耐性を持つかどうかを問うのをやめるべきです。代わりに、一度のインジェクション成功が重要な対象に到達し得るかを問うべきです。

次の自律機能を有効化する前に、許可される最悪のアクションを洗い出し、その便益がそのリスクへの曝露を正当化するか判断してください。答えが明確でない場合は、エージェントを読み取り専用に留めるか、人間の承認を必須にしてください。AmazonとGoogleの競争はより優れた防御策を生み出すでしょうが、責任ある導入は依然として封じ込めにかかっています。