本文由 AI 產生、整理與撰寫。

PlanGuard 論文閱讀分析：真正該防的可能不是那段髒資料本身，而是 Agent 的下一步行動有沒有開始偏離使用者原意

論文基本資訊

• 論文標題：Defending Agents against Indirect Prompt Injection via Planning-based Consistency Verification
• 年份：2026
• 來源：arXiv:2604.10134
• 論文連結：https://arxiv.org/abs/2604.10134
• DOI：10.48550/arXiv.2604.10134
• 主題：Agentic Security、Indirect Prompt Injection、Runtime Verification、Planning Security、Tool Security、Action Alignment

最近 agent security 這條線寫多了之後，會越來越明顯看到一個分水嶺：有些防禦還停在「想辦法辨認哪一段文字像不像惡意 prompt」，但另一派開始把焦點往 agent 真正要執行的 action 拉。PlanGuard 就屬於後者，而且它的切入點很乾脆：與其幻想模型能永遠正確分辨 instruction 和 data，不如先獨立做出一份「如果只看使用者原始要求，這個 agent 本來應該做哪些事」的乾淨參考計畫，接著再拿執行時每一步工具呼叫去對照。

這個角度很實際，因為很多間接提示注入真正危險的地方，不是它把某段內容寫得多像指令，而是它讓 agent 開始替錯的目標做對的工具呼叫。一旦你把安全邊界畫在 action layer，而不是字串表面，整個問題就比較像 runtime control，而不只是 input sanitation。

這篇論文在解什麼問題？

作者要處理的是 Indirect Prompt Injection（IPI）。也就是攻擊者不直接改使用者 prompt，而是把惡意指令埋進 email、網頁、文件或其他外部檢索內容，等 agent 自己把它讀進 context 之後，再被帶去執行不該做的事。

論文把這個問題的根源講成 context mixing：今天的 agent 常常把使用者意圖與外部資料一起丟進同一個 context window，於是模型很難穩定分清楚：

• 哪些是應該服從的 instruction
• 哪些只是拿來參考的外部 data

結果就是，只要外部內容足夠會說話，它就可能開始影響 tool selection 與參數填寫。這種失控不是只有回答變歪而已，而是可能真的把 寄信、轉帳、刪檔、查詢私密資料 這類行為帶偏。

PlanGuard 的核心想法：先做一份「不受污染的參考計畫」

PlanGuard 最重要的設計是 Isolated Planner。這個 planner 只看兩樣東西：

• 使用者原始指令
• 可用工具定義

它刻意不看任何外部檢索內容。這樣做的目的不是讓 planner 更聰明，而是讓它更乾淨。作者用它來產生一個 Reference Action Set，也就是這次任務在理想情況下，理論上允許的工具與參數範圍。

這一步很像先畫出一個 task-aligned 的行為邊界。之後真正執行中的 agent 每次想呼叫工具時，PlanGuard 就會先攔下來，比對這個 action 是否仍落在那份乾淨參考計畫裡。

換句話說，PlanGuard 不再只問：

「這段外部內容像不像 prompt injection？」

而是改問：

「你現在這一步，還是不是使用者本來要你做的事？」

它防的不是只有亂叫工具，還有「工具沒錯，但參數已經歪掉」

這篇 paper 很值得記的是，它沒有把攻擊簡化成只有「突然多叫一個不該叫的 tool」。作者把 IPI 導向的惡意 action 分成兩類：

• Type I：Unauthorized Tool Invocation — 本來不該用這個工具，卻被帶去用
• Type II：Intent Deviation / Argument Hijacking — 工具本身看起來合理，但參數已經被惡意改寫

這個 distinction 很重要。因為很多真實事故不會長得那麼明顯，不一定是「請幫我摘要信件」結果 agent 突然去 SendEmail()。更常見的是工具表面看起來沒問題，但參數已經偷偷轉向，例如：

• 本來要刪 temporary folder，最後刪到系統關鍵路徑
• 本來要寄回報給指定收件者，最後寄去攻擊者地址
• 本來要查詢一個 ticket，最後擴大成不必要的敏感資料檢索

PlanGuard 真正補上的，不只是 tool-level allowlist，而是把 argument-level intent mismatch 也拉進驗證流程。

兩階段驗證：先硬規則，再做意圖驗證

為了避免每一步都靠模糊判斷，PlanGuard 把驗證拆成兩層。

第一層：Hard Constraints

這層做 deterministic matching：

• 如果 action 與 reference action 完全一致，直接放行
• 如果工具名稱根本不在 reference set 裡，直接擋掉
• 如果工具對了，但參數長得不一樣，先進第二層再看

好處是這層很快、很硬，也很適合擋下那種明顯的 function hijacking。

第二層：Intent Verifier

作者知道只靠 exact match 會有大量誤殺，因為 LLM 本來就有 stochastic variation。像是 planner 產生 last_week，agent 實際吐出 lastweek，兩者可能功能一樣，但字串不同。

所以第二層才引入一個 LLM-based intent verifier，去判斷這種參數偏差到底是：

