會幫你做事的系統，就是高權限系統
論文裡有一個概念叫 confused deputy problem，講的是一個有權限的程式，被其他沒有權限的東西利用去執行壞事。這個問題從 1988 年 Hardy 提出到現在，換了 AI agent 的外皮之後，變得更難防。
最近 HN 有篇文章，Imperva 和 Varonis 各自展示了對 OpenClaw agent 的攻擊方式。前者把 hidden instruction 藏進 shared contact、vCard、location label 這三種入口，讓 agent 在不知情的狀況下執行下載腳本。後者更簡單，用一封看起來正常的 email，讓 agent 把 mock AWS keys 和 customer export 整包轉寄出去。OpenClaw 在 2026.4.23 修掉了 message-object flattening 的漏洞，但這解決不了根本問題。
真正的問題其實可以用一個很直觀的框架來想。一個 agent 如果同時滿足三個條件，就是高風險系統：能讀私密資料、能吃不可信的輸入、又能對外送資料。Varonis 把這三個加在一起叫 lethal trifecta，我覺得這個命名蠻準確的。三個條件缺任何一個，攻擊鏈就斷掉。問題是現在大部分設計 agent 的人，根本沒意識到自己的系統同時符合這三個條件。
讓我用一個比喻說明為什麼這很麻煩。你幫公司請了一個新員工，給了他 email 帳號、AWS console 存取權、以及讀取 CRM 的權限，因為他的工作需要。這個員工每天接收外部信件、拜訪客戶、讀各種文件。你怎麼確保他沒有被釣魚，沒有在不知情的狀況下做出讓公司受損的事？你現在的答案大概是培訓、SOP、職責分離。
Agent 的情況更難，因為你連「他有沒有被釣魚」都很難即時判斷。你能給新員工做防社工訓練，但你沒辦法 fine-tune 一個 agent 讓它完全免疫 prompt injection。Imperva 示範的那些攻擊不需要任何技術能力，隨便一個能建 shared contact 的人都可以試。vCard 裡面藏幾行指令，agent 讀到就執行，整個流程跟正常操作沒有任何外觀差異。
這讓我想到 multi-agent systems 研究裡一個常常被忽略的面向：trust boundary 的設計。很多架構討論都在聊 how do agents coordinate，但相對少人討論 what should each agent be allowed to read and write。Reviewer 審論文的時候也不太在乎這塊，大家更在意 performance benchmark。現在看來這個順序搞反了。
解法不是讓 agent 更聰明，是從設計層面縮小攻擊面。幾個方向值得想：第一，把「能讀私密資料」和「能吃外部輸入」的功能分開，不要讓同一個 agent 同時做這兩件事。第二，輸出管道要明確限制，agent 能送資料到哪裡，要預先白名單，靠 prompt 指示是不夠的。第三，敏感操作加人工確認節點，不是因為 agent 不可信，是因為 trust boundary 需要用系統設計來強制。
後兩點其實是傳統 security 的老話，minimum privilege 和 explicit authorization。只是大家在設計 AI agent 的時候很容易忘記這些原則。你花很多時間調 system prompt，讓 agent 更有禮貌、更準確、更會規劃，卻沒有問過一個基本問題：「這個 agent 最壞情況能做到什麼？」
Varonis 的攻擊之所以成功，不是因為語言模型理解不夠好，是因為整個系統同時具備了讀取敏感資料、接收外部輸入、對外傳送資料的能力。這是架構決策的結果，不是 bug，也不是靠 patch 能根本解決的問題。2026.4.23 修掉的 message-object flattening 很重要，但那是修一個技術漏洞，不是縮小 attack surface。
以我研究 multi-agent 系統這幾年的觀察，很多設計上的安全假設是隱性的，從來沒有被明確寫出來。大家預設 agent 只會按照期望行動，預設外部輸入是乾淨的，預設 privilege 不會被濫用。這些假設在 demo 環境或許成立，部署到真實世界就不一定了。
博士論文寫到一半，我突然覺得可能要加一個新的 chapter 了。
作者：十年大博士