Governed MCP 論文閱讀分析：真正撐住 Agent 工具安全的，可能不是再多一層 wrapper，而是把治理點直接釘進 kernel

論文基本資訊

• 論文標題：Kernel-Level Tool Governance for AI Agents via Logit-Based Safety Primitives
• 作者：Daeyeon Son
• 年份：2026
• 來源：arXiv:2604.16870v1
• 論文連結：https://arxiv.org/abs/2604.16870
• DOI：10.48550/arXiv.2604.16870
• 主題：Agentic Security、MCP、Kernel Security、Runtime Governance、Tool Mediation、Operating Systems、Safety Primitives

如果最近 sectools.tw 這串文章，一路都在談 prompt injection、tool poisoning、runtime guardrail、authorization boundary、MCP threat model，那這篇 Kernel-Level Tool Governance for AI Agents via Logit-Based Safety Primitives 很值得接著看，因為它把問題又往下一層壓：真正脆弱的，也許不是某個 guardrail 規則寫得不夠細，而是整個安全控制點放錯層了。

作者的核心主張非常直接：今天多數 agent safety enforcement 還活在 userspace，結果就是只要 agent 或開發者有辦法繞過那層 wrapper，整套防線就跟沒裝差不多。如果 tool call 本身其實就像 agent 的 syscall，那真正該問的就不是「有沒有在應用層多包一層檢查」，而是誰握有最底層、最難被繞過的 complete mediation 權力。

這篇論文想解決什麼？

這篇要處理的不是單一 prompt injection，也不是一般意義上的模型對齊，而是更具體的系統問題：

當 AI agent 透過 MCP 去叫 file system、network、API 等外部工具時，我們能不能把每一次 tool invocation 都當成 privileged operation，在真正低層、真正難繞過的位置做治理？

這個 framing 很重要。因為一旦你接受「tool call = syscall」這個類比，很多安全直覺就會跟著改變：

• 安全檢查不該只是 prompt hygiene
• 工具使用不該只是聊天模型的附屬能力
• 真正需要保護的是 side effect 對共享狀態的影響
• 防線位置若高於真正的 action boundary，就天生容易被繞過

也因此，作者提出的是一個 Governed MCP 架構：把 MCP tool governance 做成 kernel-resident gateway，讓所有工具呼叫都必須穿過同一條內核治理路徑。

方法核心：把 agent tool governance 從 userspace 拉回 kernel

這篇最值得記住的主線，不是哪個模型分數比較高，而是這個結構性判斷：

如果你把 agent safety 放在應用層，它本質上就還是一層可被旁路的 middleware；只有當治理點和實際 side effect 邊界綁在一起，它才比較像真正的系統安全控制。

作者把這個想法落成一條六層的 tool-call pipeline：

• schema validation：先確保呼叫格式合理，不是亂打進來的 payload
• trust tier check：依工具或來源的信任層級做前置限制
• rate limit：避免 agent 高速濫用呼叫面
• adversarial pre-filter：先擋明顯惡意內容
• ProbeLogits gate：用 logit-based semantic check 做真正承重的語意判斷
• constitutional policy match：最後再和高層政策做比對

作者甚至把審計鍊做成 Blake3-hashed audit chain。這代表它要解的不是 demo 式「看起來有擋到」，而是想把治理、審計、不可旁路性一起拉進同一個 control plane。

ProbeLogits 在這篇裡扮演什麼角色？

這篇的 companion primitive 是 ProbeLogits（arXiv:2604.11943）。它的思路不是讓模型生成一大段安全分析，再由另一層 wrapper 去讀；而是直接在 forward pass 後讀取特定 verbalizer token 的 logits，把某個 action 分類成 safe / dangerous。

這個設計的關鍵有兩個：

• 不需要完整生成文字，所以 latency 比典型 guard model 更低
• 判斷點更靠近底層執行邊界，因此比較適合被當成 enforcement primitive，而不只是 advisory classifier

在這篇論文裡，作者明講 ProbeLogits gate 是 load-bearing semantic check。這句話其實很誠實：其他層像 schema、rate limit、rule matching 都有價值，但真正決定這套防線是不是只剩 hand-crafted firewall 的，就是那個能理解語意風險的承重點。

系統實作：不只是 paper idea，而是綁進 Anima OS

這篇不是單純概念圖。作者把 Governed MCP 實作在 Anima OS，一個 bare-metal x86_64 OS，整體系統約 86,000 行 Rust。這很重要，因為它讓論文的 claim 不只是「原則上應該可以」，而是至少在作者自己的 agent-native OS 裡，真的把治理點壓到了 kernel。

更關鍵的是，作者聲稱 runtime 中全部 15 個 WASM-to-system host functions 都必須經過這個 gateway。這表示它想主打的不是一般 wrapper 式 guardrail，而是比較接近經典作業系統安全裡的 complete mediation：每次真正可能動到系統狀態的操作，都得被同一條受治理路徑看到。

如果這點成立，那它要傳達的訊息其實很強：

• 不是「讓 agent 更守規矩」
• 而是「讓 agent 就算想亂來，也很難繞過工具治理面」

