SoK 論文閱讀分析：當 Agentic AI 真正開始碰工具、知識與自治，攻擊面就不再只是 Prompt

論文基本資訊

• 論文標題：SoK: The Attack Surface of Agentic AI — Tools, and Autonomy
• 來源：arXiv:2603.22928
• 年份：2026
• 論文連結：https://arxiv.org/abs/2603.22928
• 主題：Agentic AI、Agent Security、Tool Use、RAG Security、Multi-Agent、Runtime Security

這篇 SoK: The Attack Surface of Agentic AI — Tools, and Autonomy 值得看的地方，不是它再一次提醒大家「LLM 可能被 prompt injection」，而是它把問題往前推了一層：當 AI 從單次生成模型變成會調工具、會接知識庫、會自己迭代、甚至會把工作委派給別的 agent 的系統後，安全風險也不再只是輸出講錯話，而是整條執行鏈都開始變成攻擊面。

這也是為什麼這篇 paper 雖然是 systematization of knowledge（SoK），但並不只是幫文獻做摘要。它真正想完成的，是把近兩三年 agentic AI security 裡那些看似零散的 prompt injection、RAG poisoning、tool exploit、cross-agent manipulation、privilege escalation 問題，重新收束成一張比較像系統安全工程的地圖。

這篇論文想回答什麼問題？

作者想處理的核心問題很直接：一旦 AI 系統開始具備工具使用、外部知識存取與自治能力，攻擊面到底擴大到哪裡？我們又該用什麼方式去描述、量測與治理它？

這個問題之所以重要，是因為很多團隊仍習慣用「chatbot 安全」的視角看 agent。可是真正的 agentic system 已經不是單純的提示詞輸入與文字輸出，而是包含：

• LLM 本體
• 檢索系統與外部知識來源
• plug-in / tool / API 呼叫
• memory 與 context persistence
• workflow orchestration
• multi-agent delegation 與 coordination

只要系統長成這樣，風險自然也會從「模型答非所問」升級成「模型開始替攻擊者執行事」。

這篇 SoK 的核心價值：把 agent security 從模型問題拉回系統問題

這篇論文最有價值的地方，是它很清楚地拒絕把 agent security 簡化成 model alignment 問題。作者指出，agentic AI 的核心風險來自多個 trust boundary 疊在一起：

• 使用者輸入和模型之間的邊界
• 模型與外部知識庫之間的邊界
• 模型與工具 / API 之間的邊界
• 單一 agent 與其他 agent 之間的邊界
• 計畫、推理與執行之間的邊界

也就是說，agentic AI 最大的安全轉折點，不是模型變更聰明，而是模型開始被放進一個能讀、能記、能叫外部資源、能真的造成環境變化的系統裡。 只要到了這一步，安全討論就必須從「怎麼讓模型更守規矩」改成「怎麼讓系統即使遇到不可信內容，也不會做出高風險行為」。

作者整理出的主要攻擊面有哪些？

根據論文摘要與整體架構，作者把 agentic AI 的主要風險收斂成幾大類：

• Prompt-level injection：包含直接與間接 prompt injection，讓模型在推理或執行時偏離原本任務
• Knowledge-base / RAG poisoning：污染檢索索引、文件內容或 metadata，使 agent 在 grounded workflow 裡被餵錯誤依據
• Tool / plug-in exploits：把惡意行為藏進工具實作、API schema、回傳內容或 code execution path
• Cross-agent manipulation：利用 agent 之間的委派、訊息傳遞或共享狀態，放大單點注入造成的影響
• Autonomy-amplified abuse：當系統具備自動規劃與持續執行能力時，小小的誤導可能沿 workflow 被逐步放大成真正的 unsafe action

這些分類的關鍵不在於「名字新不新」，而在於它們一起指出一個事實：agent 風險的本質不是 prompt 被污染，而是污染能不能順利穿越 retrieval、planning、tool use、memory 與 execution 這整條鏈。

為什麼 tools、RAG、autonomy 會讓風險質變？

這篇論文的標題故意把 Tools 與 Autonomy 寫進去，其實就是在提醒大家：agentic AI 和一般 LLM 應用最大的差別，不在於它能回答更多問題，而在於它開始碰真實世界。

例如：

• 如果只是聊天，prompt injection 可能只是讓回答變差
• 如果接上 RAG，prompt injection 可能變成 evidence hijacking
• 如果接上工具，prompt injection 可能變成 API misuse 或權限濫用
• 如果再加上 autonomy，錯誤就不只是一個回合，而可能被 agent 自己反覆執行、記憶、擴散

換句話說，agentic AI 的問題不是多了一個 attack vector，而是本來彼此分離的 attack vector 開始可以串起來。

這篇論文最值得注意的 framing：trust boundary 不是抽象概念，而是工程分界線

