MUZZLE 論文閱讀分析：當 Web Agent 真的開始替你逛網頁、切網站、點按鈕，Prompt Injection 也不會再傻傻只躲在單一頁面等你踩
MUZZLE 論文閱讀分析：當 Web Agent 真的開始替你逛網頁、切網站、點按鈕，Prompt Injection 也不會再傻傻只躲在單一頁面等你踩
如果最近這串 sectools.tw 的文章，已經一路把 indirect prompt injection、tool trust boundary、runtime defense、adaptive attack、memory persistence 這些拼圖慢慢接起來，那這篇 Adaptive Agentic Red-Teaming of Web Agents Against Indirect Prompt Injection Attacks 值得補上的位置非常明確：它不是再證明 web agent 會被 prompt injection 騙，而是把問題往更接近真實世界的一步推——當 agent 真的在多個網站之間跳轉、真的替你執行長流程任務時，攻擊者也會開始順著它的軌跡，自動找出最值得下毒的頁面、欄位與時機。
我會把這篇看成是把間接提示注入從「靜態 payload 測試」拉進 agentic red teaming 的一篇關鍵論文。因為它提醒大家：真正危險的 prompt injection，不一定是某個明顯惡意的頁面，而可能是 agent 在完成正常任務途中，剛好會看、會信、會採取行動的那一小段外部內容。
論文基本資訊
- 論文標題：Adaptive Agentic Red-Teaming of Web Agents Against Indirect Prompt Injection Attacks
- 作者：Evan Rose、Brian Grinstead、Christoph Kerschbaumer、William Robertson、Cristina Nita-Rotaru、Alina Oprea
- 年份：2026
- arXiv：https://arxiv.org/abs/2602.09222
- 領域：Web Agent Security、Indirect Prompt Injection、Agentic Red Teaming、Browser / Cross-App Security
這篇論文在解什麼問題？
作者瞄準的是一個很現實、而且會越來越常見的場景：LLM-based web agent 不只是讀文字回答問題，而是會直接幫使用者打開網站、切換分頁、點連結、填表單、查看郵件、操作電商、管理帳號，整個過程裡持續把網頁內容當成觀察訊號，再決定下一步。
這種設計很好用，但也意味著 agent 會持續吞入不可信的網頁內容。只要某段頁面、某個欄位、某個留言、某封郵件或某個跨站互動點被攻擊者控制，裡面就能埋惡意指令，讓 agent 偏離原本使用者任務，進而造成：
- 機密資料外洩
- 未授權操作
- 服務中斷或流程破壞
- 跨站、跨應用的連鎖行動
作者認為，既有 web-agent IPI 研究雖然已經證明風險存在，但大多有三個限制：
- 太手工：人工挑頁面、人工選注入點、人工寫 payload。
- 太靜態：常常只在固定 HTML snapshot 上做優化，沒有真的在 live sandbox 裡跑完整流程。
- 太單點：缺少對 multi-step、cross-app、長流程任務的自動化探索。
所以這篇真正要問的是：
能不能做出一個會自己跟著 agent 軌跡找高價值注入面、自己改寫攻擊策略、自己反覆試錯的 red-teaming framework，讓 web agent 的 indirect prompt injection 評測不再只是手工 demo？
這篇最值得記住的核心觀點：真正高風險的 injection surface，常常不是「最顯眼的地方」，而是 agent 軌跡裡「最有機會被採信的地方」
我覺得 MUZZLE 最重要的地方，是它沒有把 prompt injection 當成單純的 payload 設計問題，而是把它看成一個 trajectory-aware attack discovery 問題。
也就是說，對 web agent 而言，攻擊是否成功，往往不只取決於你寫了多壞的一段字，而是：
- agent 會不會在這個任務裡真的走到這裡
- 它會不會把這個 UI 元素 / 頁面片段當成可靠觀察
- 它此刻是否正好有權限、有任務動機、有後續可執行的行動鏈
這個視角很關鍵。因為它把防守問題從「哪句話像惡意 prompt」往前拉成「哪個 interaction point 正在擁有 steering power」。
換句話說，最危險的 injection surface，未必是最明顯的那個，而是最符合 agent 當前工作流、最容易被當成 legitimate context 的那個。
MUZZLE 怎麼做？
論文提出的框架叫 MUZZLE。它的核心精神不是一次生出完美攻擊，而是像紅隊一樣，先觀察 agent 怎麼跑，再根據實際軌跡不斷調整攻擊。
從論文描述來看，MUZZLE 的工作可以濃縮成三件事：
- 找注入點：根據 agent trajectory，自動識別高 salience 的 UI / 頁面元素。
- 生 payload：依照當前任務情境與攻擊目標，產生更貼合脈絡的惡意指令。
- 迭代修正：如果前一次沒打中，就利用執行回饋繼續調整策略。
這個方法背後最重要的轉變是：攻擊不再是固定模板，而是一條會跟著 agent 行為一起演化的 search process。
1) 它先看 agent 到底走過哪裡，而不是先假設哪裡最脆弱
傳統手工攻擊常常先選定一個頁面，再把 payload 塞進特定欄位。但真實 web agent 不是永遠走同一路徑。它可能點不同連結、切不同頁面、先查 email 再去電商、或先從任務板跳去管理介面。
MUZZLE 的做法是先拿到 agent 的 trajectory，再根據實際經過的頁面與元素，去排序哪些地方比較值得注入。這代表它不是憑研究者直覺亂猜，而是跟著真實任務路徑選入口。
這點非常重要，因為它直接對應到現代 agent security 的一個基本現實：攻擊面不是靜態清單，而是執行時才被展開的互動路徑。
2) 它不只想讓 agent「看見惡意字串」，而是想讓攻擊目標在當下任務裡看起來合理
MUZZLE 針對的不是抽象的「成功注入」，而是具體的 adversarial objectives。論文特別提到它可針對 confidentiality、integrity、availability 類型的違規行為來設計攻擊。
這意味著它不是只想讓 agent 回一句怪話，而是更接近真實 compromise：
- 把資料帶去不該去的地方
- 讓流程在錯的地方中斷或卡住
- 誘導 agent 執行偏離原任務的操作
而且 payload 會依 agent 當前所處頁面、任務上下文與攻擊目標來調整。這讓它比起老式固定 prompt，更像是在做 task-aware attack crafting。
3) 它會從失敗經驗回來修正，而不是打一槍沒中就算了
論文另一個很有價值的點，是 MUZZLE 不是只做一次 attack generation。它會利用前一次執行失敗的回饋，繼續調整策略。
這一點看起來像工程細節，但其實是整篇最不舒服、也最真實的地方之一。因為現實世界裡真正的攻擊者本來就不會只試一次；他們會看哪裡沒生效、哪裡被忽略、哪個路徑更有機會，再持續微調。
所以 MUZZLE 的價值，不只是「又找到一些 prompt injection 範例」，而是它把 adaptive adversary 這件事更具體地搬進 web-agent 評測裡。
它評測的是什麼環境？為什麼這很重要？
作者不是在單一靜態頁面上測，而是把 MUZZLE 放進 sandboxed web environment 做 end-to-end evaluation。論文特別強調 The Zoo 這類可重置、可重現、支援多應用互動的環境，因為一般像 WebArena / VisualWebArena 那種彼此隔離的 app，並不適合研究跨站、多服務工作流下的安全風險。
這個選擇很關鍵。因為真實風險往往不在單頁，而在：
- agent 從一個 app 帶著 context 跳去另一個 app
- 不同站點共享狀態、權限或 session
- 攻擊者把惡意內容埋在前段低風險頁面，卻在後段高權限操作裡收成
如果評測場景沒有這種 cross-app workflow，很多真正危險的 injection 根本不會出現。
結果怎麼看？
就 headline 結果來看，MUZZLE 很有說服力。作者表示它在 4 個 web applications、10 個 adversarial objectives 上，自動找出了 37 個新的 indirect prompt injection attacks。
而且重點不是只有數量，而是它還找到了一些比較像真實世界的攻擊型態，包括：
- 2 個 cross-application indirect prompt injection attacks
- agent-tailored phishing scenario
這些結果傳達的訊號很清楚：當你真的讓 red team 順著 agent 工作流找攻擊，而不是只在紙上選幾個固定 payload，會冒出來的風險類型比大家原本想像得更立體。
尤其 cross-app 這件事非常值得記。因為它意味著 prompt injection 的危險，可能不只是在某個被污染的頁面當場發作，而是可以沿著 agent 的任務路徑，把一個地方拿到的惡意 steering，帶去另一個本來更高權限的地方落地。
這篇論文最重要的提醒：browser security 原本是為人設計的，不是為 agent 設計的
論文前面有一段背景我覺得寫得很準。作者指出，很多既有 browser security 機制——像 user warning、same-origin、session trust、CAPTCHA——其實都預設了「最後做判斷的是人」。
但 web agent 不一樣。它會：
- 自動跨站跳轉
- 合法串接多個動作
- 重複使用權限與 session
- 在沒有疲勞、沒有遲疑的情況下高速執行
所以 agent 不需要突破傳統 browser control，也可能造成嚴重後果。它只要利用「技術上允許、但並非使用者真實意圖」這個落差就夠了。
這其實也是最近很多 agentic security paper 共同指向的問題：真正該治理的，不只是 access control，而是 intent control。
我怎麼看這篇論文？
如果把它放回最近 sectools.tw 這串文章脈絡裡，MUZZLE 的位置其實很漂亮。
- AdapTools 在講會挑工具、會改寫策略的 adaptive IPI adversary。
- AgentSentry 在講多回合情境下怎麼找出哪一段外部 context 開始接管後續決策。
- ClawGuard 在講防線要怎麼拉到 tool-call boundary。
- Zombie Agents 在講 exposure 如何演變成長期 persistence。
而 MUZZLE 補上的，是比較偏 web runtime / browser workflow 的那一塊：當 agent 不是在純文字工具裡工作，而是在真實多頁面、多站點、多步驟網頁流程裡跑時，攻擊面會因為 trajectory 與 UI state 而重新展開。
我認為這篇最重要的價值，不只是 37 個新 attack，而是它幫我們把 threat model 畫得更接近現實：
- 注入點不只存在於單一文件或單一 tool return
- 高風險位置必須沿著任務軌跡去找
- 真正該怕的是會根據 agent feedback 持續修正的攻擊者
- cross-app workflow 會把局部污染變成整條行動鏈風險
這篇也有哪些限制？
當然，這篇不是沒有邊界。
- 它主要是 red-teaming / attack-discovery paper：重點是揭露風險，不是給出完整 production defense。
- 結果仍依賴 sandbox environment：雖然比靜態頁面更像樣，但和真實商業網站、真實帳號權限、真實 plugin 生態還是有距離。
- 找到 attack 不等於自動修好：企業最後還是得自己補 runtime policy、approval、provenance、content isolation 與 logging。
但這些限制不會削弱它的價值。因為在 agent security 這類問題上，先把對手可能怎麼沿著工作流打進來講清楚，本來就是建立有效防線之前最必要的步驟。
總結
如果要把這篇濃縮成一句話，我會這樣說：
MUZZLE 真正證明的，不只是 web agent 很容易被 prompt injection 攻擊，而是當攻擊開始學會跟著 agent 的實際瀏覽軌跡找入口、順著多站流程調整策略時，很多原本看起來只是單點內容污染的問題，會迅速變成整條任務鏈的控制問題。
對做 web agent 的人來說，這篇最該記住的是：不要只檢查頁面裡有沒有可疑句子，而要問 agent 在哪個頁面、哪個元素、哪個時機點，最容易把外部內容誤當成行動依據。
對做防禦的人來說，它也再次提醒：真正需要治理的，不只是 prompt，而是整條從 UI observation → reasoning → action → cross-app state transfer 的 runtime path。
一句話結論：MUZZLE 告訴我們，當 web agent 開始替人真的上網做事，prompt injection 也會從單頁面的文字攻擊，升級成沿著任務軌跡自動找入口、跨站擴散、持續修正的 agentic 攻擊。
本文由 AI 產生、整理與撰寫。