Conjunctive Prompt Attacks 論文閱讀分析:真正難防的不是哪段內容特別毒,而是兩段各自都像正常話的東西在對的路由上剛好拼起來

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

論文基本資訊

  • 論文標題:Conjunctive Prompt Attacks in Multi-Agent LLM Systems
  • 作者:Nokimul Hasan Arif、Qian Lou、Mengxin Zheng
  • 年份:2026
  • 來源:arXiv:2604.16543
  • 論文連結:https://arxiv.org/abs/2604.16543
  • DOI:10.48550/arXiv.2604.16543
  • 主題:Multi-Agent Security、Prompt Injection、Routing Security、Agent Supply Chain、Runtime Composition、Agentic AI

最近大家談 agent 安全時,常把焦點放在「某段內容有沒有毒」、「某個工具描述是不是惡意」、「某個 prompt guard 有沒有擋住」。但這篇 Conjunctive Prompt Attacks in Multi-Agent LLM Systems 真正提醒的是:多代理系統裡最麻煩的風險,可能根本不是哪一段單獨看起來有多可疑,而是兩段各自都不太像攻擊的東西,會不會在 routing 後剛好拼成真正的控制訊號。

我覺得這篇最值得看的點,不只是它又證明了一次 prompt injection 可以成功,而是它把攻擊面從單點 prompt拉成跨代理組合條件:一個 user query 裡藏著看似無害的 trigger key,另一邊則是某個被供應鏈污染的 remote agent template;這兩個東西單獨看都不夠構成告警,但只要路由剛好把它們送到同一個 compromised agent,那個 benign-looking system 就可能突然長出 harmful behavior。

這篇論文想解決什麼?

作者瞄準的是越來越常見的 multi-agent pipeline。這類系統通常長這樣:

  • 一個 client / orchestrator agent 先把使用者需求拆成多個 segments
  • 再把不同 segments 分派給不同 specialized remote agents
  • remote agents 可能各自握有 tool、database 或特定 domain capability
  • 最後 client agent 再把結果拼回來,形成整體回應或後續行動

問題在於,一旦系統安全性取決於 segmentation、routing 與 agent-to-agent communication,你就不能再只拿單輪 prompt injection 的思路來看風險。 作者要回答的核心問題很直接:

如果攻擊不是靠一段明顯惡意字串,而是靠「使用者端 trigger」和「遠端代理模板污染」這兩半在 runtime 才拼起來,現有 guardrail 還抓不抓得到?

核心概念:真正危險的不是單點 payload,而是 cross-agent composition

這篇 paper 的關鍵詞是 conjunctive prompt attack。它的意思不是一般那種把一段惡意指令直接塞進 prompt,而是把攻擊拆成兩個半成品:

  • Trigger key:藏在 user query 某一段裡,看起來本身不太像惡意內容
  • Injected template:藏在某個被污染 remote agent 的內部模板裡,單獨看也不一定顯得可疑

真正的 activation 條件是:key-bearing segment 必須被 routing 到那個 compromised agent,而且剛好和 injected template 在同一個上下文裡相遇。

這個 framing 很重要,因為它說明了為什麼很多防線會失效:

  • 看 user input 時,trigger key 不夠惡意
  • 看 agent template 時,那段包裝也不一定像明顯後門
  • 看單次 message 時,各部件都像 benign
  • 真正的危險出現在 routing + composition 完成之後

也就是說,風險不是藏在某個字串,而是藏在系統如何把看似正常的片段重新組裝。

作者的 threat model 為什麼很值得警惕?

我覺得這篇最有現實感的地方,是它沒有假設攻擊者能改 model weights,也沒有假設 client orchestrator 整個被接管。作者採用的是更像供應鏈 / black-box 生態的威脅模型:

  • 攻擊者只控制 user input 的 trigger placement
  • 同時只污染一個 remote agent 的 hidden template
  • 不改 client agent
  • 不改模型權重
  • 甚至不能完全決定 routing,只能透過 routing-aware optimization 去增加 key segment 打到目標代理的機率

