BrowseSafe++：為真實世界的提示注入攻擊建立更強大的防禦

能夠瀏覽網頁的 AI 代理程式（例如 Comet 或 Computer 內置的助理）需要與網頁互動，讀取內容並利用這些內容代表用戶執行操作。這令它們容易受到間接提示注入攻擊，即攻擊者在網頁上放置惡意文字。如果 AI 代理程式遵從這些指示，就可能會回傳誤導性的答案，或執行用戶並未要求的操作。

我們在 2025 年 12 月推出了 BrowseSafe，這是一個針對此類威脅的基準測試及偵測模型。我們在 AI 代理程式可能遇到的真實網頁中加入合成攻擊，藉此建立這個模型。過去一年，攻擊手法不斷演變，變得更加精密，看起來也更像普通的網頁內容。它們不再使用「忽略先前的指示」這類明顯的字句，而是經常模仿 AI 代理程式可能信任的內容，例如網站的官方通知，或關於用戶偏好的備註。

鑑於這些變化，我們構建了更新版基準測試 BrowseSafe++，用以衡量現有的注入偵測器能否捕捉這些攻擊，以及 AI 代理程式能否抵禦它們。它包含 38,675 組受攻擊與乾淨網頁配對，主要圍繞在真實世界中收集的注入內容構建。我們會改寫每個網頁的周邊內容以保障私隱，但會原封不動保留攻擊內容。每個網頁都提供瀏覽器 AI 代理程式會讀取的四種格式：HTML、Markdown、無障礙樹及螢幕截圖。我們使用基準測試的一個子集來訓練 BrowseSafe-Guard，這是一對 0.8B 參數的偵測器：一個文字偵測器和一個多模態偵測器。兩個 Guard 偵測器識別注入內容的準確度，均高於我們測試過的提示式模型，包括前沿模型。它們的速度亦更快、成本更低，而且誤將普通網頁標記的次數也少得多。

我們將 BrowseSafe++ 作為開放基準測試發布。專案網站提供數據集、SDK、研究論文及公開排行榜的連結。任何團隊都可以用未附標籤的測試網頁評估其偵測器，並提交標籤以供評分，有機會納入排行榜。如要評估及提交結果，請參閱開始使用。

以觀察到的注入內容構建基準測試

BrowseSafe++ 是基於在真實網站上觀察到的提示注入構建而成。在 2025 年 9 月至 2026 年 9 月期間，Comet 的提示注入偵測器在其 AI 代理程式讀取的網頁上標記了 115 萬個注入內容。我們圍繞這些注入內容構建了 32,187 組配對，並加入原有 BrowseSafe 基準測試的 6,488 組配對，合共 38,675 組。每組配對都包含一個受攻擊網頁及其乾淨孿生網頁，即沒有注入內容的同一網頁。

真實環境中的注入攻擊是怎樣的

基準測試中的兩個例子展示了這些注入內容的實際樣貌。

其中一個例子是虛假購買請求，誘使 AI 代理程式採取未經授權的行動。Comet 的偵測器於 2025 年 10 月，在一個俄語開發者文件網頁上標記了以下這段英文文字：

這段文字以指令開頭和結尾，中間則填滿普通的代幣推廣內容。它聲稱來自 AI 代理程式本身的開發者，並在結尾附上授權碼，令這次購買看起來已獲批准。

在另一個例子中，一段偽造對話旨在擾亂 AI 代理程式的任務。這段文字於 2026 年 3 月在一個程式碼儲存庫網頁上被發現：

這段文字刻意模仿用戶與 AI 代理程式之間的對話：<|im_start|> 和 <|im_end|> 是部分聊天模型用來分隔對話輪次的標記。中了這次攻擊的 AI 代理程式會回應偽造的用戶查詢，並以攻擊者指定的句子回覆。

我們在已標記的注入內容中觀察到類似的模式：

