SentinelAgent 論文閱讀分析：當多代理 AI 開始互相委派，真正該驗的就不只是 Prompt，而是整條授權鏈

論文基本資訊

• 論文標題：Intent-Verified Delegation Chains for Securing Federal Multi-Agent AI Systems
• 系統名稱：SentinelAgent
• 作者：KrishnaSaiReddy Patil
• 年份：2026
• 來源：arXiv:2604.02767
• 論文連結：https://arxiv.org/abs/2604.02767
• 主題：Agentic Security、Multi-Agent Systems、Delegation Security、Authorization Chain、Intent Verification、Formal Methods、Runtime Enforcement

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

如果最近這一串 agentic security 論文一直在講 prompt、memory、tool、protocol、runtime supply chain，那 SentinelAgent 想補上的，是另一個其實更接近 production 現場、也更容易被忽略的問題：當 Agent A 把事情交給 Agent B，Agent B 再去叫 Tool C，最後代表的是誰的授權、誰的意圖、誰要負責？

這篇 paper 值得寫，不是因為它又多做了一個 guardrail，而是因為它把多代理系統裡最麻煩的一段抽出來處理：delegation chain。單一 agent 的安全問題，你還可以說是在防 prompt injection、限制 tool scope、監控輸出；但一旦進入多跳委派，風險就立刻升級成結構性問題——權限有沒有越傳越大？原始使用者意圖有沒有在中途被改寫？跨組織、跨承包商、跨雲服務時，policy 是不是還活著？出了事之後，能不能追到是哪一跳出錯？

換句話說，SentinelAgent 談的不是 agent 會不會亂做事，而是 agent chain 到底能不能被問責。

這篇論文想解決什麼？

作者的問題意識很準。現有很多 agent security 工作，會分別處理 access control、policy checking、safety filtering、trajectory monitoring 或 protocol verification；但真實多代理系統往往不是單點執行，而是：

• 人把任務交給前台 agent
• 前台 agent 再委派給專職 agent
• 專職 agent 去呼叫外部 API 或工具
• 工具結果又回流到另一個決策 agent

這時真正危險的，不只是某個 agent 被 injection，而是整條委派鏈開始失去可驗證性。你很難回答：

• 這個行為到底是誰授權的？
• 子任務是否仍然忠於原始意圖？
• 中途有沒有偷偷擴權？
• 跨單位後有沒有漏掉原本必須遵守的 policy？
• 如果發生錯誤或濫用，能不能完整回溯？

所以這篇論文的核心，不是再做一個「更聰明的 agent」，而是嘗試把 delegation accountability 做成一個正式模型加 runtime enforcement 機制。

SentinelAgent 的核心主張：別只驗 agent，要驗 delegation chain

作者提出的是一套名為 Delegation Chain Calculus（DCC） 的形式化模型，外加一個執行期協定 Intent-Preserving Delegation Protocol（IPDP）。它的想法可以濃縮成一句話：

每一次委派都不只是轉交任務，而是同時轉交 scope、intent、policy 與可追溯性；因此每一跳都必須被驗證，而不是只在入口做一次檢查。

這裡最有意思的，是作者沒有把問題簡化成「判斷這句 prompt 安不安全」，而是把每個 delegation token 都建模成一個同時包含下列資訊的物件：

• authority scope：這一跳到底被允許做哪些事
• intent：這個子任務是否仍保留原始任務的意圖
• policy constraints：原本必須遵守的政策與控制要求
• hash-linked parent：這一跳和上一跳之間的不可否認鏈結

也就是說，SentinelAgent 真正想做的，是把多代理委派從「語意上看起來合理」拉回到「結構上能被驗證」。

七個安全性質，抓住多代理委派最容易失控的地方

這篇 paper 的骨架，是它定義的七個 delegation properties。這七個性質其實就是一張很實用的 agent delegation threat model 地圖：

• P1 Authority Monotonic Narrowing：子代理不能拿到比父代理更多的權限。這是在防 delegation 變相擴權。
• P2 Intent Preservation：子任務不能背離原始意圖。這是在防任務被悄悄改寫。
• P3 Policy Preservation：原本適用的政策限制不能在中途掉失。這是在防跨邊界委派時的 compliance 漏洞。
• P4 Forensic Reconstructibility：任何行為都能回推出完整授權鏈。這是在防事後追責時只剩黑盒。
• P5 Cascade Containment：一旦出現違規，擴散半徑必須可控。這是在防 delegation chain 一路連環爆。
• P6 Scope-Action Conformance：即使 scope 合法，實際 API call 也必須受 manifest 約束。這是在防「名義合法、行為偷跑」。
• P7 Output Schema Conformance：即使呼叫的是合法 API，輸出也不能超出允許格式。這是在防「工具合法、輸出作惡」。

我很喜歡這組拆法，因為它點出一件常被忽略的事：agent security 不只是在防 unauthorized action，也是在防 authorized channel 被拿去做 unauthorized outcome。 單看 scope 還不夠，你還得看它到底呼叫了什麼，以及最後產生了什麼。

