Prompt Injection Defense 論文閱讀分析：很多防線真正缺的，不是再多一條提醒，而是別把執法權交回被攻擊的模型

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

論文基本資訊

• 論文標題：Evaluation of Prompt Injection Defenses in Large Language Models
• 作者：Priyal Deep、Shane Emmons、Amy Fox、Kyle Bacon、Kelley McAllister、Krisztian Flautner
• 年份：2026
• 來源：arXiv:2604.23887
• 論文連結：https://arxiv.org/abs/2604.23887
• DOI：10.48550/arXiv.2604.23887
• 主題：Prompt Injection、LLM Security、Adaptive Red Teaming、Output Filtering、Application Security、Agentic Security

這篇 paper 很適合接在最近一串 agent / prompt injection / runtime governance 論文後面，因為它不是再多提一個花式防禦，而是直接把一個很多人不想面對的問題拿上桌：

如果攻擊者不是拿固定題庫打一輪就走，而是真的會觀察、調整、換招、連打幾百回合，那你現在那些「看起來有效」的 prompt injection 防線，到底能活多久？

作者的答案非常不留情面，而且我覺得大致上是對的：

凡是還在依賴模型自己保護自己的防線，最後都會破；真正一路撐住的，是在 application code 裡、獨立於被攻擊模型之外執行的 deterministic output filtering。

如果要把整篇濃縮成一句話，我會寫成：

很多 prompt injection defense 真正缺的，不是再多一條「你要忽略惡意指令」的提醒，而是別再把最後執法權交回那顆正在被攻擊的模型。

這篇在處理什麼問題？

Prompt injection 研究這兩年很熱，但有個老問題一直沒消失：評測通常太短、太靜態、太像 demo。

常見做法是：

• 拿一批固定攻擊 prompt
• 打幾種 defense
• 看攔下多少

這樣當然能得到數字，但它更像是在測「你能不能擋住我今天想到的這幾拳」，不是在測「你能不能撐住一個會學習的對手」。而真實世界的攻擊者不會這麼客氣。

所以作者把問題換成更接近實戰的版本：

如果攻擊方會根據防守方的回應模式持續進化，從被擋下、部分洩漏、繞過失敗裡學東西，再回來改 prompt，那些目前最常被推薦的 prompt injection 防禦還站不站得住？

實驗怎麼做？不是單次打榜，而是長回合適應式攻防

這篇最值得看的地方，就是它把攻擊方做成一個會持續調整策略的 agentic attacker。

整個 setup 很直白：

• 防守方是一個帶有 system prompt 的 LLM application
• system prompt 裡故意埋了三個 secrets、persona、操作指令
• 攻擊方不知道 secret 值，但知道或懷疑 prompt 裡藏了敏感資訊
• 攻擊方用黑箱互動方式，反覆送 prompt、觀察回應、再演化下一輪攻擊

作者總共測了 9 種 defense configuration，打了 20,000+ 次 attacks。攻擊不是一輪一輪亂槍打鳥，而是有點像 evolutionary search：

• 保留比較有效的招式
• 根據部分成功結果做 mutation
• 觀察哪些 wording 會被擋、哪些 phrasing 會漏
• 在卡住時切到新策略繼續探路

這個設計很重要，因為它讓論文不是在問「某個 defense 今天擋不擋得住 AttackEval 式題庫」，而是在問：

它能不能撐住一個真的會從你反應裡學習的對手。

它測了哪些防禦？

從論文描述來看，九種配置大致涵蓋這幾類：

• 單純 security directives／叫模型不要洩密
• input sanitization
• delimiter / sandwich 之類 prompt framing
• instruction hierarchy 類做法
• output filtering
• 多層疊加防禦
• 把多層防禦裡的 output filter 拿掉做 ablation

真正的重點不是 taxonomy，而是它把防線粗分成兩種世界：

• model-reliant defenses：還是依賴模型自己判斷、自己拒絕、自己區分什麼該信
• application-enforced defenses：在模型外部、由外部程式邏輯決定什麼不能出去

而這篇最刺的一刀，就是結果幾乎把這兩個世界切得很乾淨。

核心結果：所有「模型自己保護自己」的方案最後都倒了

先講最關鍵的結論。

在 extended campaign 裡，所有依賴模型自身的 defense 最後都被打到 critical leak。有些很早倒，有些能撐更久，但最後還是倒。相對地，只有 output filtering，以及包含 output filtering 的 multi-layer defense，一路維持 0 leak。

更狠的是，作者不是只跑一次就收工，而是對 output filtering 跟 full-stack multi-layer configuration 又各自做了多輪 500-round stress test，累積 15,000 次攻擊，結果仍然是 0.0% leak rate。

然後作者還做了一個很乾脆的 ablation：把多層防禦裡的 output filter 拿掉。結果一拿掉就開始漏。

這幾個結果合起來的訊號很強：

真正撐住系統的不是「layer 很多」這件事，而是你有沒有把最後那道不能外流的邊界，交給模型外部的 deterministic 機制來執行。