• 它們會模仿可信來源。兩個例子都讓網頁文字聽起來像是 AI 代理程式信任的來源：第一個例子是它的開發者，第二個是它自己的對話。注入內容亦可能冒充網站本身，模仿安全檢查和政策通知；或冒充用戶，提出虛假的偏好設定。約三分之二的注入內容以正式語言撰寫。
• 許多以不同語言撰寫。在 24.4% 的配對中，注入內容所用的語言與網頁其他部分不同。這通常是在非英文網頁上出現英文指示，如第一個例子所示。這類攻擊顯然是針對能閱讀所有語言、而且通常以英文為母語的 AI 代理程式。語言切換亦令偵測更加困難：在我們最初的 BrowseSafe 評估中，多語言攻擊屬於最難捕捉的攻擊之一。
• 大多數要求行動，而非言語。超過四成會促使 AI 代理程式執行用戶從未要求的操作，例如第一個例子中的代幣購買；約三分之一則試圖令它放棄用戶的任務，如第二個例子所示。只有約 3% 試圖在答案中植入虛假資訊。
• 它們經常借助任何人都能發佈的內容。攻擊者毋須控制整個網站。普通網站上的一則論壇帖子或一份共享文件已經足夠，BrowseSafe++ 中超過 23,000 個注入攻擊正是以這種方式出現。即使是可信網域，仍可被利用來注入攻擊者的文字。

最終基準測試中的注入內容涵蓋 12 類網站、24 種攻擊類型、6 種攻擊者目標，以及網頁上的 18 個放置位置。

放大

從被標記的網頁到基準測試配對

我們無法直接在基準測試中使用已標記的網頁，因為這些網頁可能包含 AI 代理程式所服務用戶的個人資料。將網頁轉化為可分享的基準測試配對需要經過三個主要階段：

1. 收集注入內容：我們收集已標記的網頁、移除重複項目，並使用 PII-Tracer 遮蔽個人資料。然後，我們確認網頁含有注入內容；具體而言，我們要求一組模型一致同意網頁含有試圖將 AI 代理程式引離用戶原定任務的指示。
2. 建立配對：一個 AI 代理程式會從每個網頁移除注入文字，並改寫周邊的網頁內容，將名稱和品牌等細節替換成虛構內容。第二個 AI 代理程式會檢查改寫後的網頁是否仍殘留真實世界的內容，並將未通過的網頁連同回饋發回。人工審查員會隨機檢查 10% 的網頁；他們發現的問題會在流程中修正，並將修正套用至整個語料庫。注入內容會重新插入改寫後的網頁以建立受攻擊版本，乾淨版本則不包含注入內容。兩個網頁共用相同的任務、預期結果及一般指示。
3. 驗證：AI 代理程式以不同形式讀取網頁，因此我們將每個網頁的 HTML 渲染成 Markdown、無障礙樹（列出網頁介面元素及其標籤的結構化清單）及螢幕截圖。另一個 AI 代理程式會檢查注入內容是否出現在受攻擊網頁的全部四種視圖中，以及乾淨網頁在每種視圖中是否都被判定為無害。如果某個視圖中缺少注入內容，我們會將其移至網頁上的另一個位置並重新渲染，確保注入內容在最終受攻擊網頁的所有視圖中都會出現。最後一組自動檢查會修正仍帶有來源痕跡（例如真實主機名稱或品牌名稱）的配對。

放大

BrowseSafe-Guard：適用於每種視圖的快速精準偵測器

實用的偵測器需要快速而低成本地檢查每個網頁，同時對受攻擊和乾淨的網頁都要準確。高精確率尤其重要，因為大部分網頁都是安全的；即使誤報率相對較低，亦會令大部分警報都是錯誤警報。提示式通用模型往往精確率不足，而且速度太慢、成本太高，難以在每個網頁上執行。

若偵測器以分開收集的受攻擊網頁和乾淨網頁進行訓練，可能會學到一些恰好能區分兩組數據的捷徑，例如網頁的主題或版面。然而，這樣的偵測器泛化能力不佳。Guard 則改用僅在注入內容本身有所不同的網頁配對進行訓練，有助提升偵測器的精確度。對於每組配對，Guard 會分別讀取受攻擊網頁及其乾淨的對應網頁，並各自給予分數，表示其含有注入內容的可能性。模型更新時採用兩個訓練目標：標準分類目標，以及排序目標；除非受攻擊網頁的分數比其對應網頁至少高出一個固定差距，否則排序目標便會懲罰 Guard。直觀而言，分類目標教導 Guard 應作出甚麼判斷，而排序目標則將這個判斷與注入內容本身掛鈎，並忽略無害的干擾內容。這樣能訓練 Guard 針對注入內容本身作出反應，而非周圍的網頁內容。