這比那種「整個系統 prompt 都被攻陷」的假設更麻煩,因為它更像真實多代理供應鏈:client 端不一定知道 remote agent 的 wrapper、prompt、template 到底長什麼樣;而只要其中一個外部 agent 被污染,整條 pipeline 就可能多出一個隱藏 activation surface。

方法亮點:不是暴力嘗試,而是做 topology-aware、routing-aware optimization

作者不是只做一個概念示範,而是把攻擊拆成可以優化的三個離散變數:

  • j:trigger key 放在哪個 query segment
  • τ:template 放在 compromised agent prompt 的哪個位置(prefix / wrap / suffix)
  • ρ:routing bias,要怎麼增加 key-bearing segment 被送往目標 agent 的機率

因為這些決策本身是離散的,而且部署環境是 black-box,作者用一個 differentiable counterpart objective 去近似 attack success,核心就是把成功率拆成兩件事:

  • Proute:key-bearing segment 抵達 compromised agent 的機率
  • Ptemplate:一旦送達後,template 真的把行為帶偏的機率

兩者相乘形成 surrogate success objective,再加上 false activation penalty 與 entropy regularization 去避免系統退化成「永遠亂觸發」。

這很關鍵,因為這篇不是在證明某個特定 payload 有用,而是在證明:只要你的 agentic system 有 topology、有 routing、有 hidden wrappers,就存在一類可以專門優化 cross-agent alignment 的攻擊。

實驗設計很乾淨:四種 regime 把「單獨 benign、組合危險」這件事釘死

作者用四種 regime 來檢驗這是不是一個真正的 conjunctive attack:

  • clean:沒有 key,也沒有 template
  • key_only:只有 trigger key
  • template_only:只有 injected template
  • both:key 和 template 都存在

如果這個 threat model成立,理想攻擊就該呈現一個很明顯的結果:只有在 both regime 才高成功,其他 regime 都應該維持接近零。

作者也不是只在單一拓樸測,而是拉到三種 communication topologies:

  • Star
  • Chain
  • DAG

這點非常重要。因為多代理安全真正的差異,很多時候不是模型本身,而是哪種拓樸讓風險更容易傳到對的地方。

核心結果:優化後,both regime 的 ASR 可以衝到 0.8、0.9,甚至 1.0

論文最有殺傷力的地方在於:這不是一個「理論上可能發生」的小風險,而是實驗上很容易被拉高。

在 baseline(還沒做 routing-aware / placement-aware optimization)時,three-topology / three-backbone 的 both-regime ASR 多半只有 0.1 到 0.4 左右,已經說明系統天然存在可被利用的 activation surface。但一旦做 full optimization,攻擊成功率在很多組合裡直接拉到 0.6、0.8、0.9,部分情境甚至到 1.0。

  • Gemma-2B:DAG topology 在 full optimization 下 both ASR 可到 1.0
  • Mistral-7B:Star topology 可到 0.9,Chain topology 可到 1.0
  • 作者也提到這類結果可 transfer 到更大的 instruction-tuned backbone 與 closed-source model

更麻煩的是,作者刻意檢查了 false activation。整體上,clean / key_only / template_only 這些 regime 仍大多維持在低水平,表示攻擊不是靠粗暴地把所有情況都弄成 always-on,而是真的把 activation 鎖在「需要兩段 benign-looking component 拼起來」的條件上。

這就讓很多傳統 detector 很尷尬,因為它們最擅長抓的正是單一位置上明顯惡意的東西。

為什麼現有防線擋不住?因為沒有任何一個局部看起來真的夠壞

作者特別測了幾類常見防線,包括:

  • PromptGuard
  • Llama-Guard 類 guard models
  • system-level controls,像 tool restrictions

結果並不樂觀。原因其實很直白:

  • guard model 通常檢查的是單一 prompt 或單一輸入
  • system-level policy 常假設惡意性會在某個局部階段被看出來
  • 但 conjunctive attack 的惡意性是組合後才出現