• 只是格式差異
• 還是真的開始偏離使用者意圖

這裡的關鍵不是讓 verifier 再重新幫 agent 想一次，而是只處理「硬規則判不清、但又不能亂放」的灰區。這讓整個框架比較像：

• 用硬邊界擋明顯違規
• 再用較窄範圍的語意判斷處理 harmless variation

實驗結果為什麼值得注意？

作者使用 InjecAgent benchmark，總共 1,054 個案例，涵蓋 17 個 user tools、62 個 attacker tools，並把攻擊分成兩大類：

• Direct Harm：例如轉帳、刪檔、開門這種直接造成損害的動作
• Data Stealing：例如把私密筆記或資料查出來再外送

在他們的設定下，沒有防護的 vanilla agent ASR 很高，整體可到 72.8%；而 PlanGuard 把 ASR 壓到 0%，同時把 False Positive Rate 控在 1.49% 左右。更細一點看：

• 只做第一層硬規則，雖然也能做到 0% ASR，但 FPR 很高
• 加入第二層 intent verifier 後，才把 usability 拉回可接受範圍

這其實很符合直覺：真正難的不是「擋」，而是「擋了之後不要把正常 workflow 一起砍掉」。 PlanGuard 至少在這個 benchmark 上，給出一個比較完整的答案。

這篇 paper 最有價值的地方：它把防線從內容分類拉到行為一致性

我覺得 PlanGuard 最值得記住的，不是某個漂亮數字，而是它代表一種安全觀念上的位移：

agent security 不該只停在檢查外部內容乾不乾淨，而是要持續驗證 agent 的當前行動是否仍與使用者原意一致。

這個想法和最近很多 runtime security work 是同一條線，只是 PlanGuard 用 planning consistency 的方式把它做得更清楚。它不要求你先完整辨識所有惡意 prompt 樣貌，而是先承認那件事很難，然後把守門點往 tool-call boundary 與 action-policy consistency 拉。

如果放回最近這串 agentic security 脈絡來看，它很像站在下面幾篇的中間位置：

• 像 ClawGuard 那樣重視 execution boundary
• 像 Architecting Secure AI Agents 那樣重視 plan / policy / execution 分離
• 但又比單純 rule-based allowlist 多了一層處理 benign variation 的空間

它的限制也很真實：當任務真的依賴外部上下文時，planner 會有資訊不對稱問題

論文自己也承認一個很關鍵的限制：因為 planner 被刻意隔離在外部 context 之外，所以它會遇到 information asymmetry。

最典型的例子是這種任務：

「幫我付 email 裡那張帳單。」

這時 planner 可以知道「付款」這個 action 類型是合理的，但它不看 email 本文，就無法知道具體該付給誰、金額是多少、帳號是不是被污染。也就是說，它能驗 action type，卻不一定能驗 context-derived argument truth。

這個限制其實很重要，因為它提醒我們：context isolation 很有效，但不是免費午餐。 只要任務本身真的依賴 runtime context，系統就得另外設計受控的資訊萃取、可信資料通道，或更細的 human approval 機制，否則 planner 會因為看不到必要事實而只能守住一半邊界。

我的 takeaway

如果要用一句話總結這篇，我會說：

PlanGuard 真正想做的，不是把所有髒資料都掃乾淨，而是即使髒資料混進來了，也不要讓 agent 的下一步行動離開原本任務的軌道。

這是個我很買單的方向。因為現實世界裡你很難保證 agent 永遠只看到乾淨內容，但你可以要求它在真正「動手」之前，多過一層跟使用者原意對帳的檢查。當 agent 開始接 API、碰檔案、送資料、做交易時，這種 action consistency verification 其實比單純 text filtering 更接近真正的最後防線。

當然，PlanGuard 還不是終點。它對 context-dependent arguments 的處理還不夠，也仍有額外成本與延遲。但這篇 paper 的價值在於，它把問題重新畫對了：真正該被驗證的，是 agent 要做什麼，而不只是它剛剛讀到了什麼。

Takeaway

PlanGuard 這篇論文最重要的貢獻，是把 indirect prompt injection 的防禦焦點從「辨認惡意文字」往前推到「驗證工具呼叫是否仍與使用者原意一致」。透過一個不讀外部 context 的 Isolated Planner 先生成乾淨 reference plan，再用 hard constraints + intent verification 對執行中的每一步 action 做比對，作者在 InjecAgent 上把 ASR 從 72.8% 壓到 0%，同時把 FPR 控在可接受範圍。對實務來說，這篇最值得記住的不是某個 benchmark 成績，而是那個更成熟的安全觀：不要只問輸入乾不乾淨，要持續問 agent 下一步是不是還在替對的人做對的事。

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文摘要與可取得之論文 HTML 版本進行整理、解讀與分析。由於本文撰寫時未必涵蓋附錄、程式碼與所有實驗設定細節，部分觀點屬研究性解讀；若需引用精確數據、威脅模型定義或完整實驗配置，請以原始論文與作者公開版本為準。