很多 agent security 論文都會提到 trust boundary，但這篇 SoK 的好處，是它把 trust boundary 放在比較工程化的位置來看。這很重要，因為一旦你真的把系統拆成邊界，就會發現許多常見錯誤根本不是模型「變壞」，而是系統設計預設了不該存在的信任。

例如：

• 把外部文件內容直接當成可執行任務指令
• 把 tool output 當成可信 reasoning evidence
• 讓 planner 產生的高層目標直接映射成高權限 action
• 讓子 agent 沿用主 agent 的權限與上下文，卻沒有 capability scoping
• 把 memory 視為「自己的內部狀態」，忽略它其實可能早就被攻擊者污染

這幾件事單看都很合理，但合在一起，就形成了 agentic system 最危險的地方：攻擊者不一定要控制模型，只要能控制系統裡某段被錯誤信任的資料流，就可能間接控制行為。

作者提出的評估指標，為什麼比一般 benchmark 更貼近實戰？

這篇論文除了做 taxonomy，也提出幾個值得注意的 security posture 指標，例如：

• Unsafe Action Rate
• Privilege Escalation Distance

這種指標有意思的地方，在於它們不只問模型「答對沒有」，而是開始問：

• 系統做了多少不該做的事？
• 從不可信輸入到高權限動作，中間需要跨過幾道保護？
• 攻擊者要花多少步驟，才能把低可信內容變成真實環境中的 side effect？

這其實就是把 agent evaluation 從語意正確率，往真正的 security consequence 拉近。對資安從業者來說，這比單純看 benchmark 分數實用得多，因為真正的問題不是 agent 有沒有「理解任務」，而是它會不會在理解不完整時仍然動手。

防禦建議：不是多上一層 guardrail 就好

論文回顧的防禦方向大致包括：

• input sanitization
• retrieval filter 與內容驗證
• tool sandbox 與 capability isolation
• access control
• runtime monitoring
• AI guardrails

但作者並沒有把這些方法講得太樂觀。這篇 paper 最務實的地方，反而是它承認：單點防禦通常只對單點風險有用，而 agentic AI 的問題剛好就是跨層組合風險。

例如，input sanitization 可以減少明顯 injection，但擋不住已經被污染的 knowledge base；sandbox 可以限制工具副作用，但不處理 evidence corruption；access control 可以防止權限濫用，卻不保證多 agent 協作時不會出現 authority laundering。這也是為什麼論文最後給的是 phased security checklist，而不是某個萬靈丹式解法。

這篇 paper 真正想說的，其實是 secure-by-construction

如果把整篇濃縮成一句話，我會說這篇論文的核心主張是：agentic AI 的安全，不能只靠模型在最後一刻拒絕，而要靠系統在一開始就限制它能信什麼、能碰什麼、能做什麼，以及做錯後怎麼被看見。

這也是它和很多泛泛而談的 AI 安全文章最大的差別。它不是只列 attack list，而是把部署時真正該做的控制拆成幾個階段：

• Design-time hardening：先定義清楚 trust boundary、tool capability、資料來源可信度與權限範圍
• Runtime monitoring：持續監看 agent 實際呼叫的 API、產生的 side effect、跨 agent 的 delegation 行為
• Incident response：當 agent 已經被誘導執行錯誤行為時，如何回溯、隔離、撤銷與復原

這個 framing 很對，因為 agentic AI 真正缺的從來不是再多一條「請安全地回答」的 prompt，而是像對待高權限 distributed software 一樣去對待它。

這篇論文的限制

作為 SoK，這篇論文的強項是整體視野，但也有它先天的限制：

• 它主要是 systematization，不是新 benchmark 或新防禦系統，因此很多結論依賴既有研究的品質
• 文中提到的評估指標與防禦清單很有方向感，但要真正落到 production，還需要更多實作與標準化
• 2023–2025 這批文獻更新很快，agent framework 與 protocol 生態變動也很快，因此 taxonomy 仍需持續演化

不過這些限制不太影響它的價值。因為這篇 paper 最重要的工作，本來就不是交一個 finished solution，而是把問題畫清楚。

總結

這篇 SoK 最值得記住的一點，是它把 agentic AI 的安全重心，從單一模型輸出風險，拉回到整個系統的信任鏈、權限鏈與執行鏈。

當 AI 只會回答問題時，風險多半還停留在內容層；但當 AI 開始能存取知識、調用工具、記住狀態、委派子任務、持續執行工作時，安全問題就會變成真正的系統安全問題。這篇論文做的，就是把這種質變描出來。

對 sectools.tw 讀者來說，它給出的訊息很直接：未來真正需要被防的，不是某一句 prompt，而是整個 agent runtime 裡每一段被默默信任的資料流與控制流。 如果這些邊界沒有先畫清楚，那麼再聰明的 agent，也只是在把攻擊面做得更自動化而已。

免責聲明

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