Caging the Agents 論文閱讀分析：真正能讓 autonomous agent 比較敢上 production 的，不是更乖的 prompt，而是更硬的系統邊界

論文基本資訊

• 論文標題：Caging the Agents: A Zero Trust Security Architecture for Autonomous AI in Healthcare
• 作者：Saikat Maiti
• 年份：2026
• 來源：arXiv:2603.17419
• 論文連結：https://arxiv.org/abs/2603.17419
• DOI：10.48550/arXiv.2603.17419
• 主題：Agentic Security、Zero Trust、Healthcare Security、Prompt Injection、Kubernetes、Secret Isolation、Network Egress Control

如果最近一波 agentic security 論文都在證明「LLM agent 真的會出事」，那 Caging the Agents 這篇比較像是往前走了一步：既然我們已經知道會出事，那 production 到底該怎麼收？

這篇論文的價值，不在於又整理一次 prompt injection、tool abuse 或 memory poisoning 的風險，而在於它把問題帶到更接近真實部署的層次。作者面對的不是 toy benchmark，也不是單一 demo agent，而是九個已經在醫療科技公司裡上線、能碰 shell、檔案系統、資料庫與多方通訊的 autonomous agents。在這種場景裡，agent 失手不只是模型答錯，而可能直接碰到 PHI 外洩、憑證暴露、未授權資料庫存取、對外 exfiltration，甚至變成合規事故。

所以這篇論文最值得讀的地方，是它把 agent security 從「模型會不會被騙」往「整個執行環境怎麼被設計成就算模型出錯也不至於整條線一起爆掉」推進。換句話說，它談的不是聊天安全，而是runtime containment。

這篇論文想解決什麼問題？

作者的前提很明確：當 LLM 從單純生成文字，變成會呼叫工具、寫檔案、查資料庫、與其他 agent 溝通的 autonomous system，傳統以內容過濾為中心的防禦基本上已經不夠用了。

原因很簡單。真正危險的地方往往不在最後一句輸出，而在這些更底層的權限與行為：

• 模型能不能接觸原始 secrets
• 模型能不能把資料往外送到任何 destination
• 模型是否能執行跨 agent 的不安全委派
• 來自 email、web、文件或其他外部來源的內容，是否會被錯當成高信任指令
• agent image、設定與 runtime policy 是否會在長期運行中逐步 drift

這些問題在醫療環境裡特別尖銳，因為每個失誤都不只是資安事件，也可能是法規與隱私事件。作者因此把核心問題重新定義成：

如果你已經接受 autonomous agents 會進 production，那系統該如何以 zero-trust 方式包住它們，讓模型即使被繞過、被誤導、或做出危險決策，也沒有那麼容易把整個組織一起拖下水？

論文的核心貢獻：不是再講威脅，而是把威脅對應到可部署的控制

這篇論文最實用的地方，是它沒有停在抽象原則。作者先建立了一個六個面向的 threat model，涵蓋：

• credential exposure
• execution capability abuse
• network egress exfiltration
• prompt integrity failures
• database access risks
• fleet configuration drift

這個拆法很有意思，因為它不再把 agent risk 只看成 prompt injection 的延伸，而是承認真正的風險其實橫跨 模型層、執行層、網路層、資料層與維運層。也就是說，agent 的安全問題本質上是整個系統的安全問題，不是 prompt 的安全問題。

四層防線：這篇論文真正值得抄的 deployment thinking

作者提出的 defense-in-depth 架構有四層，而且四層之間分工很清楚。

1. Kernel-level workload isolation

第一層是用 gVisor + Kubernetes 做 workload isolation。這代表作者不把 agent 當成單純應用程式，而是先把它視為一個潛在會亂跑的 execution unit。這個前提非常重要：如果 agent 具備 shell、檔案系統與網路互動能力，你就應該先假設它遲早會碰到惡意輸入或做出危險動作。

因此，第一步不是問模型能不能永遠乖，而是先把它關進一個比較不容易把宿主機與其他工作負載一起拖垮的 execution boundary 裡。

2. Credential proxy sidecars

第二層是我認為最值得所有做 agent 系統的人抄的設計：不要把原始 secrets 直接交到 agent 手上。

作者使用 credential proxy sidecars，讓 agent 容器本身不能直接摸到 raw secrets。這代表即使模型被誘導、遭到 prompt injection，或嘗試把資訊外送，它也比較難直接把真正的 credential 整包帶走。這個思路比起單純在 prompt 裡寫「不要洩漏金鑰」成熟得多，因為它把問題從行為約束改成能力削減。

很多 agent 系統會失守，不是因為模型太壞，而是因為系統先把太多東西直接交給它。這篇論文等於明講：別再讓 agent 持有它不需要持有的祕密。

