PCFI 論文閱讀分析：真正該防的，往往不是哪段外部文字看起來像攻擊，而是它有沒有開始越權改寫 prompt 控制流

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

論文基本資訊

• 論文標題：Prompt Control-Flow Integrity: A Priority-Aware Runtime Defense Against Prompt Injection in LLM Systems
• 年份：2026
• 來源：arXiv:2603.18433
• 論文連結：https://arxiv.org/abs/2603.18433
• DOI：10.48550/arXiv.2603.18433
• 主題：Prompt Injection、Runtime Security、RAG Security、Middleware Defense、Policy Enforcement、Control-Flow Integrity

這篇論文我覺得最值得看的，不是它又做了一個 prompt injection detector，而是它把整個問題重新命名成一個更像系統安全的人話：prompt 不只是字串，它其實是一條有權限優先序的控制流。

一旦你接受這個 framing，很多今天 LLM defense 看起來一直很脆的原因就突然變清楚了。因為多數防線還在把 system prompt、developer instruction、user request、retrieved document、甚至外部 RAG 內容，通通當成一坨扁平文字送進模型；但實際上，這些東西在語義上根本不是同一層，也不該有同樣的支配力。

Prompt Control-Flow Integrity（PCFI）想補的，就是這個優先序與來源邊界在 runtime 被抹平之後留下的安全洞。

它在解哪個問題？

作者處理的場景很典型：企業把 LLM 放在 API 後面，前面可能有 middleware，旁邊掛了 RAG，把內部文件、外部網頁、知識庫內容一起塞進 prompt。這時真正危險的，不只是某段 retrieved text 裡面出現「忽略前面所有指示」這種明牌，而是系統沒有明確保留誰是 policy、誰是 request、誰只是被引用資料。

於是原本應該只被當成 evidence 的內容，會在模型上下文裡偷偷升格成 instruction；原本應該最高優先的 system / developer policy，也可能在長上下文裡被語意稀釋。這就是 prompt injection 能反覆得手的根本原因之一：控制面和資料面混線了。

PCFI 的核心主張很簡單：

• 把 prompt 視為有結構的組成物，而不是純字串
• 明確區分 system、developer、user、retrieved document 等 segment
• 在 forwarding 給後端 LLM 前，先由 middleware 檢查低優先序內容是否企圖改寫高優先序控制流

這個想法其實很像把傳統系統安全裡的 control-flow integrity 借來用在 prompt world：不是只問某段內容看起來像不像壞話，而是問它有沒有開始跨權限亂跳。

PCFI 具體怎麼做？

根據論文摘要，PCFI 是一個放在部署式 LLM API 前面的 FastAPI gateway，核心是一條三階段 middleware pipeline。作者提到的關鍵構件包括：

• lexical heuristics：先抓顯性的注入特徵與 override 語句
• role-switch detection：檢查低優先序內容是否試圖冒充 system / developer authority
• hierarchical policy enforcement：依來源與優先序做分層處理，而不是平面比對

這裡我覺得真正重要的不是哪一條 regex 或哪個 heuristic，而是defense placement 終於放對位置。PCFI 沒有把希望壓在模型自己讀完上下文後「懂得分辨誰比較有權威」，而是先在模型外面，把 prompt 的結構跟優先序硬保留下來。

這種設計代表一個很實際的態度轉向：不要再把 prompt injection 當成純 semantic classification 問題，而要把它當成控制面完整性問題。

這篇的 framing 為什麼比一般 detector 更有價值？

今天很多 defense paper 會卡在同一個地方：它們問的是「這段內容有沒有惡意」，但 production team 真正需要問的往往是另一件事：

這段內容憑什麼能影響 agent 下一步？

這兩者差很多。

因為很多真正麻煩的 prompt injection，並不一定長得特別像攻擊。它甚至可能只是某份文件裡一段看似正常的操作說明、某個 log 裡一條建議修復步驟、某個網頁裡一段內嵌 instruction。你如果只看語意毒性，不一定抓得到；但如果你看的是資料段落正在不正在越權改寫控制流，問題就比較清楚了。

所以 PCFI 最有價值的地方，不是它保證世界上所有 injection 都能擋住，而是它把防禦目標從「辨認壞內容」換成了「守住 prompt hierarchy」。這件事比較接近真正可營運的系統設計。

實驗結果該怎麼看？

作者聲稱，在自建 synthetic 與 semi-realistic prompt-injection benchmark 上，PCFI：