Guard 由兩個偵測器組成，各自由 Qwen3.5-0.8B 微調而成。文字偵測器讀取網頁的其中一種文字視圖：HTML、Markdown 或無障礙樹。多模態偵測器則讀取整頁截圖。部署時，Guard 只需單次前向傳遞即可讀取網頁並輸出注入分數；若分數超過閾值，該網頁便會被標記。由於 Guard 只有 0.8B 參數，而且只輸出單一分數，因此速度夠快、成本夠低，足以在每個網頁上執行。

效能基準測試

我們在基準測試的保留子集上，將 Guard 與 18 個經提示偵測注入內容的模型作比較。我們報告在 BrowseSafe++ 上量度的四項指標：

• 召回率是指被注入的網頁中獲偵測器標記的比例，用於衡量偵測器能攔截多少攻擊，因此數值越高越好。
• 誤報率（FPR）是指偵測器誤將乾淨網頁標記的比例，用於衡量偵測器發出錯誤警報的頻率，因此數值越低越好。
• 精確率是指被標記的網頁中確實含有注入內容的比例，用於衡量警報正確的頻率，因此數值越高越好。
• F1 是召回率與精確率的調和平均數；只有當偵測器能捕捉大部分攻擊，且其標記中極少是錯誤警報時，F1 才會偏高。

我們以 F1 作為主要指標，因為優秀的偵測器應同時具備高精確率和高召回率。全部四項指標均為三種文字視圖的平均值。

放大

放大

模型比較

我們測試的小型開放權重模型排在最後。Mistral NeMo 和 Qwen3 30B-A3B 各自標記約一半的乾淨網頁，而 Llama 3.1 8B 則幾乎甚麼都不標記，漏掉大部分攻擊。即使是這組中最強的模型 GPT-OSS 20B，F1 亦只有 70.97%。規模大得多的開放權重模型 DeepSeek V3.1 表現稍好，F1 為 75.23%。

輕量級 API 模型，包括 GPT-5.4 nano、Gemini 3.1 Flash-Lite 及 Claude Haiku 4.5，能偵測到更多攻擊，召回率介乎 85% 至 97%。然而，代價是誤報比例偏高；Gemini 3.1 Flash-Lite 的 FPR 是該組中最低，為 35.2%，而 Haiku 的 FPR 則接近 69%。因此，該組的最高 F1 分數為 80.9%，由 Gemini 3.1 Flash-Lite 取得。

其餘模型是較強的通用模型，F1 分數介乎 85% 至 92%。然而，它們仍需在召回率與 FPR 之間取捨；傾向謹慎的模型會封鎖正當網頁，而較少發出標記的模型則會漏掉攻擊。Claude Sonnet 5 的召回率在所有偵測器中最高，達 98.73%，但 FPR 為 24.65%。Gemini 3.1 Pro 和 GPT-5.5 的召回率分別為 97.78% 和 97.19%，FPR 分別為 19.80% 和 20.44%。GPT-6 Astra 的整體準確度最高，召回率為 96.42%，FPR 為 14.41%。Decider 位居第二，召回率為 96.02%，FPR 為 17.44%。Claude Opus 5.5 的 FPR 最低，僅為 4.21%，但其 77.71% 的召回率代表它會漏掉超過五分之一的攻擊。Claude Fable 5.1 在它有作答的網頁上表現強勁，召回率為 89.31%，FPR 為 7.92%，但它在約 30% 的網頁上拒絕回答，而「（全部）」一列將這些拒絕計作標記。

放大

Guard 推進了帕累托前沿，在漏報攻擊與錯誤警報之間取得更佳的平衡。它的 F1 約達 95%，並在每種文字視圖中都排名第一。它每 20 個乾淨網頁只標記約 1 個，約為準確度最高的提示式模型 Astra 的三分之一。這項差異源自我們的訓練；Guard 所基於的原版 Qwen3.5-0.8B 若以與其他模型相同的方式提示，F1 只有 64%，而且會標記近四分之三的乾淨網頁。在螢幕截圖視圖情境中，我們將 Guard 的多模態偵測器與四個具備圖像處理能力的模型作比較。在提供完整網頁截圖的情況下，Guard 的 F1 約為 93%，而我們評估過的其他模型中表現最佳者約為 79%。

識別攻擊不等於能夠抵禦攻擊