最誠實也最重要的一點：intent verification 本來就不可能完全 deterministic

這篇論文最值得肯定的地方，不是它宣稱自己解決了 intent verification，而是它很誠實地說：deterministic 的 intent verification 幾乎不可能。

作者直接把這件事當成一個命題來談：自然語言裡的委派意圖，本來就有語義模糊、上下文依賴與惡意改寫空間，所以你不可能指望單一規則或單一分類器，在零誤判、零漏判下穩定判斷所有 delegation intent。

這也是為什麼他們沒有把整個安全性押在「模型要看懂意圖」上，而是改成三層驗證生命周期：

• Pre-execution：先做 keyword + NLI 式 intent 檢查
• At-execution：真正呼叫 API 時，由 deterministic scope enforcement proxy 擋下越界行為
• Post-execution：輸出再經過 schema validation，避免合法工具產出不合法結果

這個設計背後的觀念非常對：既然 intent 很難完美判準，就不要把安全性全押在 intent 上；把 deterministic control 放在 action 和 output 層，讓語義判斷失手時，系統仍然有硬邊界。

這其實也呼應了最近很多 agentic security paper 的共同結論——真正可靠的安全，不該只靠模型自己說「我懂你的意思」。

為什麼這篇 paper 比一般 guardrail 文章更有系統味？

因為它不只是做偵測，還把formal model、runtime protocol、compliance mapping、mechanical verification 接在一起。

作者不只提出 DCC 和 IPDP，還加上：

• Delegation Authority Service（DAS）：一個非 LLM、可被信任的中介層，負責 token 簽發與驗證
• Federal Compliance Mapping Engine：把 NIST SP 800-53 與 OWASP agentic risks 映射成可執行 constraint
• TLA+ model checking：對 P1、P3–P7 做機械驗證
• DelegationBench v4：用 516 個 scenario、10 類攻擊、13 個 federal domains 做評估

這整套做法的價值，在於它把「agent governance」從口號往 security engineering 推了一大步。你可以不同意它所有實作細節，但很難否認它抓到了一個方向：多代理系統的安全，不只要 policy，要有可以插進 runtime 的可驗證控制面。

怎麼看實驗結果？亮點很亮，但限制也很明顯

論文裡最吸睛的數字，是三點驗證 lifecycle 在 DelegationBench v4 上做到 100% combined TPR、0% FPR，黑箱攻擊條件下也能擋下 30/30 attack。

這個結果當然漂亮，但我覺得真正該看的不是漂亮數字本身，而是它透露出的結構訊息：

• deterministic properties 很硬：像 authority narrowing、policy preservation、scope/action/schema conformance 這類，只要控制面存在，就真的能形成硬邊界。
• intent verification 還是軟肋：面對 sophisticated paraphrasing，P2 仍然明顯退化。
• 三層防線之所以有效，是因為彼此補洞，而不是因為語意理解已經被完美解決。

換句話說，SentinelAgent 最有價值的地方，不是證明「模型終於懂了」，而是證明即使模型不完全懂，你也可以靠更好的委派結構設計，讓它比較不容易闖禍。

當然，這篇 paper 也有幾個要保留的地方：

• 場景高度偏 federal / governed workflow，對一般商業 agent stack 的可移植性還要觀察。
• Intent 這一層仍有對 NLI 模型與資料分布的依賴，換 domain 不一定一樣穩。
• Schema 與 manifest 的維護成本不低，真實世界若工具很多、流程常改，治理負擔會快速上升。

但即使如此，這篇 paper 還是很值得看，因為它沒有逃避這些代價，而是明確告訴你：如果你真的想讓 multi-agent system 碰高權限流程，這些治理成本本來就不可能省。

我怎麼看這篇論文

我會把 SentinelAgent 看成最近這波 agentic security 論文裡，從 prompt / tool / memory 攻擊面，繼續往「delegation control plane」推進的一篇關鍵文章。

如果說：

• ClawLess 在講的是 runtime hard boundary
• AgentRFC 在講的是 protocol composition safety
• Your Agent Is Mine 在講的是 API / router trust boundary
• ShieldNet 在講的是 runtime network-visible supply-chain injection

那 SentinelAgent 講的就是：當 agent 開始彼此委派、共享授權並代表使用者行動時，真正要被保護的不是某一段 prompt，而是整條 delegation chain 的 authority、intent、policy 與 accountability。

這也是我覺得它比很多「再加一道 classifier」型論文更重要的原因。它在提醒大家：多代理系統一旦進入高權限場景，安全問題的最小單位已經不是單一模型回合，而是可追溯、可約束、可驗證的委派鏈。

一句話總結

SentinelAgent 最重要的貢獻，不是讓 agent 更會判斷意圖，而是把多代理委派從「誰都說自己有被授權」變成「每一跳都必須拿得出可驗證的授權鏈、行為邊界與事後追責證據」。

對想把 agent 放進 SOC、自動化審批、政府流程、企業內部高權限工作流的人來說，這篇 paper 提醒得很直接：agent 之間真正危險的，不是它們會聊天，而是它們會互相代辦。