• 攔下所有 attack-labeled requests
• false positive rate 為 0%
• 中位處理額外開銷只有 0.04 ms

老實說，這種結果漂亮到我不會直接把它當 production truth，而是把它當一個很強的訊號：至少在作者設計的威脅模型裡，priority-aware middleware 可能真的是一條高 ROI 的防線。

但也要講清楚，這不代表 prompt injection 問題就此解決。因為只要 benchmark 還是作者自建的 synthetic / semi-realistic workload，就仍然有幾個要保留的問號：

• 面對更隱晦、非明牌式的 injection，0% FP / 全攔截是否還能維持？
• 如果攻擊不直接宣稱自己是 system，而是慢慢用長文脈絡重排模型注意力，role-switch detection 能抓多少？
• 一旦 prompt 結構不是 API gateway 完全可見，而是多跳 agent / tool / memory pipeline，PCFI 的觀測面還夠不夠？

所以我會把這組數字理解成：這個 placement 值得學，不是這個 benchmark 值得神化。

把它放回今天的 agentic security 主線裡，補的是哪一塊？

如果把今天 sectools.tw 已經一路發過的幾篇放在一起看，像是：

• 把治理要求翻成 runtime controls 的 paper
• 把 drift 與 invariants 拉進 delegated agent runtime 的 paper
• 把 prompt injection 偵測從 pattern matching 往 evidence aggregation 推的 paper
• 把 MCP / tool use 當成 privileged action 去治理的 paper

那 PCFI 補上的，是更前面那一層：在內容還沒真的進模型、還沒長成 tool call、也還沒進到 trajectory drift 之前，prompt 結構本身到底有沒有被正確保護？

它不是在談整條 agent loop 的完整治理，而是在處理最前線那個很容易被低估、但其實天天都在出事的入口：data-to-control conversion。

很多團隊以為自己已經有 system prompt、有 retrieval boundary、有一些 jailbreak detector，就算有基本防禦；但如果 retrieved document 進來時，系統仍然把它和高優先 instructions 混成同一種上下文物件，那本質上還是在用錯模型的 trust primitive。

PCFI 至少把這個問題講得很清楚：不是每段文字都該有一樣的控制權。

它和一般 RAG sanitization 差在哪？

很多人可能會說，這不就是 input sanitization 的另一種說法嗎？有點像，但不完全一樣。

一般 sanitization 常在問：

• 內容裡有沒有危險片段？
• 要不要刪字、遮罩、過濾？

PCFI 問的是：

• 這段內容的來源角色是什麼？
• 它在 prompt hierarchy 裡應該有多高權限？
• 它現在是否企圖越權控制更高層 instruction？

所以這篇其實更接近runtime mediation，而不是純清洗。這也是我覺得它值得寫的原因：它的角度比「再做一個更聰明的輸入過濾器」更成熟一點。

限制也很現實

當然，PCFI 也有明顯限制。

第一，它很適合部署在單次 request 可觀測、prompt segment 還清楚可分的 API gateway 場景；但如果你的 agent 是多步驟、自我反思、會把 tool output、memory、plan state、delegation transcript 一路重新拼裝，那 prompt hierarchy 會變得沒那麼乾淨。

第二，它的防禦直覺依賴於系統本身願意承認：不同來源內容就是應該不平等。這在理論上很合理，但在很多今天的 agent framework 裡，其實根本還沒被做成一級公民。

第三，lexical heuristic 與 role-switch detection 很可能仍對 attack style 敏感。也就是說，這類方法要進 production，最後還是得面對 distribution shift 與 attacker adaptation。

我的看法

我喜歡這篇的原因很直接：它終於不再把 prompt injection 單純講成「模型被壞字串騙了」這種很像社交工程故事的版本，而是把它拉回系統設計語言。

在我看來，這篇最該記住的一句不是 benchmark 成績，而是這個 framing：

真正該防的，往往不是哪段外部文字看起來多像攻擊，而是低優先序內容有沒有開始越權改寫高優先序控制流。

如果你在做的是 RAG API、enterprise LLM gateway、prompt firewall、agent middleware，這篇很值得看。因為它提醒了一件很多團隊還沒徹底接受的事：prompt security 的問題，本質上不是文字分類，而是控制面完整性。

而只要控制面和資料面還混在一起，很多今天看起來像模型「不夠安全」的問題，其實都只是系統先把邊界做錯了。