AgenTEE 論文閱讀分析：很多 edge agent 真正缺的，不是再多一層 sandbox，而是連主機 OS 都摸不到它的推理中間態
論文基本資訊
- 論文標題：AgenTEE: Confidential LLM Agent Execution on Edge Devices
- 作者：Sina Abdollahi、Mohammad M Maheri、Javad Forough、Amir Al Sadi、Josh Millar、David Kotz、Marios Kogias、Hamed Haddadi
- 年份：2026
- 來源：EuroMLSys 2026 / arXiv:2604.18231
- 論文連結：https://arxiv.org/abs/2604.18231
- DOI：10.1145/3805621.3807660
- 主題：Confidential Computing、LLM Agents、Edge AI、Arm CCA、TEE、Runtime Isolation
這篇 AgenTEE 我覺得很值得寫，因為它碰的不是大家最愛講的「agent 會不會被 prompt injection 騙走」，而是另一個同樣現實、但更底層的問題：如果 agent 真的開始跑在使用者自己的手機、平板、邊緣裝置上，那誰來保護 agent 自己的 prompt、模型權重、KV cache、工具呼叫內容與跨元件訊息，不被裝置上的 OS、hypervisor，甚至裝置持有人本人看光？
很多人把 edge agent 想成比較隱私，因為資料不送雲端；但這篇 paper 提醒你，「不送雲」不等於「安全」。當 agent 轉到 edge device，威脅模型整個變掉：你不只要防外部攻擊，也得防本機平台軟體、共居 app、甚至惡意使用者本身。這時真正缺的就不是再多一層 application sandbox，而是硬體層級的 confidential execution substrate。
這篇的主線很簡單：很多 edge agent 真正缺的，不是更聰明的模型，而是一個連主機 OS 都看不到 agent 腦內狀態的執行底座。
它想解的不是一般 app isolation，而是 agent pipeline isolation
作者一開始就把問題講得很準。一般軟體做隔離，通常是保護某個 process、某份資料、某個 API key；但 agent 不一樣。它是一條多元件 pipeline，裡面至少包含：
- agent runtime：負責維持上下文、規劃步驟、挑工具、整合回傳結果
- inference engine：真正執行模型推論的地方
- third-party applications / tools：被 agent 呼叫的外部元件
這幾塊之間會持續交換非常敏感的東西，包括 system prompt、模型權重、KV cache、中間推理狀態、工具輸出、使用者資料，以及跨元件協調訊息。傳統 OS process isolation 或 seccomp 在低風險場景也許夠用，但只要 agent 開始接觸高價值資產，這套就不夠了，因為敏感資料在使用中的那一刻，對 privileged software 仍然太透明。
這也是 AgenTEE 最有價值的 framing：agent 安全不是單點 sandbox 問題，而是整條 agentic workload 的 system composition 問題。
為什麼 edge agent 特別麻煩？
如果 agent 跑在雲端，大家通常把威脅模型放在租戶隔離、雲端權限、外部輸入污染；但當 agent 往 edge device 移，麻煩點會變成：
- 裝置上的 OS / hypervisor 可能本身不可信
- 使用者或裝置 owner 可能想偷看 專有 prompt、專有模型權重、商業邏輯
- 第三方 app 需要跟 agent 協作，但雙方未必互信
- agent 中間狀態若外洩，可能不只漏資料，還會漏掉 策略、偏好、工作流結構
論文把 inference engine 的風險拆得很具體。除了模型權重本身有商業價值之外，推論期的 KV cache 與 runtime state 也是資產。這點很重要，因為很多人談 LLM 安全只想到 prompt 與 output，但對 agent 來說，真正高價值的往往是那些「還沒輸出、但已經足以洩漏意圖與上下文」的中間記憶。
AgenTEE 的核心做法：把 agent、模型、第三方元件拆進不同 cVM
AgenTEE 建在 Arm Confidential Compute Architecture（CCA） 上。CCA 讓系統可以建立稱為 realm 的 confidential virtual machines（cVMs），把記憶體保護到 host OS 與 hypervisor 都無法直接讀寫的程度，並支援遠端 attestation。
論文的核心設計非常清楚：
- 把 agent runtime 放進一個 realm
- 把 LLM inference engine 放進另一個 realm
- 把 third-party applications 各自放進獨立 realm
- 元件啟動後，各自向擁有者提供 RMM-signed attestation token
- 擁有者驗證通過後，才把專有資產送進對應 realm
這個設計的精髓在於：不是先把所有秘密灌進裝置，再希望 OS 幫你守；而是先要求元件在硬體保護區裡證明自己是對的，再讓各方只把自己的資產 provision 給那個已驗證的元件。
這對多方互不信任的 agent 生態特別重要。論文直接點出一個很實際的場景：可能一方提供 runtime、一方提供 model、另外還有第三方 app。這種結構下，安全需求不是保護單一使用者而已，而是同時保護多個 stake-holder 彼此不被看光。
關鍵不只在隔離，還在「可信的跨 realm 溝通」
把元件拆進不同 realm 還不是最難；真正難的是：拆開之後它們還得有效溝通。
AgenTEE 這裡結合了 CAEC 的做法，使用 Confidential Shared Memory（CSM） 讓 realm 之間交換資料，同時搭配 inter-realm attestation，確保只有經過驗證與授權的對端才能建立可信通道。換句話說，它不是單純做成「很多密閉盒子」，而是做成很多彼此驗證過身份、再經由受保護共享記憶體交換內容的盒子。
我覺得這點比 paper 表面看起來還重要，因為它碰到 agent 系統常見的一個真問題：安全隔離如果做得太重，整體系統就變得根本不好用；但如果跨元件通道沒保護好，那你前面做的隔離又會在通訊時全部漏光。
這篇最值得記住的不是概念，而是它真的有跑出來
很多 confidential computing 論文容易停在 architecture 圖；AgenTEE 至少往前多走了一步：它真的做 prototype、真的量 latency。
由於商用 Arm CCA 硬體還沒普及，作者使用 OpenCCA 在 Radxa Rock 5B 上實作原型，並另外套用 CAEC patch 來支援 realm 間 CSM。為了讓 realm 間溝通更輕量，他們還做了一個只有 184 行 的小型 messaging library 來處理 message region 與 queue 結構。
評估工作負載用了兩種代表性 agent：
- Chatbot agent：偏問答與摘要，通訊與推論負載較輕
- Itinerary planning agent：規劃型 workload，prompt 與 response 都更長，對 agent–model 互動更重
模型則用了兩個大小不同的本地模型：
- GPT2-Medium-q8_0（437MB）
- Llama-3.2-1B-Instruct-Q4_0（773MB）
最實際的數字：端到端 overhead 低於 5.15%
這篇 paper 最能說服人的地方，是它沒有用「安全很重要，所以多花一點成本沒關係」這種空話，而是真的把成本量出來。
作者比較了三種隔離配置：
- NW Process：同一個正常世界 OS 裡的 processes，以 shared memory 溝通
- NW VM：一般 VM 之間共享記憶體，假設 hypervisor 可信
- AgenTEE：兩個 cVM 以 confidential shared memory 溝通，假設整個 normal world 都不可信
結果很乾脆：
- 相較於 NW VM，AgenTEE 的端到端 overhead 在所有測試都 低於 2.53%
- 相較於最便宜的 NW Process baseline，AgenTEE 的端到端 overhead 也 低於 5.15%
幾個代表數字也很值得記：
- Chatbot + GPT2-Medium：end-to-end 從 93.45s 增到 98.25s，約 5.14%
- Chatbot + Llama-3.2-1B：end-to-end 從 277.80s 增到 289.55s，約 4.23%
- Itinerary + GPT2-Medium：end-to-end 從 163.82s 增到 170.77s，約 4.24%
- Itinerary + Llama-3.2-1B：end-to-end 從 462.31s 增到 485.18s，約 4.08%
這些秒數本身看起來很長，因為實驗平台是較弱的 prototype board，但作者也明講：重點不是絕對延遲，而是強隔離帶來的相對額外成本其實沒有想像中大。
這篇真正有價值的地方：它把「agent confidentiality」講成系統問題
我最喜歡這篇的地方，是它把 agent security 往下挖了一層。最近很多 agentic security 論文都在談：
- prompt injection
- tool poisoning
- runtime guardrail
- policy enforcement
這些都重要，但它們大多預設 agent 執行底座本身還算可信。AgenTEE 則把問題改寫成：如果連 host platform 都不該被信任，那 agent 還怎麼活？
這個角度很關鍵，因為未來真的會出現很多「把 agent 下放到 user device」的產品：本地 copilot、手機助理、車機 agent、工控邊緣分析 agent、離線醫療或企業現場助手。到那時，保護 user data 只是半套；保護 agent vendor 的 model、system prompt、workflow logic 與第三方 service integration 也會變成商業現實。
它的限制也要看清楚
當然，這篇不是萬靈丹。
- 它保的是機密性與完整性底座，不是語意安全：放進 realm 的 agent 還是可能被 prompt injection、tool output manipulation、memory poisoning 影響。
- 目前還是 prototype：作者自己也承認商用 Arm CCA 硬體尚未普及，OpenCCA 只能做 best-effort approximation。
- 效能評估還偏早期：只測了兩種 agent、兩個模型，還沒觸及更複雜的 multi-tool、多 app、長上下文工作流。
但我反而覺得這些限制讓 paper 更誠實。它沒有假裝自己解掉了 agent 的全部安全問題，而是很明確地在補執行底座這一層。
放回最近 sectools.tw 的脈絡，這篇剛好補哪個洞？
如果把最近站上的幾篇文章串起來看，AgenTEE 補的是很缺的一塊：
- CapSeal 在講 secret mediation，重點是不要把 bearer credential 直接交給 agent。
- 治理到執行防線 在講 controls placement，重點是把治理要求翻成對的位置。
- SafeAgent、CASCADE、LogJack 這些在講 runtime threat 與 content-side hijack。
- AgenTEE 則把鏡頭往更底層拉：就算 content-side 問題先不談，agent 的 prompt、weights、KV cache、跨元件通訊本身，也需要一個硬體保護的 execution substrate。
也就是說，這篇不是在跟 prompt injection paper 搶題，而是在提醒：你不能一邊談 agent security，一邊默認底層 OS 一定值得信任。
最後怎麼看這篇？
AgenTEE 最值得帶走的，不是「Arm CCA 很酷」這種表面結論，而是它把一個很現實的產品問題講清楚了：
當 agent 從雲端移到裝置端，真正需要被保護的，不只是不外傳的 user data，還包括 agent 自己那顆腦、那套流程、那條跨元件協作鏈。
如果未來 edge agent 真的要進到高價值場景，光靠 OS process isolation 多半不夠。你需要的是一個能讓 agent runtime、模型推論、第三方元件彼此隔離、彼此驗證、彼此只經由可信通道互動的底層。AgenTEE 至少證明了一件事：這條路不是只能寫在架構圖上，它是能跑、而且 overhead 沒有大到不能接受的。
如果我要把這篇濃縮成一句話，我會寫成：
很多 edge agent 真正缺的，不是再多一層 sandbox，而是連主機作業系統都摸不到它推理中間態的硬體級隔離。
本文由 AI 產生、整理與撰寫；內容基於論文摘要、公開資訊與脈絡化解讀，建議仍搭配原始論文交叉閱讀。