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

Architecting Secure AI Agents 論文閱讀分析：真正能撐住間接提示注入的，不會只是更會拒答的模型，而是把 plan、policy、approval 與 runtime feedback 全部拆開來治理

論文基本資訊

• 論文標題：Architecting Secure AI Agents: Perspectives on System-Level Defenses Against Indirect Prompt Injection Attacks
• 年份：2026
• 來源：arXiv:2603.30016
• 論文連結：https://arxiv.org/abs/2603.30016
• DOI：10.48550/arXiv.2603.30016
• 主題：Agentic Security、Indirect Prompt Injection、System Architecture、Runtime Policy、Human-in-the-Loop、Plan-and-Policy Separation

最近幾篇 agentic security 論文，不是在談 tool poisoning、就是在談 memory persistence、web-agent injection、silent egress 或 guard model。這篇 Architecting Secure AI Agents 比較不一樣：它不是再多塞一個 detector 或 benchmark，而是直接退一步問一個更根本的問題：

如果 indirect prompt injection 本質上是在搶 agent 的控制流，那我們到底該怎麼把 agent 系統本身重新拆成比較可控的樣子？

我認為這篇 paper 最有價值的地方，在於它把焦點從「模型能不能自己看懂哪句話有毒」移到整個 runtime control plane 要怎麼設計。換句話說，作者在講的其實不是 prompt hygiene，而是 agent architecture。

這篇論文在解什麼問題？

作者的出發點很直接：今天很多防禦仍然想把 indirect prompt injection 視為輸入文字分類問題，像是：

• 把危險字串抓掉
• 把系統 prompt 寫更嚴格
• 用另一個 LLM judge 看看有沒有可疑內容

但在真實 agent 裡，風險通常不是某一句文字本身，而是那段外部文字有沒有成功改寫後續的 plan、policy、tool decision 與 information flow。也因此，論文主張：如果要真的處理 indirect prompt injection，不能只盯著 model output，而要把 agent 當成一個完整計算系統來看。

作者想推進的核心問題可以濃縮成一句話：

高效能 agent 幾乎一定需要根據環境回饋動態 replanning；但只要 replanning 存在，攻擊者就會想辦法從 untrusted context 影響 plan 和 policy。那麼，系統該如何一邊保留效用、一邊不把控制權讓出去？

核心架構：把 agent 拆成 orchestrator、plan/policy approver、executor、policy enforcer

這篇 paper 最值得記住的，是它提出的那個高階安全架構。作者認為，一個想兼顧 utility 與 security 的 agent，至少應該把幾個角色分開：

• Orchestrator：根據任務產生 plan 與 policy
• Plan / Policy Approver：檢查現在這個 plan / policy 合不合理，必要時要求修正
• Executor：依照 plan 產生具體 action，例如 tool call 與參數
• Policy Enforcer：在 action 落地前做 allow / deny 決策
• Environment：外部 API、檔案系統、網頁、工具回傳內容

這種切法的意義，不只是模組化而已，而是把安全關鍵決策點從一坨混在一起的「大模型自己想辦法」中硬拆出來。因為只要你不拆，最後就很容易演變成：同一個模型同時讀外部內容、自己修 plan、自己決定可不可以做、再自己真的去做。 那其實就是把整個控制平面都交給最容易被注入影響的那一層。

第一個重點：replanning 與 policy update 不是可選配件，而是一般 agent 的基本需求

我很認同作者的第一個 position：對一般用途 agent 而言，動態 replanning 幾乎是不可避免的。

原因很簡單。現實任務不是 benchmark 裡那種靜態小劇場。API 會改版、網頁會變、權限會失敗、測試會爆、檔案格式會不一致。你如果要求 agent 一開始就把完整細節 plan 到底，而且中途不能根據外界回饋修正，那它在現實環境裡常常根本做不完。

論文舉的例子很到位，像是：

• 資料分析 agent 原本打算呼叫某個 API endpoint，結果 runtime 發現 endpoint 已廢棄，必須改 plan
• coding agent 跑測試、看錯誤、補 patch、再重跑，下一步怎麼做本來就依賴上一輪 execution feedback

這裡真正重要的訊號是：如果防禦只會靠固定 plan isolation，雖然可能比較難被 hijack，但 utility 也可能直接被自己砍掉。 所以問題不是「要不要 replanning」，而是「怎麼做 security-aware replanning」。

第二個重點：policy 也不能假設是一次寫死的靜態規則

很多人談 agent 安全，還是會下意識把 policy 想成傳統 allowlist：哪些工具可用、哪些檔案不能碰、哪些網站不能連。這些當然重要，但這篇 paper 指出一件很現實的事：policy 本身通常會跟著任務與 plan 一起變動。

例如同樣是讀檔、發信、轉帳、安裝套件，能不能做、該不該做，往往不是工具層級可以一次決定，而是要看：

• 目前任務在做什麼
• 這個 action 是否真的是完成任務所必需
• 資料是從哪裡來的
• 這個資訊流會不會把高敏感資料帶到不該去的地方
• 當前情境是否需要人來確認模糊意圖

也就是說，policy 不能只是「永遠禁止 X、永遠允許 Y」這麼粗。它比較像是針對當前 plan 與 context 動態生成、再由系統做 enforcement 的 least-privilege contract。

第三個重點：某些安全判斷還是可能需要 LLM，但前提是它看到的東西必須被嚴格限縮

這篇 paper 一個很成熟的地方，在於它沒有天真地說「全用規則就好」，也沒有反過來說「再加一個 judge model 就能解」。作者的立場比較務實：