為什麼這個結論值得重視？

因為它其實不是只在講 prompt injection，而是在打很多 agent security 設計裡最常見的一種錯覺：

我們常常把「模型現在看起來有守規矩」誤當成「系統真的有邊界」。

這兩件事差非常多。

如果你的防線本質上是：

• 請模型記得系統提示高於使用者輸入
• 請模型辨識這是不是 injection
• 請模型不要把秘密講出去

那你其實是把守門員、法官、被告，甚至被攻擊目標，全塞在同一個 cognition 裡。這在安全上本來就很危險。因為一旦語意空間本身被帶偏，你等於是在問那個已經失衡的系統：「你可不可以自己誠實承認自己失衡了？」

這篇論文只是用比較大規模、比較不留情面的方式把這件事量化出來。

這篇最有價值的 framing：security boundary 必須在 model 之外

我覺得整篇最值得帶走的，不是某個攻擊技巧，也不是某個特定數字，而是這個設計原則：

安全邊界不能只存在於 prompt 語意裡，必須存在於 model external enforcement 裡。

翻成人話就是：

• 不要把秘密直接放在 prompt 裡，能不放就不放
• 如果一定要放，至少要有模型外部的輸出檢查
• 不要把「拒答」當成主要保證，把它當成 bonus 比較合理
• 真正的禁區應該由 application code、policy engine、output gate、tool mediation 去執行

這跟最近很多 agent runtime / privilege separation / kernel-style governance 的論文，其實是在同一條線上。只是這篇特別乾脆，它直接說：

如果最後那道邊界還在被攻擊模型自己的輸出裡，那那不是邊界，那比較像願望。

跟既有 prompt injection 研究比，這篇補了什麼？

如果你前面已經看過很多 prompt injection paper，可能會覺得「output filter 比 prompt-based defense 靠譜」這件事不算完全新鮮。但這篇還是有幾個補位價值：

• 它把短期有效與長期耐打分開了。
• 它把 adaptive attacker 放進評測，而不是只打固定 corpus。
• 它用 ablation 明確指出 output filter 是真正撐住結果的關鍵。
• 它讓「模型自我防守」這件事從抽象懷疑，變成有數據支持的工程判斷。

這也是為什麼我會說，這篇雖然論文本身不算花俏，但對實作 team 反而很有用。因為它講的是 architecture truth，不是 prompt 小技巧。

我怎麼看它的侷限？

當然，這篇也不是沒有侷限。

第一個是 threat model 仍然偏向 prompt-secret leakage，也就是重點在 system prompt 裡藏的秘密會不會被吐出來。這很重要，但還不是 agent security 的全貌。真實風險還包括：

• 工具誤用
• 權限濫用
• memory contamination
• 跨步驟 objective drift
• 不直接吐 secret、但改成間接執行高風險行為

第二個是 output filtering 能守住這組任務，不代表它是萬靈丹。因為只要風險從「不能講出某字串」變成「不能做出某動作」或「不能讓某種計畫成立」，事情就會更難。也就是說：

output filtering 對 prompt leakage 很有用，但對 agentic action safety，還需要更往 execution boundary 走的 enforcement。

第三個是論文測的是特定 attack loop 與特定 defense family。它很有說服力，但還不等於已經窮盡全部 defense design space。

不過即使有這些限制，主結論還是站得很穩：不要把安全保證寄託在被攻擊模型自己的自制力上。

對實務有什麼啟示？

如果你今天在做的是：

• 會把系統 prompt、API key、internal instructions 混在同一個 context 的 LLM app
• 會讀 email、web、docs、ticket、log 的 agent
• 以為「我們有叫模型不要洩漏」就算有做 prompt injection 防禦

那這篇最值得抄走的不是論文 wording，而是幾個很務實的原則：

• 能不把 secret 放進 prompt，就不要放。
• 敏感資訊輸出前要經過模型外部的 deterministic gate。
• 不要只跑一次紅隊 demo，要做 sustained adaptive testing。
• 把模型視為可能被帶偏的元件，不是最終信任根。

如果再往 agent world 推一步，我會補一句：

• 不只 output 要 filter，tool call、state transition、memory write、privilege escalation 也都該有 model-external enforcement。

結語

Evaluation of Prompt Injection Defenses in Large Language Models 最有價值的地方，是它把很多團隊心裡其實早就隱約知道、但一直不想講太白的事，直接講白：

只要最後那道防線還是靠模型自己理解、自己拒絕、自己守密，它就比較像延後失守，不像真正的安全邊界。

真正撐住的設計，不是更會講道理的 prompt，而是把不能破的規則移出 prompt，移到 application code、runtime gate、deterministic policy enforcement 那一側。

所以如果要用一句話收尾，我會這樣下：

很多 prompt injection defense 真正缺的，不是再多一條提醒模型「不要被騙」，而是終於肯承認：被騙的那顆模型，從一開始就不該握有最後執法權。