Prompt Injection Kill Chain 論文閱讀分析：很多 agent 真正缺的，不是再多一個過濾器，而是先看清楚髒東西在哪一層被寫進系統

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

論文基本資訊

• 論文標題：Stage-Level Tracking of Prompt Injection Across Attack Surfaces and Model Safety Tiers
• 作者：Haochuan Wang、Alvin Wan、Shivam Singhal、Michael B. Rush、Ari Morcos、Robin Jia
• 年份：2026
• 來源：arXiv:2603.28013
• 論文連結：https://arxiv.org/abs/2603.28013
• DOI：10.48550/arXiv.2603.28013
• 主題：Prompt Injection、LLM Agents、Multi-Agent Security、Runtime Evaluation、Pipeline Architecture、Defense-in-Depth

這篇 paper 最值得看的地方，不是它又多做了一套 prompt injection benchmark，而是它直接指出一個業界很常見、也很危險的偷懶：很多團隊到現在還在用「有沒有成功打中一次」這種二元指標評估 agent 安全，但真正的風險其實是攻擊在整條 pipeline 裡面傳到哪一層、卡死在哪一層、又是在哪一層突然被放大。

作者把 prompt injection 從一個單點失敗事件，改寫成一條可追蹤的 kill chain。這個 framing 很重要，因為真實的 agent 系統本來就不是一顆模型直接回答而已。它會讀文件、寫記憶、轉交上下文、呼叫工具、跨 agent relay，最後才真的落到高權限動作。很多系統真正出事，不是因為第一步沒看見髒東西，而是因為後面某一個 write node、relay node、tool execution node 把它當成正常訊號一路送到底。

這篇論文在解什麼問題？

作者的出發點很直接：今天大家在測 prompt injection 時，常常只問一件事——attack success rate 是多少？ 但這種問法其實太粗了，因為它把整條 agent pipeline 壓扁成一個終點事件，於是你會看不見幾件真正有工程價值的事：

• 惡意內容是在曝光階段就被看到了，還是後來才被寫進 memory？
• 是 document ingestion 爆掉，還是 memory relay 爆掉？
• 模型本身有風險，還是架構設計把一個本來可控的風險送成不可控？
• 防禦機制到底是沒有偵測到，還是偵測了但放錯 channel？

對資安實務來說，這些問題比「最後有沒有成功」更重要。因為如果你不知道毒是怎麼傳的，就只能一直在 system prompt 上貼膠帶，然後祈禱不要再中。

作者的方法：把 prompt injection 當成一條四段式 kill chain

這篇最核心的設計，是用一個 cryptographic token 當 canary，去追蹤 prompt injection 在 agent pipeline 中的四個階段：

• EXPOSED：模型是否接觸到惡意內容。
• PERSISTED：惡意內容是否被寫進 memory、scratchpad、note、或其他可延續狀態。
• RELAYED：這個污染是否被轉送到其他 agent、其他步驟、或後續上下文。
• EXECUTED：最終是否真的影響行為，造成錯誤工具使用、指令遵從或安全破壞。

這四段拆法很漂亮，因為它讓 prompt injection 不再只是「輸入有沒有毒」，而變成一個狀態傳播問題。你可以看到毒訊號在哪裡第一次進系統、在哪裡被永續化、在哪裡跨節點轉送、又在哪裡真的變成 action。

換句話說，作者真正想說的是：

每個 agent system 都會先暴露在不可信內容面前，但不是每個 system 都必然把暴露一路升級成執行。

實驗設計：不是只比模型，而是比架構、channel 和防禦擺放位置

作者做了 950 次 run，涵蓋：

• 5 個 frontier LLM
• 6 種 attack surfaces
• 5 種 defense conditions

這裡最值得注意的是它的比較單位不是只有 model family，而是attack surface × defense placement × model safety tier 的組合。這樣做的好處是，你可以看見同一顆模型在不同 surface 上為什麼表現差這麼多，也可以看見一個 defense 為什麼在某條 channel 有效、換一條 channel 就漏光。