直覺上，能正確識別注入內容的模型，在執行用戶任務時遇到該網頁，也應該會忽略該注入內容。然而，我們的實驗顯示，偵測分數高並不保證模型能抵禦攻擊。我們將同一個受攻擊網頁給予每個模型兩次：一次讓它判斷網頁是否含有注入內容，另一次讓它在看不到先前判斷結果的情況下執行用戶任務。再由另一個獨立的評判模型檢查它是否遵從了注入內容。每個受測模型仍然會遵從部分它已標記的注入內容，佔已標記網頁的比例由 GPT-6 Astra 的 1.64% 至 Llama 3.1 8B 的 24.73% 不等。

放大

偵測分數未能可靠地預測各模型之間的差異。Claude Sonnet 5 與 GPT-5.5 偵測注入內容的能力相若，F1 分數分別約為 88% 和 89%。然而，Sonnet 5 在 19.74% 的網頁上遵從了它已標記的注入內容，頻率是 GPT-5.5（1.97%）的十倍。

可部署的注入攻擊防禦系統

這些結果表明，將封鎖網頁的決定交由專用模型負責，而非依賴執行用戶任務的模型，是有價值的。在 AI 代理程式行動前篩查每個網頁的獨立偵測器能提供額外一層防禦，而且它沒有可被劫持的任務，也沒有可被濫用的工具。

Guard 正是為擔任這種偵測器而設計。除了在我們測試的所有模型中擁有最高的 F1 分數和準確度外，其細小的模型規模亦令運行成本低至足以在每個網頁上執行。平均而言，Guard 處理每個文字網頁約需 0.15 秒 GPU 時間。以租用的 H200 計算，我們估計每 1,000 個網頁的成本為 US$0.18，而前沿 API 模型按標價計算則需 US$18.95–180.61。在我們的比較中，這令頻繁篩查的成本大幅降低，同時保持高偵測分數。

下圖繪出每個偵測器的準確度與其每頁處理時間及每 1,000 頁成本的關係，兩者均採用對數刻度。Guard 在兩個圖表中都獨佔左上角：它在準確度、速度及成本方面都勝出。每個提示式模型處理每頁都需時約一秒或以上，而準確度最高的兩個模型 GPT-6 Astra 和 Claude Fable 5.1，每 1,000 頁的成本超過 100 美元。

放大

測試防禦措施抵禦自適應攻擊的能力

BrowseSafe++ 基準測試的注入內容數量有限。然而，真正的攻擊者可以發動自適應攻擊；當注入失敗時，攻擊者可以改寫並再次嘗試。因此，能抵禦原始注入的 AI 代理程式，仍可能容易受到日後的攻擊。此外，模型是以從互聯網收集的數據訓練，因此可能學會抵禦其中大部分注入內容；由於我們公開發布基準測試，它很可能會飽和，無法有效區分不同模型。為解決這兩個問題，我們構建了 BrowseSafe-Adapt，這是一個讓攻擊者模型可以改寫注入內容的測試環境。每項測試分為三個階段：

1. 設定案例。每個案例將一項 BrowseSafe++ 條目與一個目標 AI 代理程式配對。BrowseSafe++ 條目包括一個含有用戶查詢及任務的情境、一個受攻擊的網頁，以及攻擊者期望達成的結果。AI 代理程式在沙箱中運作，沙箱會提供執行任務所需的工具及合成數據。另一個獨立的驗證模型會評估攻擊是否達成目標。
2. 執行嘗試：我們將目前的注入內容插入網頁，然後讓 AI 代理程式執行任務。驗證器會檢查 AI 代理程式的答案及其對沙箱所作的任何更改，以判斷攻擊是否成功。首次嘗試使用原始 BrowseSafe++ 條目中的注入內容。
3. 修改並重複：如果攻擊失敗，我們會將該次嘗試存檔，並由評審模型檢討問題所在。攻擊者模型會根據這些回饋改寫注入內容；它可以更改攻擊的措辭、格式或在網頁上的位置。攻擊目標、成功準則及周邊網頁內容則維持不變。下一次嘗試會使用更新後的攻擊。這個過程會不斷重複，直至攻擊成功或攻擊者達到設定的嘗試次數上限為止。

放大