換句話說,現有防線很多是在看「字串像不像攻擊」,而這篇 attack 真正利用的是「系統會不會把兩段看似正常的東西組成攻擊」。

這跟近來很多 agentic security 論文其實是同一條主線:當安全風險往 runtime composition 轉移時,單點 classifier 再準,也不代表整個 workflow 安全。

這篇論文真正補的是 routing security,不只是 prompt security

如果把這篇 paper 放回最近的 agentic AI 安全脈絡,我覺得它真正補的是一個常被低估的層:routing security

以前我們比較常講:

  • prompt injection
  • tool poisoning
  • memory poisoning
  • malicious MCP server

但這篇提醒的是,就算每個局部 component 自己都沒明顯爆炸,系統把任務切段、分派、轉送、重組的那條 communication fabric,本身就已經是攻擊面。

也就是說,多代理系統真正的危險往往不在「某個 agent 很壞」,而在:

  • 哪個 segment 被送到哪裡
  • 哪個 remote agent 帶著什麼 hidden wrapper
  • 哪些 benign-looking pieces 會在 runtime 被湊到同一個 privileged context

從這個角度看,這篇其實是在把 agent security 從 content inspection 拉回 control-plane inspection。

對實務系統的啟示:不能只掃內容,得掃路徑

我覺得這篇對產品團隊最有價值的提醒,是你不能再只問:

  • 「這段輸入有沒有違規?」
  • 「這個 tool description 有沒有毒?」
  • 「這個 agent output 有沒有 suspicious phrase?」

而是要開始問更系統級的問題:

  • 哪些 segments 會被送到哪些 agent?
  • 哪些 agent 的 template / wrapper 是外部供應、不可見、不可驗?
  • 同一條 user request 中,哪些 benign-looking token 組合會在特定 routing 下形成高風險 activation?
  • 安全檢查做在 message level,還是做在 end-to-end path level?

如果做不到這些,你的 guardrail 很可能只是守住 local prompt,而沒守住真正的 cross-agent attack path。

論文的限制也得看清楚

當然,這篇也不是沒有侷限:

  • 實驗環境仍是 controlled A2A setup:和真實 enterprise multi-agent orchestration 還有距離。
  • activation 採 deterministic marker token 驗證:有利於可重現,但也代表「成功」定義偏向實驗可觀測性。
  • routing model 是作者可參數化的 dispatcher:真實產品 routing policy 可能更複雜,也可能更 noisy。
  • 只污染一個 remote agent 的模板:已經夠危險,但現實中還可能伴隨 memory、tool metadata、shared logs 等更多複合面。

不過這些限制不太影響它的核心價值。因為這篇真正證明的不是某個 payload 在某個 toy app 上可行,而是:多代理系統一旦引入 segmentation、routing、黑箱 remote agents 與 hidden templates,就天然會長出單代理評測看不見的組合型攻擊面。

我的看法

我會把這篇 Conjunctive Prompt Attacks 視為一篇很值得跟近期 MCP / agent runtime / delegation-chain / supply-chain security 論文一起讀的 paper。它最有價值的地方,不是又多了一種 prompt injection 變體,而是把一件更尷尬的事講清楚了:

在 multi-agent system 裡,真正危險的常常不是某個 component 單獨看起來多惡意,而是整個系統太擅長把幾段看似正常的東西,在錯的地方拼成一條可執行的控制鏈。

如果前一波 agent security 論文在告訴你「不要只信 prompt」,這篇往前再推一步:你也不能只信 routing,更不能只信那些你其實看不到內部模板的 remote agents。

所以我覺得這篇最該被記住的,不只是它展示了 high ASR,而是它把問題重新定義成一句更接近 production reality 的話:多代理安全失效,往往不是某一個點突然壞掉,而是系統把幾個各自都不夠可疑的片段,安靜地組成了真正的攻擊條件。

You may also like