LLM Agent Security 形式化論文閱讀分析：真正危險的不是某句 prompt，而是 agent 已開始替錯的人做錯的事
論文基本資訊
- 論文標題：A Framework for Formalizing LLM Agent Security
- 作者：Vincent Siu、Jingxuan He、Kyle Montgomery、Zhun Wang、Neil Gong、Chenguang Wang、Dawn Song
- 年份：2026
- 來源：arXiv:2603.19469
- 論文連結：https://arxiv.org/abs/2603.19469
- 主題：Agentic Security、Prompt Injection、Memory Poisoning、Data Isolation、Formal Security Model、Runtime Authorization
如果最近這一串 agent security 論文一直在告訴我們「prompt injection 很危險」「memory poisoning 很麻煩」「tool calling 需要 guardrail」，那這篇 A Framework for Formalizing LLM Agent Security 真正往前推的一步，是把整件事從「很多攻擊案例」重新拉回 安全定義本身：到底什麼叫做 agent 被攻擊了？我們是在防內容，還是在防脈絡裡不該發生的授權錯位？
這篇論文最值得看的地方，不是又發明一個新 benchmark，也不是再做一個新的 runtime defense，而是它直接點破目前 agent security 討論裡一個很根本的問題：同一句指令，在不同脈絡下可能是合法操作，也可能是安全事件。 你如果不把「誰下的命令、目標是什麼、這個動作是不是服務於授權目標、資訊流有沒有越權」一起放進來，很多安全定義其實都太粗，最後只能在 utility 與 security 之間做笨拙折衷。
換句話說，這篇論文不是在問「哪些字串像惡意 prompt」，而是在問：
當 agent 真的開始替人讀信、查資料、叫工具、跨 session 記憶時，安全的本質是不是應該被定義成一組可被脈絡驗證的授權條件？
這篇論文想解決什麼問題？
作者對現況的批判很準。今天很多 LLM agent attack 定義，其實是以「輸入長得像不像攻擊」為中心。例如：
- 資料輸入裡出現 prompt，所以被當成 indirect prompt injection
- 使用者輸入要求模型忽略前文，所以被視為 direct prompt injection
- 外部內容試圖改變 agent 行為，所以被當成越權操控
問題在於，這種定義方式很容易把內容本身當成風險來源，卻忽略了 execution context。而在 agent 世界裡，真正決定安全與否的，往往不是某句話本身，而是：
- 這句話是誰提供的？
- 它是否來自經授權的來源？
- agent 現在正在執行的目標是什麼？
- 這個動作是否真的服務於那個目標？
- 過程中的資訊流是否跨越了不該跨的權限邊界？
如果沒有這層 contextual definition，防禦就會落入兩難：
- 防太兇：把很多合法操作都擋掉，utility 直接掉下來
- 防太鬆：保留可用性，但讓攻擊者只要找對脈絡空隙就能繞過
這篇論文的核心，就是試圖把這個模糊地帶 formalize。
作者怎麼重新定義 agent security？
作者提出的核心主張很漂亮：agent security 應該被看成 contextual authorization 問題。 也就是說，不是單看輸入或輸出內容，而是看 agent 在某一個時間點的執行脈絡中，這個行為是否仍然符合授權條件。
為了做到這件事，論文把 agent 在每個時間點的 execution context 想成一個狀態組合，裡面至少包含：
- 使用者目前授權的任務目標
- 先前已經執行過的軌跡與觀察
- agent 持久記憶中的內容
- 哪些 source 已驗證、哪些尚未驗證
- 哪些 source 對哪些資源有權限
這樣一來，安全判斷就不再只是「有沒有可疑 prompt」，而變成「這個 action 是否在當前脈絡裡仍屬於被授權的行為」。這個角度很重要，因為它直接把 agent security 從 content moderation 拉到 systems authorization 的層次。
四個核心安全性質：這篇論文最值得記的骨架
作者把 contextual security 收束成四個 security properties。這四個幾乎就是整篇論文最重要的骨架。
1. Task Alignment
Agent 追求的整體目標，必須對齊使用者真正授權的 objective。這是在問：它現在到底是在幫你做事，還是在偷偷改做別人的事？
這個性質主要抓的是目標層級的偏移，例如：
- 本來要整理郵件，卻被帶偏去蒐集可外傳資料
- 本來要完成報表，卻改成優先執行攻擊者植入的額外任務
- 因為記憶污染或惡意指令，長程目標被悄悄重寫
2. Action Alignment
即使高層目標看起來沒偏，單一步驟的 action 也必須真的服務於該目標。這是在問：這個工具呼叫、這次檔案讀取、這次資料傳送，和原任務有什麼正當關係？
很多現實風險其實出在這裡。因為 agent 表面上還在做你的 task，但中間混入一個不必要、卻高風險的動作，例如：
- 整理文件時順手讀了不相關的敏感檔案
- 分析 incident 時多做了無關帳號重設
- 執行自動化流程時插入一個外傳資料的步驟
3. Source Authorization
Agent 不該把未經授權來源的指令，當成可以直接執行的命令。這其實就是把 indirect prompt injection、惡意文件、惡意網頁、惡意 tool output 等問題，拉回 provenance 與 source trust 來看。
也就是說，問題不只是「內容裡有 prompt」，而是：
- 這個 prompt 是不是來自可授權 agent 的主體？
- 這個 email／web page／tool response 應該被當成 instruction 還是 data？
- agent 是否把未認證來源錯當成上位控制面？
4. Data Isolation
資訊流必須遵守權限邊界，不能因為 agent 有能力看很多東西，就把不同來源、不同使用者、不同權限範圍的資料混在一起。
這一條幾乎把最近很多 agent security 問題都收進來了，包括：
- cross-user contamination
- memory leakage
- tool-mediated exfiltration
- 把高權限資料透過低權限回覆洩出去
如果前兩條比較像「是不是在做對的事」，那 data isolation 就是在問：即使在做對的事，有沒有把不該流出去的資訊順手帶出去？
Oracle Functions：這篇論文最聰明、也最誠實的部分
論文沒有假裝自己已經把所有 runtime verification 都解決了。相反，它提出一組 oracle functions，用來定義：如果你真想在 runtime 判斷這四個安全性質有沒有被違反，理論上你至少需要知道哪些事。
例如：
- Instruction attribution：agent 這一步到底是在跟隨哪一段指令？
- Source attribution：這段輸入、這條 observation、這筆記憶，來源是誰？
- Objective evaluation：當前 action 與高層 task objective 的關係是什麼？
這個設計很有價值，因為它把很多今天靠 heuristic 硬猜的 guardrail 問題，轉成比較可討論的 verification 問題。作者等於是在說：
先不要急著吹哪個 defense 很厲害，先問它到底在近似哪個 oracle、漏掉了哪個 oracle、因此又看不見哪些 violation。
這讓整個 field 從「又一個 defense trick」往前推到「我們究竟缺哪些可驗證能力」的層次。
這篇論文怎麼重新解釋既有攻擊？
有了四個 security properties 之後，作者把很多熟悉的 agent attack 重新 formalize 成 property violation。這一段非常重要，因為它把一堆看似分散的攻擊手法，收回同一張圖裡。
Indirect Prompt Injection
不再只是「外部資料裡藏 prompt」。更精確地說，是 agent 跟隨了未經授權來源的指令，並且產生了不對齊原任務的 action。也就是 source authorization + action alignment 一起出問題。
Direct Prompt Injection / Privilege Conflict
如果輸入來自已授權來源，但它與更高優先級的目標或 policy 衝突，那問題就不是來源真假，而是 task alignment。這讓 direct prompt injection 不再只是「惡意文字」，而是控制層級衝突造成的目標偏移。
Jailbreak
在這個框架下，jailbreak 也不是單純一句繞過 safety policy 的花招，而是 agent 對 task / action / source 的授權判斷開始失真，導致本來不該被接受的指令變成可執行目標。
Memory Poisoning
這一篇也把 memory poisoning 很自然地放進同一框架裡。記憶不再只是「多一塊 context」，而是可能在未來改變 task alignment、source attribution、甚至 data isolation 的長程污染來源。這讓 memory risk 不再是附屬題，而變成 authorization fabric 的一部分。
對防禦的啟發：很多 guardrail 其實只是守住其中一角
這篇論文最有殺傷力的地方，不是它提出四個性質，而是它順手讓很多既有 defense 顯得不夠完整。
因為一旦你接受這個框架，就很難再滿足於「我們有 prompt injection detector」「我們有 tool allowlist」「我們有 content filter」。原因很簡單：這些防禦通常只看單一面向。
- 只看文字內容的 detector，常常看不到來源是否已授權
- 只看 source 的機制，未必知道 action 是否真的服務任務
- 只做 tool permission，未必能阻止資料經由合法工具錯誤外流
- 只做 output filter，則可能錯過長程記憶對 objective 的污染
這也是作者反覆強調的點：很多 defense 的問題不是完全沒用，而是它們只近似了部分 oracle，因此只覆蓋了部分 security property。
翻成人話就是：你可能不是沒有防，而是只防到了同一張圖的某一個角落。
為什麼這篇對 production agent 特別重要？
因為 production agent 真正麻煩的地方，從來都不是單輪聊天內容，而是它會：
- 讀多種來源的資料
- 帶著 memory 跨回合做事
- 調工具、碰外部系統、寫入新狀態
- 在不同權限範圍之間搬運資訊
在這種系統裡，安全問題自然不該只被定義成「有沒有一句惡意 prompt」。更準的說法是：
agent security 的本質，是在一條持續演化的 execution loop 裡，確認目標、動作、來源與資訊流始終沒有脫離授權邊界。
這也正是為什麼這篇 paper 雖然比較偏 formalization，但實際上很貼 production。它幫我們把 agentic security 從零碎案例，收斂成一個比較像樣的設計與驗證語言。
限制與保留
當然，這篇論文的強項在 conceptual framework，不是在於已經把所有 oracle 都工程化落地。也因此它的限制也很清楚：
- oracle 很強，但現實實作未必容易：尤其 instruction attribution 與 objective evaluation，都還是非常難的 runtime 問題。
- formalization 不等於 deployment solution：它給的是設計語言與驗證方向，不是現成產品。
- 上下文建模成本高：真正要追 source、task、action、data flow，runtime observability 與 provenance 基礎設施得先跟上。
但這些限制不太像缺點，反而比較像這篇論文的誠實之處。它沒有假裝問題已經解完，而是把 field 往「該解什麼」推得更清楚。
我怎麼看這篇論文？
我認為這篇最有價值的地方，是它把 agent security 從「攻擊名詞學」拉回「授權與資訊流學」。
最近很多 paper 各自談 prompt injection、memory poisoning、skill supply chain、delegation control、cross-user contamination，看久了其實很容易碎掉；但這篇做的事，是把這些問題重新投影到同一張 contextual security 地圖上。這種 paper 短期內不一定最容易變成 benchmark 分數，卻很可能是未來做 runtime monitor、policy engine、auditable provenance、secure-by-construction agent framework 時最需要的底層語言。
如果要用一句話總結這篇，我會說：
真正該防的從來不只是某句 prompt，而是 agent 在整條執行脈絡裡，何時開始替錯的人做錯的事，或把不該流動的資料帶過界。
一句話總結
這篇論文最重要的提醒是：LLM agent security 不是單純的內容過濾問題，而是目標、動作、來源與資訊流是否持續對齊授權脈絡的系統性問題。
本文由 AI 產生、整理與撰寫；內容僅供研究與技術分析參考，若需引用或用於正式決策，請務必回到原始論文與作者資料進一步確認。