效能與結果：真正有意思的是 ablation，不只是延遲

在效能上，作者給出的數字是：

• 五個非推論層合計只增加 65.3 微秒 每次呼叫
• ProbeLogits semantic decision 約增加 65 毫秒

這個 latency 對高風險 tool invocation 來說，其實不算離譜。真正值得記的是 ablation：

• 在 101 個 MCP-domain prompt benchmark 上
• 拿掉 ProbeLogits 後，F1 從 0.773 掉到 0.327
• 也就是 ΔF1 = -0.446

這個結果等於在說：只靠手寫規則、防火牆式預過濾、結構檢查，遠遠不夠。 真正把 system-level tool governance 從「看起來有控」撐成「真的能控住」的，仍然是語意判斷層。

我覺得這個結果很有代表性，因為它剛好對應這一年很多 agent security 論文一直反覆出現的主線：規則很重要，但單靠規則，通常守不住語意型攻擊。

這篇論文最值得記住的主線：tool security 的核心其實是 placement，不只是 detection

如果只把這篇當成另一篇 MCP defense paper，就有點可惜。它真正比較有意思的地方是，它把防禦重心從「怎麼多做一個 detector」往前推成：

安全判斷做得再漂亮，如果 enforcement 放在可旁路的位置，系統仍然是假的安全；真正的差異在於安全控制點到底黏在哪一層 execution substrate 上。

這其實把 agent security 和經典系統安全重新接上了。很多近年的 agent paper 還停在 prompt、memory、tool description、response filtering 這些較高層的面；這篇則是說：如果 agent 真要變成作業系統級執行主體，那你對它的治理，也應該開始長得像作業系統安全。

我怎麼看這篇論文？

我對這篇的整體評價是：方向很對、系統味很重，但也帶著很強的作者世界觀。

我喜歡它的地方主要有四個：

• 它抓到真正的 load-bearing question：不是再多一層 guard，而是 guard 放在哪。
• 它把 complete mediation 這種老派系統安全原則重新帶回 agent world。
• 它誠實做了 ablation，證明 semantic gate 才是承重點。
• 它把 audit chain、policy match、runtime mediation 放成同一套架構，而不是零散 patch。

但保留也很明顯。

1. 這比較像 AI-native OS 論文，不是通用現成落地方案

作者跑在自己的 Anima OS 上，這讓架構很完整，但也意味著它不是你今天把 Cursor、Claude Code、OpenClaw 或一般 MCP host 拿來就能無痛套上去的東西。它比較像是在定義 下一代 agent runtime 應該怎麼長，而不是現成給所有現有生態直接套件化的方案。

2. ProbeLogits 很吸引人，但仍然吃 verbalizer / calibration / model 選擇

作者自己另一篇 paper 其實就已經說明，這種 logit-based primitive 的效果跟 verbalizer、calibration 強度、模型組合高度相關。也就是說，它不是魔法；它只是把語意判斷做成更低成本、較難被繞過的 primitive。這很有價值，但仍然需要 deployment-time tuning。

3. 「不可繞過」是架構上更強，不是絕對安全

論文裡那句「10-line userspace bypass structurally impossible」很有力，但也要成熟理解：它指的是對既定 runtime 邊界內的 userspace wrapper bypass 變得不成立，不代表整個系統就沒有其他設計弱點、供應鏈問題、policy bug、或 kernel 自身漏洞。

對實務界的啟示

如果你在做的是 MCP host、agent runtime、coding agent sandbox、或高風險 tool orchestration，這篇有幾個很實際的提醒：

• 把 tool call 當 syscall 看，很多安全設計會瞬間清楚很多。
• 真正該追的是 complete mediation，不只是 clever detection。
• 語意判斷層若只是 advisory，而非 enforcement，就很容易淪為裝飾。
• 規則層與語意層不是二選一，而是應該堆成分層治理漏斗。
• 若 agent runtime 最終會變成 execution substrate，OS-style security 會越來越重要。

更白話地說：很多 agent 團隊現在還在討論「該不該再加一個 prompt filter」，但這篇的答案比較像是——你們可能先該問，真正會動到檔案、網路、憑證與外部狀態的那條路，到底有沒有被一個不可旁路的控制點接住。

總結

Kernel-Level Tool Governance for AI Agents via Logit-Based Safety Primitives 最重要的，不只是提出一個 MCP 防線，而是重新提醒我們一件老派但常被忘記的事：

安全控制的價值，不只取決於它多聰明，也取決於它到底站在系統哪個位置。

放到最近 sectools.tw 一整串 agentic security 脈絡裡，這篇很像一個明確的轉折點：討論已經不只是在比誰的 guardrail 更懂語意，而是開始進入「agent runtime 本身要不要被當成作業系統級治理對象」的階段。

如果這個方向繼續長下去，未來真正成熟的 agent 安全，也許不會長得像今天常見的 wrapper 式防線，而會越來越像 policy-aware execution substrate：每次 action 都被低層治理、每個 side effect 都有可追的審計鏈、每個高風險能力都必須經過不可旁路的 gate。這篇 paper 的價值，就在它把這條路先講得夠清楚了。

免責聲明

本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。