3. Network egress allowlisting

第三層是 network egress policy。這一層的意義很直接：即使 agent 能讀到敏感資料，也不代表它應該能把資料傳到任何地方。

這其實是很多 agent demo 最容易忽略的一層。大家很常防「讀」和「執行」，卻少防「送出去」。但真實世界裡，資料外洩往往不是因為模型突然講了一句秘密，而是它透過正常 API、HTTP 請求、webhook 或第三方服務把東西 quietly exfiltrate 出去。allowlist egress 的價值就在於：就算 agent 被說服，它能送資料的出口仍然被物理性地縮到很小。

4. Prompt integrity framework

第四層則是 prompt integrity：作者使用 structured metadata envelopes 與 untrusted content labeling，讓外部內容在進入 agent context 時，不會和高信任系統指令混在一起。

這一點與近來許多 agentic security 研究其實高度呼應：真正危險的常常不是外部內容裡有惡意文字，而是系統沒有明確標記「這段東西只是外部資料，不是 owner 指令」。只要信任邊界沒有被結構化表示，模型就很容易把 document、email、網頁、ticket 或另一個 agent 的回話一起當成同等可信。

所以這篇論文的 prompt integrity 不是在做漂亮 prompt engineering，而是在補信任標籤。這才是比較接近 architecture 的思路。

最有份量的部分：它不是理論提案，而是有 90 天 production hardening 經驗

這篇論文比很多架構文更有說服力的地方，在於作者不是只畫藍圖。文中直接報告了 90 天部署結果，包括：

• 九個 autonomous agents 的 production 使用情境
• 跨三個 VM image generations 的持續 hardening
• 由 automated security audit agent 發現並修補的 4 個 HIGH severity findings
• 對應近期文獻中 11 種 attack patterns 的 defense coverage mapping

這裡最值得注意的是那個 automated security audit agent。它意味著作者不只把 agent 視為風險來源，也把 agent 變成安全工程流程的一部分。這個方向很合理：當 system complexity 已經高到人很難靠一次性 review 全抓完時，安全控制本身也得逐漸變成持續運作、持續檢查、持續收斂的 pipeline。

但同時，這篇論文也提醒了一件事：就算你把 agent 拿來做 security audit，也不能因此跳過 sandboxing、egress control 與 secret isolation。因為那個 audit agent 本身仍然是 agent。

這篇論文對 sectools.tw 讀者真正的啟發是什麼？

我覺得這篇論文最重要的訊息，可以濃縮成一句話：

Agent security 的關鍵，不是讓模型永遠不犯錯，而是把整個系統設計成模型犯錯時也不容易釀成大錯。

這和很多早期討論的差別很大。早期做法比較像是「想辦法把 prompt 寫更嚴、規則列更長、模型訓得更乖」，但這篇論文走的是另一條路：先承認 agent 不可完全信任，再用 zero trust 把權限、祕密、輸入來源、網路出口與執行環境層層拆開。

這個思路特別適合今天的 agent runtime。因為我們已經看到太多案例證明：只靠 instruction-level guardrails，不足以阻擋 indirect prompt injection、非預期 delegation、tool misuse、memory contamination 與資料外送。真正能撐住 production 的，通常不是更會說理的 guardrail，而是更硬的系統邊界。

限制與我自己的看法

當然，這篇論文也不是沒有侷限。它的部署場景是在 healthcare，風險模型和法規壓力都特別高，因此控制策略也相對保守。放到一般企業環境時，某些團隊可能會覺得：

• sidecar 與 egress allowlist 會增加整體維運複雜度
• gVisor 與額外 proxy 可能帶來效能成本
• structured trust labeling 要求整個資料流與 orchestration layer 一起配合，不是只改 prompt 就能解

但老實說，這些都不是這篇論文的缺點，反而是它的誠實之處。真正的安全幾乎從來不是零成本。 如果一套 agent 安全方案完全不需要改 deployment、不需要改 credential 流、不需要改 network policy，那它多半只是把風險往後延，而不是把風險真正收斂。

總結

Caging the Agents 最值得記住的，不是它用了 healthcare 這個高壓場景，也不是它羅列了多少 attack pattern，而是它把 agentic security 的重心從「防模型說錯話」轉成「防整個自主系統在錯的時候還有能力把事情做大」。

對今天任何準備把 agent 往真實工作流推進的團隊來說，這篇論文其實是在提醒一個很現實的問題：你該問的不是 agent 聰不聰明，而是它一旦被帶偏，你到底還剩幾層東西能攔住它。

如果沒有，那問題大概不是模型還要再訓，而是架構根本還沒準備好上線。