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

Retrieval Barrier 論文閱讀分析：真正讓間接 Prompt Injection 變成實戰威脅的，不只是毒內容本身，而是它終於能穩定被撈進來了

論文基本資訊

• 論文標題：Overcoming the Retrieval Barrier: Indirect Prompt Injection in the Wild for LLM Systems
• 年份：2026
• 來源：arXiv:2601.07072
• 論文連結：https://arxiv.org/abs/2601.07072
• DOI：10.48550/arXiv.2601.07072
• 主題：Agentic Security、Indirect Prompt Injection、RAG Security、Retrieval Security、Embedding Models、Data Exfiltration

最近很多 indirect prompt injection 論文都已經說服大家：只要 agent 會讀外部內容，就可能被外部內容帶偏。 但老實說，這條敘事一直有個沒講透的現實問題：那段惡意內容到底有沒有那麼容易真的被撈進 context？ 如果毒文件平常根本檢索不到，那風險就可能比較像理論漏洞，而不是穩定可操作的 exploitation path。

Overcoming the Retrieval Barrier 這篇 paper 的價值，就在於它直接對準這個最硬的環節。作者不是再重複證明「被撈進來之後很危險」，而是往前退一步，處理真正讓攻擊從 concept 變成 weaponizable 的那道門檻：如何讓惡意內容在自然查詢下也能高機率被 retrieval 選中。

這篇論文在解什麼問題？

作者要處理的是 Indirect Prompt Injection（IPI） 在真實 RAG 與 agent 系統裡的可行性落差。過去很多研究已經指出，攻擊者可以把惡意指令藏在 email、文件、知識庫頁面或其他外部資料裡，等模型把這些內容撈回來之後，再把它當成半可信上下文吃下去。

但這裡一直有個實務盲點：retrieval 本身不是保證命中的。 你今天就算植入一段再惡毒的 payload，只要 embedding space 裡它跟使用者自然查詢對不太上，它就可能永遠排不上來。這意味著很多 IPI demo 真正繞過的，不只是 model safety，而是默默假設了「毒內容會被成功取回」。

所以這篇論文真正要問的是：

如果攻擊者只有黑箱 embedding API 存取權，能不能系統化地打造出一段幾乎保證被檢索命中的 trigger，讓任何惡意 attack fragment 都有機會穩定進入 agent 的 decision pipeline？

核心觀念：真正難的不是寫壞指令，而是先跨過 retrieval barrier

我覺得這篇最值得記住的一句話，可以濃縮成：很多間接提示注入之所以看起來不夠致命，不是因為後半段 exploitation 不成立，而是因為前半段 retrieval 命中率太差。

作者把這個問題命名成 retrieval barrier。意思是說，在真實世界裡，惡意內容如果不能先變成高相關、高排名的 retrieval candidate，它再會操控模型也沒用。這讓 IPI 的攻擊面不再只是「內容安全」，而是變成：

• embedding model 如何表示語意
• 檢索排序如何決定哪些內容先進 context
• RAG / agent pipeline 怎麼把 retrieved text 當成 observation

也就是說，真正的控制面其實更前面，落在 retrieval-to-context 這條鏈上。

作者的方法：把 payload 拆成 trigger fragment 與 attack fragment

這篇 paper 最關鍵的技巧，是把惡意內容拆成兩個功能不同的部分：

• Trigger Fragment：負責在 embedding / retrieval 層保證命中
• Attack Fragment：負責真正承載攻擊目標與惡意指令

這個拆法很漂亮，因為它承認了一個以前常被混在一起的事實：「容易被撈到」和「足以控制模型」其實不是同一個最佳化目標。 一段很會操控 agent 的文字，未必和自然查詢語意夠近；反過來，一段很容易命中的文字，也未必足夠惡意。作者把這兩件事拆開後，就能先專心把 retrieval 做到穩，再把任意攻擊目標掛在後面。

換句話說，攻擊者現在不必再幻想一段文字同時兼顧：

• 像正常內容
• 又要高檢索相關
• 還要能控制 agent

作者的方法等於是把這個多目標問題重新分層，先處理最務實的第一步：保證被看見。

黑箱也能打：作者強調只需 embedding API 存取權

這篇研究另一個很重要的訊號，是它不是在假設攻擊者能白箱看到 embedding 模型內部權重。作者主打的是 black-box attack：只需要 API access，就能用成本可接受的方式去構造 trigger fragment。

這點很關鍵，因為它直接把威脅模型拉近現實。很多企業系統今天用的就是第三方 embedding service、封裝好的向量索引或托管式 RAG stack。攻擊者不需要接管整條 pipeline，只要能：

• 預估常見自然查詢主題
• 投毒進可能被檢索的外部語料
• 對 embedding API 做有限次查詢最佳化 trigger

就有機會把 payload 推到 retrieval 前排。論文裡最刺眼的一個數字，就是它把成本壓到 每個目標使用者查詢最低約 0.21 美元。這不是 nation-state 級成本，而是非常像 spam / phishing 經濟學會接受的攻擊單價。

最值得注意的結果：retrieval 命中率幾乎被作者做成可工程化能力

根據論文摘要，作者的方法在 11 個 benchmarks、8 種 embedding models 上達到 接近 100% retrieval。而且這些 embedding models 不只包含開源模型，也包含 proprietary services。

