AgentSpec 論文閱讀分析：很多 Agent 真正缺的不是更長的提示詞，而是一個能在 runtime 真的執法的政策層

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

論文基本資訊

• 論文標題：Customizable Runtime Enforcement for Safe and Reliable LLM Agents
• 作者：Christopher M. Poskitt 等
• 年份：2026
• 來源：arXiv:2503.18666 / ICSE 2026
• 論文連結：https://arxiv.org/abs/2503.18666
• 主題：Agent Runtime Security、Policy Enforcement、DSL、Guardrails、Code Agents、Embodied Agents、Autonomous Systems

最近這一串 agent security 論文，很多都在談 prompt injection、tool poisoning、memory persistence、benchmark realism。這些當然重要，但如果把視角再往下切一層，真正會決定系統能不能上 production 的，往往不是「模型有沒有被教乖」，而是：當它準備真的去做事時，你到底有沒有一套能在 runtime 把它攔下來、改道、要求覆核、甚至直接中止的機制。

這篇 Customizable Runtime Enforcement for Safe and Reliable LLM Agents，做的不是再訓一個更懂安全的模型，也不是再做一個只會打分的 judge。它想補的是更工程、也更務實的那一塊：把安全限制寫成可讀、可調、可執行的規則，然後直接插進 agent 的決策與執行流程裡。

如果要把這篇的主線濃縮成一句話，我會這樣寫：

很多 agent 真正缺的，不是更長的 system prompt，而是一個能在 action 落地前持續執法的 runtime policy layer。

這篇論文在打哪個痛點？

現在常見的 agent 安全做法，大致可以分成幾類：

• 靠模型自己判斷什麼能做、什麼不能做
• 在執行前做一次風險評估
• 用 wrapper / detector 看輸入或輸出像不像危險內容
• 把風險交給人工審批，但流程沒有結構化

問題是，這些方法各自都有一個常見盲點：它們不是太黑箱，就是太脆弱，不然就是停在事前預測，沒有真的管到執行當下。

對真實 agent 來說，風險往往不是抽象的「它有沒有生成奇怪文字」，而是非常具體的：

• 是不是正要執行高風險 shell 或 Python 程式
• 是不是正要修改敏感資料
• 是不是在沒有人覆核下做金流、法規或醫療相關決策
• 是不是軌跡前面都正常，但到了某一步突然偏離可接受邊界

也就是說，問題不只是偵測危險，而是怎麼把可執行的限制真正掛到 agent trajectory 上。這篇論文的回答很直接：做一個專門給 agent 用的 DSL，把「何時觸發、檢查什麼條件、要怎麼執法」正式寫下來。

核心設計：AgentSpec 是一個給 Agent Runtime 用的規則語言

作者提出的框架叫 AgentSpec。它本質上是一個輕量級 DSL（domain-specific language），用來描述 agent 的 runtime constraints。每條規則大致由三塊組成：

• trigger：什麼事件發生時要檢查
• predicate / check：在什麼條件下視為有風險
• enforcement：一旦觸發，要採取什麼動作

這種設計很像把 security policy 從散落在 prompt、程式碼、人工 SOP 裡的隱性規範，拉成一個顯式、可審查、可維護的 runtime policy layer。

論文舉的例子很直白：假設 agent 要幫使用者轉帳，那就可以寫成類似下面這種規則：

• 當出現 Transfer 這個行為時觸發
• 如果收款人不是已驗證的 family member
• 那就要求 user inspection，先讓人確認再繼續

重點不是語法本身，而是這個想法：安全限制不再只是「請小心」這種自然語言提醒，而是 runtime 裡真的會被 evaluate、真的會改變 agent 行為的執行規格。

它不是只會擋，還能指定怎麼處理

我覺得這篇一個很實用的地方，是它沒有把 enforcement 簡化成只有 allow / deny。論文裡提到的執法方式包含：

• 直接終止動作
• 要求使用者檢查 / 核准
• 呼叫修正性機制
• 要求 agent 做 retrospective self-examination / self-reflection

這點很重要。因為 production 裡很多高風險場景，不是每次都只能硬擋；有些時候你會想：

• 低風險任務自動放行
• 中風險任務要求人工確認
• 高風險任務直接中止
• 模糊任務要求 agent 先重新檢查自己的理由鏈

也就是說，AgentSpec 比較像一層runtime governance orchestrator，而不是單純的 binary filter。

這篇最值得注意的地方：它把 enforcement 放在 trajectory 裡，而不是只放在前門

很多 guardrail 系統的問題，是把防線放在太早的地方：例如只在 user prompt 進來時掃一次，或只在模型回應時判一次。作者這篇比較值得肯定的，是它明確把問題定義成：

在 agent 每一步規劃與執行的過程裡，持續確認目前的 trajectory 與下一步 action 是否仍然安全。

這個 framing 很對。因為很多 agent 事故不是一開始就明顯違規，而是：

• 前面幾步都正常
• 某一步開始碰到高權限工具
• 某一步開始接觸到特殊資料
• 某一步把環境觀察錯誤解讀成可執行指令

如果防線沒有跟著 execution 一起跑，它就很容易變成「一開始看起來沒事，最後卻已經做錯事」。

跨三種場景驗證：Code Agents、Embodied Agents、AVs

作者沒有只拿單一 toy task 驗證，而是跨了三類場景：

• Code execution agents
• Embodied agents
• Autonomous vehicles

對應的資料集分別包含：