這比單純做「哪顆模型最安全」有意思得多。因為 production 上你真正能改的，往往不是 foundation model 本身，而是：

• 誰能寫 memory
• 哪個 agent 有 relay 權
• 文件清洗在哪一層做
• 工具呼叫前要不要經過另一顆驗證模型

這篇最重要的發現：prompt injection 其實是 pipeline architecture 問題

論文最有價值的一句話，在我看來不是哪個模型分數高，而是這個結論：every model is fully exposed, yet outcomes diverge downstream。

翻成白話就是：大家都會看到髒東西，但不是每個系統都會把髒東西一路送去執行。 真正拉開差距的，不一定是模型多聰明，而是你把哪些節點做成可寫、可傳、可執行。

作者舉的例子很直：

• Claude 在 memory-write 這一層把注入卡住，ASR 是 0/164。
• GPT-4o-mini 則有大約 53% 的 propagation。
• DeepSeek 在不同 surface 上甚至能從 0% 到 100% 大幅擺盪。

這個結果非常關鍵，因為它直接拆掉了一種常見幻想：只要換一顆「更安全」的模型，整條 agent pipeline 就會一起變安全。 不是。這篇告訴你，同一顆模型在不同資料入口、不同 relay 結構、不同 write policy 下，風險可以差到像是不同產品。

write-node placement 才是真正高槓桿的安全決策

如果要我只挑這篇最值得記的一個 takeaway，我會選這句：write-node placement is the highest-leverage safety decision。

作者發現，只要把 memory write 或持久化寫入的那一層，路由到一個經過驗證、比較可信的模型或防線上，很多 prompt injection propagation 可以直接被斷掉。這非常像資安裡的老道理：不是每個看到髒資料的元件都要變成可信寫入者。

很多團隊現在做 agent，很容易犯一個結構性錯誤：讓同一顆負責 ingest 外部資料的模型，順手也有權寫 memory、改 plan、觸發工具。這篇的數據等於在提醒你，這種設計其實就是把 exposure、persistence、execution 三件事綁死在同一條高風險路徑上。

更直白一點：

真正該被嚴格治理的，不只是輸入內容，而是「誰有資格把不可信內容變成系統狀態」。

第二個重點：很多防禦不是被攻破，而是根本放錯 channel

這篇另一個很強的發現，是所有四種 defense 都至少在一個 surface 上失效，而且失效原因甚至不需要 adversarial adaptation，只是 channel mismatch 就夠了。

這件事很殘酷，也很真實。很多 prompt injection defense 論文愛講「我們加了一層 classifier / sanitizer / policy checker」，但如果你的防線只盯可見文字、只盯 user message、只盯某種 JSON 欄位，那麼攻擊只要換個入口，整套保護就會像不存在。

所以這篇不是在說防禦沒用，而是在說：

• 防禦跟資料流不對齊，就等於沒部署。
• 你防的是 content surface，攻擊走的是 state surface，那就是白做。
• 你防的是 rendered layer，攻擊藏在 parsing / ingestion / hidden metadata，那也是白做。

這種 insight 很適合真正要上 production 的團隊，因為它把焦點從「防禦演算法本身」拉回到「防禦是否嵌進正確節點」。

第三個重點：看不見的 payload，不代表比較難成功，反而可能一樣致命

作者還特別點出一個很實務的問題：whitefont PDF payload 的 attack success rate 可以和 visible text 一樣高，甚至更高。

這件事等於直接打臉很多只看 render 結果的 document screening 思路。因為對 agent 來說，真正被吃進去的常常不是你肉眼看到的畫面，而是 OCR、text extraction、document parsing 之後的字串。只要那條 ingestion pipeline 會把隱藏層的文字也吞進去，攻擊就根本不用跟人眼打交道。