我們測試了七個 AI 代理程式，每個均基於不同模型構建：Claude Sonnet 5、Claude Haiku 4.5、GPT-5.5、Gemini 3.1 Pro、Gemini 3.5 Flash-Lite，以及開放權重模型 DeepSeek V3.1 和 Kimi K2。每個 AI 代理程式均面對相同的 1,024 項任務，每項任務最多可嘗試 64 次。在首次嘗試中，七個 AI 代理程式的攻擊成功率都很低。無論針對哪個 AI 代理程式，原始注入內容最多只在 4% 的評估任務中成功。但在自適應框架下，攻擊成功率大幅上升。在七個 AI 代理程式中，攻擊者針對其中五個時，至少在 79% 的任務中成功。即使是最強的 AI 代理程式亦難以倖免：針對 GPT-5.5，攻擊仍在約三分之二的任務中成功；針對 Claude Sonnet 5，則約為三分之一。

當攻擊者的目標是令 AI 代理程式發出特定工具調用時，各 AI 代理程式之間的差異最大。在這類目標的任務中，Sonnet 5 在約 8% 的任務中失守，GPT-5.5 則約為 29%。其餘五個 AI 代理程式在超過一半的任務中執行了攻擊者的目標。

我們亦在 Guard 先篩查每個網頁的情況下，以 BrowseSafe-Adapt 測試 Gemini 3.5 Flash-Lite AI 代理程式。Guard 攔截了 94.5% 的原始注入內容，並令攻擊者所需的平均嘗試次數增加近一倍，由 9.7 次增至 17.0 次。然而，在給予全部 64 次嘗試的情況下，攻擊者仍在 84.2% 的任務中成功（沒有 Guard 時為 93.6%），而且幾乎都是利用 Guard 未有標記的注入內容。這與我們發布 BrowseSafe 時提出的觀點一致：沒有任何偵測模型是萬靈丹，因此偵測器必須作為多層防禦的一部分。

放大

結論

瀏覽器 AI 代理程式往往容易受到間接提示注入攻擊，即隱藏在普通網頁上的攻擊試圖干擾 AI 代理程式執行用戶任務的能力。隨着時間推移，危險只會與日俱增：一方面 AI 代理程式可存取更多數據和工具，令攻擊的潛在風險提高；另一方面攻擊者亦可修改注入內容，令其更有效。

我們的 BrowseSafe 套件正是為應對這些威脅而設。BrowseSafe++ 基準測試包含 38,675 組主要由真實注入內容構建的網頁配對，讓偵測器的訓練和評估更可靠。以這些配對訓練的 BrowseSafe-Guard 偵測器能實現高度準確、快速且低成本的偵測，讓系統能在 AI 代理程式對網頁採取行動前先掃描網頁。BrowseSafe-Adapt 框架則可針對經修改的注入內容測試模型，突顯使用固定注入內容進行單次嘗試時可能無法察覺的漏洞。

我們希望這些工具能共同幫助研究人員和工程師更容易找出失效情況，並改善針對網頁提示注入攻擊的防禦。我們亦持續評估和改進 Comet 及 Computer 的內置防禦措施，以保障用戶安全。

開始使用

1. 安裝 SDK 並取得數據存取權限。SDK 可從 GitHub 安裝：

此數據集設有存取限制。請先在其 Hugging Face 頁面上申請存取權限一次，然後使用 hf auth login 登入。

2. 提交至排行榜。在 BrowseSafe++ 的測試集上評估你自己的偵測器：

此操作會為你列出的每個視圖，在每個網頁寫入一個判斷結果；列出全部三個文字視圖，即可在文字排行榜上取得平均分數。使用你的 Hugging Face 帳戶登入排行榜 Space，然後上載 predictions.jsonl。該 Space 會傳回每個視圖的 F1、準確度、假陽性率及其他指標，並可按你的選擇將結果發佈到排行榜上。每個帳戶（註冊至少 60 天）每個 UTC 週可提交一次並獲評分。測試網頁僅供評估之用：請勿用於訓練或重新發佈。提交指南說明了檔案格式及發佈規則。

引用

@online{perplexity2026BrowseSafePlusPlus,
  author = {{Perplexity} and Yuetian Chen and Kaiyuan Zhang and Yuntao Du and Thomas Li and Mark Tenenholtz and Kyle Polley and Jerry Ma and Denis Yarats and Ninghui Li and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{BrowseSafe++: Building stronger defenses against real-world prompt injection}},
  date = {2026-10-28},
  url = {https://www.perplexity.ai/hub/blog/browsesafe-plus-plus}
}