• RedCode-Exec：測試 code agent 在 25 種 vulnerability types、8 個領域下的風險執行
• SafeAgentBench：測 embodied agents 是否會做出火災、電擊等危害行為
• FixDrive：測 autonomous driving agent 在 law-breaking scenarios 下的違規行為

這個 setup 的意義，不只是展示「我們方法可以跨域」，更重要的是它在說：runtime enforcement 不是 prompt injection 專用補丁，而是一種更一般化的 agent control primitive。

結果怎麼看？關鍵不是百分之百完美，而是它真的把 action boundary 接管回來

這篇最常被引用的結果，大概有幾個：

• 在 code agent 場景中，攔下超過 90% 的不安全執行
• 在 embodied agent 任務中，消除所有 hazardous actions
• 在自動駕駛 law-violation 測試中達成 100% compliance
• 執行開銷是毫秒級

我覺得這裡最值得看的，不是把數字當神話，而是它傳達出一個工程訊號：你不一定要把所有風險都交給模型內部學會，很多時候把 policy enforcement 放到 execution boundary，反而更穩、更可稽核。

這也剛好補上最近很多 agent security 論文的共同缺口：大家很會證明 runtime 很危險，但比較少論文真的把「那 runtime 到底要怎麼治理」做成一套可落地機制。

另一個實用亮點：規則還可以半自動生成

如果 AgentSpec 只有手工寫規則，那它雖然合理，但可能會卡在維運成本。作者也想到這點，所以加了一組實驗：用 LLM 來幫忙自動產生 AgentSpec 規則，再由人審核或直接拿來測效果。

論文裡提到，用 OpenAI o1 產生的規則，在 embodied agent 場景下可達：

• Precision：95.56%
• Recall：70.96%

另外，它也能辨識 87.26% 的 risky code，並在 AV zero-shot 設定下成功阻止 8 個案例中的 5 個 法規違反情境。

這組結果我會保守看。它不是在證明「讓 LLM 自動寫政策就萬無一失」，而是在說：policy authoring 這件事有機會被部分自動化，但最後真正有價值的仍是那個可審閱、可修改、可執行的結構化規則層。

這篇對最近的 agentic security 主線有什麼補位價值？

如果把最近 sectools.tw 這串文章串起來看，會發現我們已經談過很多風險來源：

• prompt injection 為什麼會成功
• tool metadata / skill file / retrieval 為什麼會變成控制面
• benchmark 為什麼常高估防禦能力
• memory 與 persistence 為什麼讓一次事故變成長期感染

而 AgentSpec 剛好補的是另一塊：即使你完全承認外部世界不可信、模型也不完美，那 production 系統還能靠什麼在最後一哩控制風險？

作者給的答案其實很 systems security：把 policy 顯性化，把 enforcement runtime 化，把執法行為模組化。

這種思路我認為比單純再加一層「更聰明的 guard model」更值得長期投資。因為模型可能會變、attack surface 會變、tool 會變，但企業最後仍然需要：

• 哪些行為一律不准做
• 哪些情況必須覆核
• 哪些事件要留下可稽核證據
• 哪些限制是依部門、場景、風險承受度而變

這些，本來就比較像 policy engineering，不只是模型能力問題。

我怎麼看這篇論文？

我會把這篇定位成一篇很工程派、也很 production 派的 agent safety / security paper。它沒有用很誇張的 benchmark hype 包裝自己，反而是在處理一個更樸素、也更重要的事：如果 agent 真的要上線，你的限制機制不能只存在於文件裡，得存在於執行路徑裡。

當然，這篇也不是沒有邊界。它的規則能多完整、多細緻，仍然取決於：

• 你能不能正確定義 trigger 與 predicate
• agent framework 能不能提供足夠觀測點
• 環境狀態與工具語意是否可被抽象進 policy
• 規則之間會不會互相衝突或產生維護負擔

但這些限制，老實說正是它可取之處。因為它承認治理本來就是一件需要顯性設計的事，而不是期待模型某天自動長出完美安全感。

幾個最值得帶走的訊號

• 不要把安全全押在 model judgment 上。 很多限制更適合做成外部 runtime enforcement。
• 真正成熟的 agent 安全，不只要 detect，還要 enforce。 而且 enforcement 不能只會一刀切。
• policy 應該是可讀、可調、可審核的。 否則 production 治理會很快失控。
• 毫秒級 overhead 很關鍵。 能不能落地，常常不是看 paper 多漂亮，而是會不會把整條 workflow 拖垮。
• LLM 可以幫忙寫規則，但不該取代規則層本身。 真正重要的是那個可驗證的 policy artifact。

總結

Customizable Runtime Enforcement for Safe and Reliable LLM Agents 最有價值的地方，不是它又找到一個新的 detector，而是它把 agent 安全問題重新拉回一個更成熟的工程語言：runtime constraints、policy enforcement、action boundary、human inspection、corrective intervention。

如果最近幾篇文章一直在提醒大家：agent 的風險早就不是單一句 prompt，而是整條會自己動起來的執行鏈；那這篇補上的就是下一句：既然 execution chain 才是風險核心，那治理也應該沿著 execution chain 去設計，而不是只靠前門過濾。

對真的想把 agent 接進高風險工作流的人來說，這篇 paper 很值得看。因為它談的不是「怎麼讓模型看起來更安全」，而是怎麼讓系統在模型不完美的前提下，仍然比較像一個可被管理的系統。