BrowseSafe++：針對真實世界的提示詞注入，打造更強大的防禦

能夠瀏覽網頁的代理程式，例如 Comet 或 Computer 內建的助理，需要與網頁互動，讀取內容並據此代表使用者執行動作。這使它們容易受到間接提示詞注入的影響，也就是攻擊者在網頁上放置惡意文字。如果代理程式遵循這些指示，就可能傳回誤導性的答案，或執行使用者未要求的動作。

2025 年 12 月，我們發布了 BrowseSafe，這是一套針對此威脅的基準測試與偵測模型。我們的做法是在代理程式可能遇到的真實網頁中加入合成攻擊。過去一年來，攻擊手法不斷演進，變得更加精密，也更像一般的頁面內容。這些攻擊不再使用「忽略先前的指示」這類容易露出破綻的語句，而是經常模仿代理程式可能信任的內容，例如網站的官方公告，或是關於使用者偏好的備註。

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

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

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

BrowseSafe++ 是以在真實網站上觀察到的提示詞注入建構而成。從 2025 年 9 月到 2026 年 9 月，Comet 的提示詞注入偵測器在其代理程式讀取的頁面上標記了 115 萬筆注入內容。我們圍繞這些注入內容建構了 32,187 組配對，並加入原始 BrowseSafe 基準測試中的 6,488 組配對，總計 38,675 組。每組配對都包含一個遭攻擊的頁面及其乾淨的對應版本，也就是移除注入內容後的相同頁面。

實際環境中的注入攻擊樣貌

以下兩個來自基準測試的範例，展示了這些注入內容在實務上的樣貌。

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

這段文字以指令開頭和結尾，中間則填滿一般的代幣行銷內容。它聲稱來自代理程式本身的開發者，並在結尾附上一組授權碼，讓這筆購買看起來已獲核准。

在另一個範例中，一段偽造的對話企圖干擾代理程式的任務。這段文字於 2026 年 3 月在某個程式碼存放庫頁面上被發現：

這段文字的設計是模仿使用者與代理程式之間的對話：<|im_start|> 和 <|im_end|> 是部分聊天模型用來區隔對話輪次的標記。落入此攻擊陷阱的代理程式會回應偽造的使用者查詢，並以攻擊者指定的語句回覆。

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

• 它們會模仿受信任的來源。這兩個範例都讓頁面文字聽起來像是代理程式信任的來源：第一個是它的開發者，第二個是它自己的對話。注入內容也可能偽裝成網站本身，模仿安全檢查與政策通知；或是偽裝成使用者，提出虛假的偏好設定。約有三分之二的注入內容以正式語言撰寫。
• 許多注入內容以不同語言撰寫。在 24.4% 的配對中，注入內容使用的語言與頁面其他部分不同。這通常表現為非英文頁面上的英文指示，如第一個範例所示。這類攻擊顯然是針對能讀懂各種語言、且通常以英文為母語的代理程式。切換語言也會增加偵測難度：在我們最初的 BrowseSafe 評估中，多語言攻擊是最難攔截的攻擊之一。
• 大多數注入內容想要的是行動，而非言語。超過四成會誘使代理程式執行使用者從未要求的動作，例如第一個範例中的代幣購買；約三分之一則試圖讓代理程式放棄使用者的任務，如第二個範例所示。只有約 3% 試圖在答案中植入錯誤資訊。
• 它們經常依附在任何人都能發布的內容上。攻擊者不需要控制網站。一般網站上的一篇論壇貼文或一份共用文件就已足夠，BrowseSafe++ 中有超過 23,000 筆注入內容就是透過這種方式出現的。即使是受信任的網域，仍可能被用來注入攻擊者的文字。

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

放大

從遭標記的頁面到基準測試配對

我們無法將遭標記的頁面直接用於基準測試，因為其中可能含有代理程式所服務之使用者的個人資訊。要將頁面轉換為可分享的基準測試配對，需要經過三個主要階段：

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

放大

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%。

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

其餘模型是較強的通用模型，F1 分數介於 85% 到 92% 之間。然而，它們仍面臨召回率與誤報率之間的權衡：傾向謹慎的模型會封鎖正常頁面，而較少發出標記的模型則會漏掉攻擊。Claude Sonnet 5 的召回率是所有偵測器中最高的，達到 98.73%，但誤報率為 24.65%。Gemini 3.1 Pro 和 GPT-5.5 的召回率分別為 97.78% 和 97.19%，誤報率分別為 19.80% 和 20.44%。GPT-6 Astra 的整體準確度最高，召回率為 96.42%，誤報率為 14.41%。Decider 位居第二，召回率為 96.02%，誤報率為 17.44%。Claude Opus 5.5 的誤報率最低，僅有 4.21%，但其 77.71% 的召回率意味著它會漏掉超過五分之一的攻擊。Claude Fable 5.1 在有回答的頁面上表現強勁，召回率為 89.31%，誤報率為 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%）的十倍。

可實際部署的注入防禦系統

這些結果顯示，將是否封鎖頁面的決策交給專用模型，而非仰賴執行使用者任務的模型，是有價值的做法。在代理程式採取行動前先篩檢每個頁面的獨立偵測器，能提供額外一層防禦，而且它沒有可被劫持的任務，也沒有可被濫用的工具。

Guard 正是為此打造的偵測器。除了在我們測試的所有模型中擁有最高的 F1 分數與準確率之外，它的體積小巧，成本也低到足以在每個頁面上執行。平均而言，Guard 處理每個文字頁面約需 0.15 秒的 GPU 時間。以租用的 H200 計算，我們估計每 1,000 個頁面的成本為 0.18 美元；相較之下，前沿 API 模型依牌價計算則需 18.95–180.61 美元。在我們的比較中，這讓頻繁篩檢的成本大幅降低，同時維持高偵測分數。

下圖繪製了每個偵測器的準確度相對於其每頁處理時間及每 1,000 頁成本的關係，兩者皆採用對數尺度。Guard 在兩個面板中都獨自位於左上角：它在準確度、速度和成本上全面勝出。每個以提示詞驅動的模型每頁都需要約一秒或更久，而準確度最高的兩個模型 GPT-6 Astra 和 Claude Fable 5.1，每 1,000 頁的成本超過 100 美元。

放大

針對適應性攻擊測試防禦能力

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

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

放大

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

當攻擊者的目標是讓代理程式發出特定的工具呼叫時，各代理程式之間的差異最大。在具有這類目標的任務中，Sonnet 5 約在 8% 的任務中屈服，GPT-5.5 則約為 29%。其他五個代理程式則在超過一半的任務中執行了攻擊者的目標。

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

放大

結論

瀏覽器代理程式往往容易受到間接提示詞注入的影響，也就是隱藏在一般頁面中、企圖干擾代理程式執行使用者任務的攻擊。隨著時間推移，這些危險只會不斷增加：代理程式能存取的資料和工具越來越多，提高了攻擊可能造成的損害；攻擊者也能修改注入內容，使其更加有效。

我們的 BrowseSafe 套件可應對這些威脅。BrowseSafe++ 基準測試包含 38,675 組主要以真實注入內容建構的網頁配對，讓偵測器的訓練與評估更加可靠。以這些配對訓練而成的 BrowseSafe-Guard 偵測器，能提供高準確度、快速且低成本的偵測，從而能在代理程式對頁面採取行動前先行掃描。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}
}