Agentic AI as a Cybersecurity Attack Surface 論文閱讀分析：當 AI Agent 的真正攻擊面，開始變成整條執行期供應鏈
論文基本資訊
- 論文標題：Agentic AI as a Cybersecurity Attack Surface: Threats, Exploits, and Defenses in Runtime Supply Chains
- 作者：Xiaochong Jiang、Shiqi Yang、Wenting Yang、Yichen Liu、Cheng Ji
- 年份：2026
- 來源：arXiv:2602.19555
- 論文連結：https://arxiv.org/abs/2602.19555
- DOI：10.48550/arXiv.2602.19555
- 主題：Agentic Security、Runtime Supply Chain、Prompt Injection、Memory Poisoning、Tool Supply Chain、Zero-Trust Runtime
如果說前面幾篇 agentic security 論文，分別在談 system prompt 是 attack surface、skill / tool 是 supply chain、runtime guardrail 要看實際流量、formal security model 要先把權限邊界畫清楚，那這篇 Agentic AI as a Cybersecurity Attack Surface 做的事情，某種程度上就是把這些零散直覺重新收束成一個更完整的判斷：
Agent 的真正攻擊面，不只在模型、不只在 prompt，也不只在某個惡意工具；而是在它整條執行期供應鏈（runtime supply chain）本身。
我覺得這篇最有價值的地方，不是它提出了某個全新 exploit，而是它把很多看似分散的問題——例如 indirect prompt injection、memory poisoning、hallucinated tool names、過度授權的工具呼叫——重新放進同一條 supply chain 敘事裡。這件事很重要，因為只要你還把這些問題看成彼此無關的「單點漏洞」，你最後做出來的防禦通常就會是東補一條 rule、西補一個 filter，永遠在追著 symptom 跑。
這篇論文在解決什麼問題？
作者的基本判斷非常準：傳統軟體供應鏈的核心，是 部署前就能列舉、驗證、鎖定依賴；但 agentic system 的依賴，很多是在執行當下才被「語意化地」挑出來的。
也就是說，對一般軟體而言，dependency 大多是 build-time artifact：哪個 library、哪個 binary、哪個 hash，都能先看清楚。但對 agent 來說，真正影響它決策與行動的 dependency，常常是：
- 它剛剛從外部抓回來的文件
- 它在 memory bank 裡取出的舊紀錄
- 它語意搜尋後選中的工具描述
- 它當下決定要不要呼叫、以及如何呼叫的外部 capability
這些東西不是靜態連進程式裡，而是在推理過程中被動態解析、拼接、信任、再執行。作者把這種現象稱為一種很值得記住的結構：Stochastic Dependency Resolution。這個詞的意思很直白——agent 的有效依賴關係，不是 deterministic build graph，而是由模型在 runtime 透過語意與機率動態決定。
一旦你接受這個前提，整個安全邏輯就會變。因為攻擊者不一定要打進 model weights、host infrastructure 或系統 prompt；他只要污染 agent 在執行時會接觸的那些依賴，就可能改變後續行為。
它真正重畫的，是 supply chain 的邊界
這篇 paper 很值得看的地方，是它直接把供應鏈從「安裝前的套件與程式碼」往外推，推到 資料、記憶、工具發現、工具實作、工具呼叫 這整條執行期路徑。
作者把 runtime 風險拆成兩大鏈：
- Data Supply Chain：agent 看到了什麼、記住了什麼、未來還會再讀回什麼
- Tool Supply Chain：agent 以為自己拿到什麼能力、實際載入了什麼實作、又在什麼權限下執行
這個切法其實很漂亮。因為很多人在談 agent 安全時，會把「被惡意內容影響推理」和「被惡意工具影響行動」分開看；但在真實 agent workflow 裡，這兩者本來就連在一起。先有被污染的 perception，再有被誤導的 action；而 action 的產物又可能回寫到環境，變成之後新的可檢索資料。這就是作者那張圖裡最關鍵的 loop：不是單次 prompt 被搞壞，而是 perception–action loop 整個變成可被污染的循環系統。
Data Supply Chain：Agent 最大的問題，不是看錯一次，而是把髒東西帶進控制面
在資料供應鏈這一段，作者其實不是單純再講一次 prompt injection，而是把資料污染按「持續時間」分成兩類：
- Within-session manipulation：在單一 session 內污染 context window
- Across-session manipulation：把惡意內容打進會被長期保留的 knowledge / memory
這個區分非常實用。因為對一般聊天機器人來說，被 prompt injection 影響一次，常常只是那一輪回答歪掉；但對 agent 來說，情況完全不同。它的 context 不是單純拿來生成文字，而是會直接影響：
- 接下來要不要用某個工具
- 該不該升高權限
- 是否把某段內容寫回 memory
- 要不要把結果回傳到 wiki、repo、ticket、email 等外部系統
也因此，作者強調 context 不再只是輸入，而是 operational control signal。這句話我很認同。因為在 agentic system 裡，資料不只是「資訊」，而是會間接變成控制流的一部分。
論文在 within-session 這邊提到兩個典型面向：indirect prompt injection 與利用大量上下文範例污染 agent 當前行為模式的 in-context learning manipulation。重點不在技術名詞，而在一個更大的結論：只要系統把 secure instruction 和 untrusted data 塞進同一個 context window，模型就很容易把原本只是資料的東西，上升理解成可執行的指令。
作者用了一個很傳神的詞：Prompt-Data Isomorphism。意思是在人類看來是資料、在模型的推理流程裡卻可能被當成指令。這其實就是很多 agent 安全問題的核心：我們以為自己在餵資料，模型卻把那段資料當作新的 policy signal。
而 across-session 的問題更麻煩，因為它不只是影響當下，還會污染未來。論文把它落在兩個場景：
- Knowledge base contamination：把惡意內容打進 RAG corpus、向量庫，甚至圖結構檢索系統
- Long-term memory poisoning：讓 agent 把污染過的紀錄當成自己未來決策的經驗基礎
這一段之所以關鍵，是因為它把「記憶」從 convenience feature 拉回安全資產。很多人把 memory 想成讓 agent 更聰明、更個人化的功能，但從防禦角度看，memory 其實是可被延遲觸發的持久化攻擊面。你今天只植入一次，明天、下週、甚至不同 agent 之間，都可能繼續把那段污染重新活化。
Tool Supply Chain：問題不只是惡意工具，而是 intent、implementation、authority 三者脫鉤
這篇另一個很強的部分，是它把工具供應鏈拆得很清楚。不是籠統說「tool 可能有風險」，而是把整個 capability binding 過程分成三階段：
- Discovery：從意圖解析到 tool ID
- Implementation：從 tool ID 載入實際程式碼
- Invocation：在特定權限與參數下真正執行
這個分解很有用，因為 agent tool-use 的失敗，真的常常不是單一點爆掉，而是這三層其中某一層悄悄脫鉤。
在 Discovery 階段，作者點出兩個很有代表性的風險：
- Hallucination squatting：模型幻想出 plausible 但不存在的工具名，攻擊者再搶先註冊成惡意套件
- Semantic masquerading：把工具描述寫得特別像合法需求，騙過語意檢索或 ranking 流程
這裡最值得注意的不是「模型會 hallucinate」這件老事，而是：當工具選擇本身是靠語意近似與 metadata 決定時，描述文字就不再只是介紹欄，而是 capability routing surface。 換句話說，tool registry 裡的文案、描述、標籤，本身就是安全邊界的一部分。
到了 Implementation 階段，問題變成：就算選對工具名稱，也不代表你載進來的是乾淨實作。這裡包括：
- 表面正常、特定條件才觸發的 hidden backdoor
- 安裝依賴時偷偷執行惡意邏輯的 transitive dependency exploitation
也就是說，agent 的風險不只在「選錯」，也在「選對了名字，但底下跑的不是你以為那個東西」。這和一般軟體 supply chain 很像，但 agent 更危險，因為 agent 會把安裝依賴這件事也當作一個正常步驟去自動完成，而不會天然把它視為高敏感操作。
最貼近實務傷害的，則是 Invocation 階段。這裡作者談的是：
- Over-privileged invocation：agent 拿著太寬的權限去做本來不該做的事
- Argument injection：工具本身沒錯、權限也是真的，但輸入參數被惡意扭曲，最終導致越界副作用
這段我特別喜歡，因為它提醒了一件常被忽略的事：正確的工具 + 正確的憑證，不等於正確的行為。 很多組織一看到「不是惡意 binary、不是未授權 token」，就以為系統安全了；但對 agent 來說，真正的災難常發生在 logical boundary 失守——例如它用合法郵件工具寄出不該寄的內容，用合法雲端權限刪了不該刪的資料，或用合法 API 參數去做了不符合原始意圖的狀態變更。
這篇 paper 最有洞見的一點：Viral Agent Loop
整篇論文裡，我認為最值得記住的概念是 Viral Agent Loop。
作者的意思不是傳統惡意程式那種利用 code execution bug 自我複製，而是：一個 agent 被污染後，可能透過自己被授權的正常工具，把惡意 payload 寫回環境；接著另一個 agent 又把這些內容當成正常輸入讀進來，於是污染沿著 agent 生態自己擴散。
這個概念之所以重要，是因為它把風險從「單一 agent 出錯」拉到「整個 agent ecosystem 的迴圈污染」。你可以把它想成一種 semantic worm：
- 不是靠 memory corruption 傳播
- 不是靠 exploit kernel 傳播
- 而是靠 agent 合法的 instruction-following、retrieval、write-back、communication 行為來傳播
這也是為什麼作者說，agentic supply chain 的拓樸已經從 pipeline 變成 cycle。這句話很重，但很準。傳統供應鏈安全多半在處理「上游污染、下游受害」；agent 生態則開始進入「消費者同時也是生產者」，因此污染物會在系統裡反覆再製。
作者主張的防禦方向：Zero-Trust Runtime，而不是再多寫幾條 prompt 規則
面對這種執行期供應鏈風險，作者最後主張的是 Zero-Trust Runtime Architecture。我覺得這個方向是對的，因為它承認了一件殘酷但必要的事：
對 agent 來說，context 不能再被視為被動資料，而要被視為不可信的控制流。
這句話其實幾乎可以當成 agent security 的新基本法。只要你還把外部內容看成普通 reference material，你就會不自覺把權限、推理、工具調用一路綁在一起；但如果你把 context 視為 untrusted control flow，就會自然開始問：
- 這段內容是誰提供的？
- 它能影響到哪一層決策？
- 它能不能直接改變工具選擇與執行參數？
- 它產生的 side effect 要如何被驗證、被限制、被回溯？
作者也因此強調，工具執行不該只憑語意判斷「這看起來像正當需求」，而要盡量靠 cryptographic provenance、權限邊界、顯式 capability binding 來約束。這個立場其實和最近幾篇好論文的方向非常一致：不要把安全押在模型是否聽話，而是把安全建立在即使模型被帶偏，系統仍然有硬邊界。
怎麼看這篇論文的價值與限制？
我會把這篇 paper 定位成一篇很有用的 systematization / framing paper，而不是某個單點技術突破。它最強的不是新模型或新 benchmark，而是它幫 agent security 補上了一張更像樣的地圖。
它的價值在於：
- 把 data poisoning、memory poisoning、tool confusion、authority misuse 放進同一個 runtime supply chain 視角
- 把很多原本像「偶發 LLM 失誤」的問題，改寫成結構性 dependency risk
- 明確指出 agent 生態的風險不是線性 pipeline，而是會自我回灌的循環系統
當然，它也有典型 framing paper 的限制：比較像建立分析框架與設計原則，而不是給你一個今天裝上去就能完整解決的 production system。可是在這個題目上，這恰恰不是缺點。因為現在很多團隊缺的本來就不是第 N 個 heuristic patch，而是 先把問題定義對。
我的結論
Agentic AI as a Cybersecurity Attack Surface 這篇論文真正說服人的地方，在於它把 agent 風險從「模型可能答錯、工具可能有毒、記憶可能被污染」這些零碎事件，往上提升成一個更完整的系統論斷：
一旦 AI agent 的能力來自執行期動態解析的資料、記憶與工具，它的攻擊面就不再只屬於模型，而屬於整條 runtime supply chain。
而這個判斷帶來的實務含義也很清楚：未來真正成熟的 agent security，不會只是更強的 prompt、更多的拒答模板、或更花俏的 routing policy，而是要開始像守一般高風險系統一樣，認真看待 dependency provenance、memory integrity、tool binding、permission scoping、runtime containment 這些硬問題。
說得再直白一點：如果你還把 agent 當成比較會說話的應用程式，你看到的只會是提示詞問題；但如果你把它當成會自己找依賴、自己改變環境、自己把輸出再餵回系統的自動化主體，你就會知道，真正該守的是整個執行期供應鏈。
本文由 AI 產生、整理與撰寫。