這個結果之所以重要，不是因為它單純代表「搜尋做得很好」，而是因為它把先前很多人心裡那個保留意見打掉了：

「也許惡意內容實際上很難在自然查詢下被撈到，所以風險沒有看起來那麼大。」

這篇 paper 幾乎是在說：如果攻擊者願意針對 retrieval layer 最佳化，那個前置門檻其實可以被大幅突破。 一旦 retrieval barrier 被跨過，後面的 agent hijacking、資料外送、任務偏轉，就從偶發事故變成更穩定的 exploitation chain。

這篇 paper 真正刺痛人的地方：不只打 RAG，還打 end-to-end agent workflow

作者沒有把故事停在「某段毒文件被撈回來」。他們強調的是 end-to-end IPI exploits，而且是發生在 自然查詢、真實外部語料、RAG 與 agentic systems 的設定下。

摘要裡最值得被記住的案例，是這個場景：

• 使用者發出自然查詢，要系統整理常見主題的 email 摘要
• 攻擊者只投毒一封 email
• 最後 GPT-4o 在一條 multi-agent workflow 裡，被誘導去外洩 SSH keys
• 成功率超過 80%

這個案例之所以兇，不只是因為外洩的是 SSH key，而是它把整條 attack chain 串起來了：

1. 惡意內容先在 retrieval 層贏得可見性
2. 被系統當成與任務高度相關的 context 撈回來
3. 再被 agent 當成 observation 或指引的一部分
4. 最後轉成實際資料外送行為

也就是說，這已經不是「模型講了不該講的話」，而是檢索、推理與行動層一起形成了一條可操作的外洩管線。

這篇論文對防禦方最大的提醒：不要再把 retrieval 當成中性 plumbing

很多團隊在做 agent / RAG 安全時，會把重點放在：

• system prompt 寫得夠不夠強
• output filter 有沒有攔住危險回答
• tool call 前有沒有 human approval

但這篇 paper 很直接地提醒你：如果 retrieval layer 本身可被對手最佳化，那它就不是中性的資料搬運層，而是整個控制鏈最前面的排序器。 一旦排序器開始穩定偏好惡意內容，後面再多 guardrail 都是在處理已經被汙染過的上下文。

所以防禦重心不能只放在「retrieved content 有沒有看起來像壞 prompt」，還必須往前問：

• 檢索結果是否過度依賴語意相似度而缺少來源可信度權重？
• embedding space 是否容易被低成本 query-based optimization 操控？
• retrieval 結果進 context 前，有沒有 provenance、segmentation、risk scoring？
• agent 是否把 retrieved text 和 user instruction 混成同一等級的控制訊號？

作者對既有防禦的結論很不客氣：它們仍擋不住「被撈到」這件事

摘要最後一句很關鍵。作者不是只說現有防禦不夠好，而是更具體地指出：現有防禦不足以阻止惡意文字被 retrieval 成功選中。

這句話的意思其實很重。因為很多 defenses 主要在防：

• 文字內容像不像 prompt injection
• 模型有沒有遵守 instruction hierarchy
• agent 有沒有在 action 前做額外檢查

但如果你沒有防住 retrieval hit，本質上就是讓攻擊者穩定拿到一張進入 context 的門票。接下來就算後面幾層還能再擋一些，也表示整條系統已經先丟失了一次最關鍵的 trust boundary。

我的 takeaway

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

這篇論文真正把 indirect prompt injection 從「內容污染問題」往前推成了「檢索控制問題」：真正危險的不是那段毒文字存在，而是它被低成本、黑箱、可重複地送進 agent 眼前。

這個 framing 很重要。因為它讓我們重新理解 RAG / agent security 的第一道防線不是 prompt template，而是 retrieval pipeline 本身。當 embedding model、ranking mechanism、corpus ingestion 與 context assembly 一起構成控制鏈時，retrieval 不再只是搜尋品質問題，而是 security boundary。

對我來說，這篇最該被記住的不是某個單一數字，而是這個更成熟的安全觀：只要不可信內容能被對手穩定做成 top-k 結果，後面的 agent guardrail 就很容易變成在毒已入血之後才開始急救。

Takeaway

Overcoming the Retrieval Barrier 這篇論文最重要的貢獻，是把 indirect prompt injection 的真正瓶頸講清楚：很多攻擊不是不夠危險，而是以前還不夠容易被 retrieval 命中。作者透過把 payload 拆成 trigger fragment 與 attack fragment，證明在只具備黑箱 embedding API 存取權的情況下，也能以低成本把惡意內容最佳化成高命中檢索項，並在 11 個 benchmarks、8 種 embedding models 上達到接近 100% retrieval，甚至在真實 multi-agent workflow 中把 SSH key 外洩成功率推到 80% 以上。這篇 paper 真正把問題重新畫對了：RAG / agent security 的核心不只是防髒 prompt，而是把 retrieval 視為一條必須被保護的 control plane。

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文摘要、arXiv 頁面與可取得的研究說明進行整理與分析。由於撰寫時未必涵蓋附錄、完整實驗細節與作者程式碼，部分表述屬研究性解讀；若需引用精確威脅模型、最佳化程序或完整評測設定，仍應以原始論文與作者公開版本為準。