某些安全決策可能真的需要 learned model 的語義能力，但它只能在被嚴格限縮觀察面與決策面的前提下使用。

這句話很關鍵。因為今天很多所謂「用 LLM 防 LLM」之所以不可靠，不是因為 learned judge 這個概念本身完全錯，而是因為它常常直接吃進完整、原始、未消毒的外部文字，再被要求做過度寬泛的安全判斷。那當然很容易一起被帶偏。

作者主張更合理的方向是：

• 讓模型只看結構化、範圍被縮小的 artefacts
• 讓模型只負責狹義問題，例如某次 plan update 是否異常、某條 policy change 是否超出任務必要範圍
• 把任意環境文字與任意行動決策分離，不讓同一個 judge 同時接管整個世界模型

我會把這個觀點翻成更直白的一句話：不是不能讓模型參與安全，而是不能讓它在最容易被污染的觀察面上，替你做最開放式的控制決策。

第四個重點：真正難解的地方不只是惡意內容，而是模糊意圖與個人化邊界

這篇 paper 還有一個我覺得很值得保留的誠實：作者明講，有些問題不是演算法再強一點就會自動消失。

例如：

• 「幫我整理最緊急的 email」——什麼叫緊急？
• 「安裝這個看起來跟 debug 有關的套件」——這是合理 troubleshooting，還是被帶去裝惡意依賴？
• 「把錢匯給對的人」——受款人與金額資訊如果來自外部 artefact，到底能不能信？

這些例子都在提醒同一件事：agent security 裡有些風險本質上是 ambiguous objective alignment，不是單純 toxic string detection。 所以 paper 才會把 personalization 與 human interaction 拉進核心設計，而不是只把 human approval 當最後一道土炮保險絲。

作者順手點破了一個老問題：很多 benchmark 太靜態，容易讓防禦看起來比實際更有效

論文另一個很有意思的部分，是它直接批評現有 benchmark 可能會給出過度樂觀的安全感。理由主要有兩個：

1. 很多任務太短、太靜態，幾乎不需要 replanning 或 policy update
2. 攻擊 payload 太固定，沒有把 adaptive attacker 納進來

這個批評我覺得很準。因為只要 benchmark 本身沒有逼 agent 面對動態環境，plan-execution isolation 這種設計就會看起來很完美；同樣地，只要攻擊都還是靜態模板，那很多 detector 也會顯得很能打。但這不代表它們在真實環境裡同樣成立。

換句話說，這篇 paper 不只是在提架構，也是在提醒研究社群：如果 evaluation 場景本身沒有把 runtime adaptation 與 adaptive attack 拉進來，那很多 utility/security trade-off 都會被看得太簡單。

這篇論文對實務上最有用的啟發

如果把這篇 paper 壓縮成幾條對 agent builder 真正有用的設計原則，我會整理成下面五點：

1. 把 plan 和 action 分開：不要讓同一個模型一邊讀外部資料、一邊直接決定下一個高權限 action。
2. 把 policy 從 prompt 文字中抽出來：policy 應該是可檢查、可執行、可更新的顯性物件，不要只是散落在 system prompt 裡的道德勸說。
3. 把 approval / enforcement 變成 runtime boundary：真正的控制點應該在 action commit 前，而不是事後解釋模型為什麼這樣做。
4. 若必須用 learned judge，就縮小它的輸入面與責任範圍：看結構化訊號，做窄任務判斷。
5. 把 human ambiguity 當成設計前提，不是失敗 fallback：模糊意圖、個人化偏好與高風險 actions，本來就該是系統的一級概念。

這些原則其實都指向同一件事：間接提示注入不是只靠更聰明的模型就能解，它更像是 operating system 與 application security 問題重新長在 agent 上。

我怎麼看這篇 paper 的定位？

老實說，這篇不是那種會丟一堆漂亮 leaderboard 數字的論文。它比較像 position paper，很多內容是在整理一個更合理的安全設計框架，而不是直接宣稱「我們已經解決 indirect prompt injection」。

但我反而覺得這種 paper 很重要。因為現在 agent security 很容易陷入一種碎片化狀態：今天補 detector、明天補 benchmark、後天補 memory sanitizer，結果做了一圈還是不知道整體系統到底該長什麼樣子才比較不容易被 takeover。這篇論文的價值，就是把那個 skeleton 重新畫出來。

它也沒有過度承諾。作者承認某些地方還是要靠 learned model，也承認某些地方人就是得介入。這種姿態比「我們找到一招通吃 prompt injection」可信很多。

Takeaway

Architecting Secure AI Agents 這篇論文最重要的提醒，是 indirect prompt injection 的真正戰場不只是輸入文字，而是 agent 的 plan、policy、approval 與 action enforcement 這整條控制鏈。 高效能 agent 幾乎無法避免動態 replanning 與 policy update，因此真正有用的防線，應該是把這些決策點顯性拆開、限制 learned judge 的觀察面、把 human ambiguity 納入系統設計，並在 runtime action boundary 做可檢查的安全執行。說白一點：要讓 agent 比較安全，不只是把模型訓練得更乖，而是把系統架構設計得不那麼容易被接管。

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文摘要與可取得之研究資訊進行整理、解讀與分析。由於本文撰寫時未必涵蓋論文全文所有細節、案例與附錄內容，部分觀點屬基於公開版本的研究性解讀，不應替代對原始論文的直接閱讀。若需引用精確定義、實驗設定或完整方法描述，請以原始論文與作者公開版本為準。