這也是為什麼我會說這篇的價值不在於又證明一次 prompt injection 很危險，而在於它把問題從「模型是否夠聰明辨識惡意文字」提升成：你的文件處理堆疊，到底把哪些層當成真實輸入？

這篇論文真正補到哪裡？

1. 它把 prompt injection 評估從 binary success 拉成 stage-by-stage diagnosis

這是最大貢獻。很多防守失敗不是因為你不知道有風險，而是因為你不知道風險到底卡在哪一節。這篇把觀測粒度拉高，讓工程團隊可以真的對症下藥。

2. 它把模型安全重新放回架構安全脈絡

很多 agent 安全討論太愛神化模型差異，但這篇很清楚地告訴你：架構拓撲、write policy、relay path、surface design 這些系統決策，常常比換 model family 更影響真實風險。

3. 它讓 defense-in-depth 終於有可量測的 pipeline 語言

以前大家說 defense-in-depth 常常很口號。這篇至少提供了一個更可操作的說法：你可以沿著 EXPOSED → PERSISTED → RELAYED → EXECUTED 四段去看，哪裡需要過濾、哪裡需要隔離、哪裡需要二次驗證。

我怎麼看它的限制？

1. Canary 很強，但仍然是 proxy

用 cryptographic token 追蹤 propagation 很聰明，但它畢竟還是 proxy signal。真實 prompt injection 有時不是把一段 token 原封不動地搬運，而是轉寫、摘要、重述、語意變形後才進入後續步驟。這種情況下，stage tracking 可能比 binary ASR 更好，但仍未必完全覆蓋。

2. 950 runs 很紮實，但 production diversity 更髒

真實企業流程會有更多 parser、更多 middleware、更多資料格式、更多人為 workaround。也就是說，這篇很適合當架構診斷基準，但不代表你照著它的 surface list 跑完就算安全了。

3. 它更擅長告訴你哪裡失守，不一定直接給你完整修法

這篇的價值比較像 CTI 或 EDR 的 attack path visibility：它很會幫你看見傳播路徑，但真正要把路堵住，還是要靠後續的權限拆分、記憶治理、工具前審批、文件前清洗、以及更嚴格的 state transition policy。

為什麼這篇值得 sectools.tw 讀者看？

因為這篇不只是再說一次「prompt injection 很可怕」，而是把資安讀者最在意的那件事講清楚：很多 agent 真正的安全邊界，不在模型回答那一刻，而在它把不可信內容寫進狀態、傳給別人、再拿去執行的那幾個節點。

如果你平常做的是：

• 文件驅動的 agent workflow
• RAG with memory / notes / planner
• multi-agent orchestration
• 自動讀報表、讀工單、讀 log 再採取動作的 security pipeline

那這篇會很有共鳴。因為它談的不是抽象 alignment，而是很具體的系統設計：你到底把哪些節點做成 write-capable？哪些 channel 被你漏掉？哪些不可見層其實正在偷偷進場？

而且作者點名的場景像金融文件、投資研究、企業文檔處理，也都跟現在最常見的 agent 落地路徑很接近，不是那種離 production 很遠的 toy benchmark。

總結

Stage-Level Tracking of Prompt Injection Across Attack Surfaces and Model Safety Tiers 這篇論文真正厲害的，不是又做出一個更花俏的 prompt injection leaderboard，而是它把 prompt injection 從「模型有沒有中招」改寫成「污染怎麼沿著 pipeline 傳播、永續化、轉送、最後執行」。

如果要用一句話記這篇，我會寫成：

很多 agent 真正缺的，不是再多一個 prompt filter，而是先看清楚髒東西是在哪個 write node 被放進系統，然後又是沿哪條 relay path 一路變成高權限行為。

對想把 agent 放進真實工作流的人來說，這篇的價值不只是提醒你小心 prompt injection，而是逼你重新畫一次自己的系統圖。因為真正危險的，從來不只是模型看見了什麼，而是系統允許它把看見的東西，變成什麼。