Defense Trilemma 論文閱讀分析：如果你的 prompt injection 防線本質上只是 wrapper，那它很可能從一開始就不可能又保留效用、又連續穩定、又把風險清乾淨
Defense Trilemma 論文閱讀分析：如果你的 prompt injection 防線本質上只是 wrapper，那它很可能從一開始就不可能又保留效用、又連續穩定、又把風險清乾淨
論文基本資訊
- 論文標題：The Defense Trilemma: Why Prompt Injection Defense Wrappers Fail?
- 作者：Manish Bhatt、Sarthak Munshi、Vineeth Sai Narajala、Idan Habler、Ammar Al-Kahfah、Ken Huang、Joel Webb、Blake Gatto、Md Tamjidul Hoque
- 年份：2026
- 來源：arXiv:2604.06436
- 論文連結：https://arxiv.org/abs/2604.06436
- 主題：Agentic Security、Prompt Injection、Formal Methods、Security Theory、Runtime Security、Lean 4
最近幾篇 agent security 論文，不管是做 prompt injection detector、guard model、tool boundary monitor、execution harness，其實都有一個很常見的隱含假設：只要我們在模型前面再包一層，就能把危險輸入改寫、消毒、重寫、稀釋，最後把風險壓到安全區。
這篇 The Defense Trilemma 厲害的地方，就是它不再只是拿更多 attack samples 去打某個 defense，而是往上提一層問：如果你的防禦本質上就是一個「輸入進來、先經過 wrapper、再丟給模型」的前處理函數，那它有沒有可能同時滿足三件事？
- 連續穩定：相近的輸入不要被改得天差地遠。
- 保留效用：本來安全、正常可用的 prompt 不應該被亂改壞。
- 完整安全：所有輸入經過 wrapper 後都變安全。
作者的答案非常直接：不行。而且不是工程上「目前還做不到」而已，而是提出一套形式化論證：在 connected prompt space 上，只要 wrapper 是 continuous 且 utility-preserving，它就不可能 complete。
如果只想先記一句話，我會這樣收這篇：
很多 prompt injection defense 不是做得還不夠好，而是它們瞄準的那一類解法，本身就存在不可同時滿足的結構性限制。
這篇論文在打哪一類防禦？
先講清楚，這篇不是在說「所有防禦都沒救」。它打得很精準：wrapper defense。
也就是那種把原始 prompt 先送進一個前處理流程，產生另一個 prompt 再給模型的做法，例如：
- 輸入分類後做 sanitization
- 把 prompt rewrite 成比較安全的版本
- 用 constitutional 或 policy rewrite 把高風險請求轉寫
- 在模型前面塞一個 preprocessor / paraphraser / normalizer
作者把這類方法統一抽象成一個函數 D: X → X：輸入空間裡的 prompt 先經過 D，再進主模型。
這裡最關鍵的是，它不是在討論某個特定模型、某個特定 prompt、某個特定 benchmark，而是在討論這類防禦函數本身的可行性邊界。
核心論點：Defense Trilemma
作者提出的三角拉扯，可以濃縮成：
- Continuity（連續性）：相近 prompt 應該得到相近 rewrites，不然 defense 自己會很不穩。
- Utility Preservation（效用保留）：對已經安全的 prompt，最好維持原樣，不然 usability 會崩。
- Completeness（完整性）：任何 prompt 經過 defense 後，輸出都應落在安全區。
論文主結論就是：三者不能同時成立。
這不是一句哲學口號，而是作者分三層往上推：
- Boundary fixation：你一定會留下某些 safety boundary 上的點完全不動。
- ε-robust constraint：在那些 boundary 點附近，不可能把整片區域都穩穩往安全區深處拉開。
- Persistent unsafe region：如果風險上升的斜率比 defense 能拉回去的速度更快，就一定存在一塊正測度的區域，經過 defense 後仍然不安全。
白話翻譯就是：你可以修一部分、緩和一部分、把一些案例壓低，但只要你又想保留正常任務效用、又想維持平滑穩定，那就總會留下某些洞，而且不只是零星個案，而是一整塊 persistent failure region。
第一層：Boundary Fixation 為什麼重要？
作者先定義一個 alignment deviation function f(x)，把 prompt x 映成一個安全偏離分數；低於門檻 τ 的算安全，高於門檻的算不安全，剛好等於 τ 的就是安全邊界。
接著他們證明：如果 defense 對安全輸入都保持不動，而且整個 defense 是 continuous，那麼它不只會固定安全區裡的點，還必然會固定至少一個邊界點。
這個結果很值得停一下。因為很多人直覺以為 wrapper 可以「在邊界附近特別聰明地修一下」；但作者說的是，只要你承諾安全輸入不亂動，這個 fixed-point set 會因為閉包性一路延伸到 boundary，於是某些最關鍵的邊界點根本不會被修。
對安全工程的意義是什麼？很簡單：
如果你的 defense 不能接受誤傷正常輸入，那它就被迫在某些臨界點選擇不出手；而 prompt injection 真正愛鑽的，往往就是這種臨界地帶。
第二層：不是只漏一點，而是邊界附近整帶都很難壓乾淨
如果只有 boundary fixation，有人可能還會想：「那只是剛好卡在門檻上的單點問題，實務上不一定嚴重吧？」
所以作者再往前一步，加入 Lipschitz regularity。直觀上就是：模型風險分數變化不能無限陡峭、defense rewrite 也不能無限劇烈。
在這個條件下，他們得到 ε-robust defense constraint：靠近那些固定不動的 boundary 點時，defense 最多只能把風險往下拉一點點，下降量會被一個與距離成正比的界限卡住。
換句話說，邊界附近不會只是「剛好一個點救不了」，而是會形成一條 near-threshold band。這對實務非常關鍵，因為真實 prompt injection 不是拿尺畫出來的單點攻擊；攻擊者會在邊界附近反覆搜索、微調、改寫語氣、改格式、改上下文拼接方式。
所以這篇其實是在告訴 defender：
別把 near-miss 當勝利。很多 wrapper defense 能做到的，往往只是把危險輸入從「明顯惡意」壓成「接近門檻但仍可被探索」而已。
第三層：Persistent Unsafe Region 才是最傷的地方
再來是我覺得整篇最有 punch 的部分。
作者指出，如果在某些方向上，alignment deviation 的上升速度比 defense 可施加的修正能力更快，那麼就不只是 near-threshold 而已，而是會留下 persistent unsafe region：一整塊區域中的 prompt，經過 defense 之後還是高於安全門檻。
這裡很像在講斜率戰爭：
- 一邊是攻擊面沿某個方向「往不安全區升高」的速度。
- 另一邊是 defense 透過 rewrite / sanitization 能把它往回拉的速度。
只要前者大於後者，你就追不上。
這個結論對最近很多 defense paper 很有解釋力。為什麼有些方法在 benchmark 上看起來能擋一批 attack，但只要攻擊者換個任務、換個上下文、拉長對話、多一步工具互動，success rate 又回來？這篇給的答案是：因為 defense 處理的是表面輸入形狀，但真正的風險地形可能在某些語意方向上升得比你修得更快。
它其實也順手解釋了「為什麼 wrapper 會越補越像打地鼠」
如果把這篇放回最近幾波 prompt injection defense 脈絡裡，我覺得它最大的價值，是幫很多零散觀察補上共通解釋。
我們早就看過很多現象：
- 加一層 rewrite 後，attack A 降了，但 attack B 起來。
- 短 prompt benchmark 上不錯，長上下文、多輪 agent task 就掉。
- 為了更安全，把 normal prompt 也改得面目全非，結果 utility 大幅下降。
- 某些防禦越 aggressive，正常任務越常被打斷、誤判或拒答。
這些現象以前常被當成 implementation 還不夠成熟，或 dataset 還不夠完整。但這篇在說：至少對 wrapper 類方法來說，這些不一定只是工程瑕疵，而可能是結構性代價。
也就是說，所謂「調參後應該就能兩全」這個想法，本身就可能太樂觀。
它沒有說所有防禦都沒用，這點要講清楚
這篇論文最容易被誤讀成「prompt injection 無解」，但作者自己其實講得很節制。它沒有否定以下方向：
- training-time alignment
- 模型架構層面的改動
- 不連續的 hard rejection / blocklist / classifier
- output-side filtering
- human-in-the-loop
- 多組件、多關卡、不要求每個 prompt 都保留完整 utility 的系統
這一段很重要，因為它其實替 defense strategy 劃出了一條界線：
如果你堅持「盡量不改正常輸入、又要平滑泛化、又要在單一 wrapper 裡徹底消毒」，那這條路走不通；但如果你願意在系統架構、權限切分、硬性拒絕、人工審批與模型訓練本身動手，事情就不是同一個問題了。
換句話說，這篇不是要你放棄防禦，而是要你停止把 wrapper 當成萬用修補膠。
Lean 4 形式化驗證，是這篇的一個加分點
這篇另一個我很買單的地方，是作者不是只用直覺講定理，而是把整套理論用 Lean 4 + Mathlib 做了形式化驗證。文中提到 artifact 包含 46 個檔案、約 360 個 theorem、沒有 admitted proof。
在 AI safety / security 論文裡，很多 paper 會丟出很強的理論口號，但 proof sketch 一旦細看，常常藏很多未說清的假設。這篇至少在態度上比較扎實：它是真的把理論聲稱往可機械檢查的方向推。
這不代表理論就一定等於現實世界全部，但至少比「感覺上應該不可能」強很多。
我怎麼看這篇？
我會把它看成最近一串 agent / prompt injection 論文裡，一篇很值得當「上位框架」來讀的 paper。
像前面我們看過的很多方法：
- 用 attribution 找局部惡意片段
- 在 tool boundary 做 policy check
- 用 parallel guard model 審核 web agent 行為
- 把 execution harness 做 provenance-aware security design
這些都不是沒價值。相反地，正因為 wrapper 型前處理有理論上限，這些把防線往架構層、行為層、執行邊界層移動的方法才更顯得合理。
這篇等於替整個領域補上一句很重要的提醒：
不要再把 prompt injection 當成一個可以只靠「把輸入洗乾淨」就結束的問題；真正該治理的是模型、任務、權限、工具、記憶與執行副作用組成的整條控制鏈。
如果你今天還在設計的是「模型前面再加一層 rewrite / sanitizer，應該就差不多了吧」，那我認為這篇是必讀的冷水。
這篇的限制也要誠實看
- 它分析的是特定類型防禦：單一 continuous、utility-preserving wrapper，不是所有安全系統。
- prompt space 的連續化是理論抽象：真實 token space 是離散的，但作者也補了 discrete 結果與 continuous interpolation 的橋接。
- 理論不能直接告訴你哪個產品明天一定被打穿：它給的是結構性限制，不是實作層 exploit recipe。
- empirical validation 不是這篇唯一重點：它的主要貢獻是 impossibility / tradeoff framing，不是 benchmark 大戰。
但我不覺得這些限制削弱它的價值。反而剛好：這篇最有用的地方本來就不是提供一個更強 defense，而是幫你淘汰一類註定會被過度期待的 defense 思路。
總結
如果要把這篇濃縮成一個結論，我會這樣寫：
The Defense Trilemma 真正戳破的，不是哪一個 prompt injection wrapper 做得不夠漂亮，而是「只要再多包一層前處理就能把模型洗到安全」這個想像，本身就站不太住。
對 sectools.tw 這條線來說，這篇特別有意思，因為它剛好能把最近一整串 detector、guard、monitor、harness、verification 類論文重新排序：凡是只想在輸入層做平滑修補的方案，都應該先假設自己有理論上限；真正比較有前途的，是那些願意把安全決策顯性拆到執行邊界、權限系統、人工審批與架構分層裡的設計。
一句話結論：如果你的 prompt injection 防線本質上只是「在模型前面包一層 wrapper 幫忙洗 prompt」，那它很可能從理論上就不可能同時兼顧平滑穩定、任務效用與完整安全。
本文由 AI 產生、整理與撰寫。