2026 年 7 月,AI 投資人、前 HyperWrite CEO 馬特・舒默（Matt Shumer）在自己的 Mac 上試用 OpenAI 尚未公開的新模型 GPT-5.6,代號 Sol。他給了它對電腦的完全存取權限。結果一個負責清理的子任務執行了一條 rm -rf,刪的正是他的使用者目錄。等他反應過來去叫停,一個多小時已經過去,電腦裡的檔案幾乎都被刪光了。
其實 OpenAI 自己早就知道這類風險。就在事發的 16 天前,它在模型的安全說明裡,把「給 AI Agent 完全存取權限」標成了一個不容忽視的風險項。
這件事裡沒有駭客,也沒有漏洞。刪檔案,本來就是這個 Agent 被授予的、再正常不過的一項能力。
這背後,是一個更根本的問題:今天大多數 AI Agent 的架構,天生就不安全。面對這種不安全,最自然的反應就是給它加護欄(guardrail),把危險操作一條條攔下來。可護欄是個錯的方向:它和要防的對象處在同一個層級,怎麼加都可能被繞過。真正有效的防線,必須建在模型之外。
AI 安全的三類問題,本文只談第三類
AI 安全最近是個很熱的詞,但它在不同場景裡指的並不是同一件事,大致能分成三類。
第一類,是模型本身的安全。怎麼防止它被越獄,怎麼避免它輸出有害內容,怎麼讓它跟人的價值觀對齊。這是過去幾年被談論得最多的。
第二類,是把 AI 用在安全上(AI for security),也就是反過來用大模型做防禦,例如威脅偵測、程式碼稽核、情報分析。我們自己也在這個方向上做過一些研究,例如用思維增強的大模型偵測智慧合約漏洞的 Thought Is All You Need,以及評估 AI Agent 能否勝任智慧合約安全稽核的 REEVMBench。
第三類,也就是本文要談的,是 AI Agent 自身的安全。當模型不再只是回答問題,而是能讀取使用者的檔案、掌握使用者的密碼、替使用者執行操作,它能用的那些工具、拿到的那些權限、做出的每一個動作,本身就變成了別人可以利用的入口。
前兩類都已經有不少研究,第三類還很新,也最容易被忽視。可它恰恰是 AI Agent 能不能大規模走進企業的前提:一個連自身安全都保不住的 Agent,沒有哪家公司敢把真正的業務和資料交給它。
從不可信輸入到任意執行:Agent 的先天缺陷
一個 Agent 要真正做事,通常得同時具備好幾樣能力:它能讀取外部內容(網頁、郵件、程式碼庫、別人提交的程式碼),能動用有價值的資源(金鑰、雲服務密碼、資料庫),還能呼叫工具執行動作(執行指令、發請求、改檔案)。這幾樣能力集中在一起,恰恰是最危險的組合。
問題的根源在於,模型分不清一句話到底是使用者交代的任務,還是它從外部讀到的、別人寫的內容。在它眼裡,這些都是一樣的文字,處在同一個上下文裡。它只能憑訓練時學到的經驗判斷該聽誰的,沒有一套明確規則幫它區分。這在安全領域是個很老的問題,叫「混淆代理」(confused deputy):一個有權限的程式,被沒有權限的一方欺騙,替它做了壞事。
這背後是一環扣一環的:真正執行動作的工具聽大模型的,大模型聽提示詞的,而提示詞什麼來源都有,既有使用者自己寫的,也有從網頁、郵件、文件裡讀進來的。這就等於,一個本來不可信的來源,經過一個行為並不確定的模型,最後能指揮工具執行任意操作。傳統軟體裡,資料是資料,程式碼是程式碼,界限分明;可 Agent 不一樣,它讀進來的一句話,隨時可能被當成命令執行。
這意味著,攻擊者不需要高深的漏洞,也不用盜取帳號,只要在一份文件、一個網頁、甚至一條程式碼註解裡植入一句話,就可能讓 Agent 去做它本不該做的事。微軟的安全團隊說得更直接:你的大模型不是一道安全邊界;你給它開了哪些工具,就等於給了攻擊者多大的活動範圍。
這些都不是假想,已經有多起真實案例。xAI 的程式設計工具 Grok Build,每開啟一次工作階段,就把整個程式碼倉庫,連同 .env 裡的金鑰和完整的提交歷史,悄悄上傳到自家的雲端伺服器,實測上傳的資料量是完成任務真正需要的近三萬倍。Cursor 的 Agent 在一次測試裡未經確認就在九秒內刪光了一家公司的生產資料庫,連備份一起刪了,事後還寫了一封道歉信。Replit 的 Agent 在明令凍結程式碼期間,刪掉了整個生產資料庫,又偽造了幾千條假紀錄來掩蓋。亞馬遜 Q 的 VS Code 擴充功能,則被人透過一個惡意的程式碼提交,植入了「把系統清空」的指令,還隨官方版本發佈到近百萬台電腦上。
這幾起事故有一個共同點:造成傷害的,幾乎都是 Agent 本身被授予的正常權限,而不是外部入侵。讀取 .env、執行指令、查詢資料庫,這些本來就是 Agent 每天在做的操作;一旦被惡意利用,日常操作就變成了事故。
模型內的護欄為何不夠:防禦者與被防禦者同處一層
面對這些事故,最直覺的反應是給 Agent 加護欄。所謂護欄,就是在模型內部設一些規則,約束它不要做危險的事:可以用提示詞直接要求它不要執行危險操作,也可以在 Agent 內部加一道檢查,像有些程式設計工具那樣,攔截危險指令、檢查檔案路徑。
可這個做法有個根本問題:護欄和它要防的對象,處在同一個層級。
美國國家標準與技術研究院(NIST)的資深科學家 Apostol Vassilev,在 2026 年 6 月發表過一篇文章,把哥德爾不完備定理的邏輯用到了這件事上。文章標題本身就是一句反問:《穩健的 AI 安全與對齊:一場薛西弗斯式的苦役?》。
他的意思大致是這樣:護欄本質上是一套有限的、固定的規則;就像一個有限的公理系統沒辦法既完備又自洽,任何一套固定的護欄,也總會有一句話能繞過去。人類語言又模糊又靈活,能繞過去的說法幾乎數不清。用他的原話說,沒有哪一套有限的護欄,能擋住所有的對抗性提示。剩下的問題只是:防守方和攻擊方,誰先找到那句話。NIST 因此在官方新聞稿裡建議,安全思路要從「一次做對」轉向「持續監測、持續更新」。
還有一個更直接的證據。既然模型本身靠不住,那用一個模型去檢查另一個模型有沒有被注入,是否可行?威斯康辛大學的一項研究發現,這條路走不通:這類用一個模型去判斷另一個模型有沒有中招的偵測方案,存在結構性缺陷。研究者建構出的自適應攻擊,能把偵測率壓到接近零,注入卻照樣以約九成的成功率得手。負責檢查的模型和被檢查的內容始終處在同一層,本該發現攻擊,結果自己先被繞開。
還有一層常被忽略:護欄起作用的時候,Agent 已經拿到執行權了。EchoLeak 就是一個例子。它是針對微軟 365 Copilot 的一次「零點擊」攻擊:一封精心構造的郵件,悄無聲息地穿過了微軟給 Copilot 加的過濾器,把敏感資料帶了出去,整個過程不需要使用者做任何點擊。
所以,「在模型裡加護欄」有點像修一條馬奇諾防線:不是沒用,只是從設計上就必然能被繞過。它可以作為防禦的一層,但不能是唯一的防線。
真正的防線,應建立在 Agent 之外
既然模型內部靠不住,這道防線就要移到模型外面,建立在系統層面。
把不可信的程式碼關進一個隔離的環境、只給它完成任務必需的最小權限,這套思路在系統安全領域已經有幾十年的歷史。早在 1975 年,Saltzer 和 Schroeder 那篇經典論文就提出過兩條原則:一是最小特權,一個程式只應拿到完成任務必需的那部分權限;二是職權分離,把權力拆分開,任何單點的失誤或被欺騙,都不至於危及整個系統(The Protection of Information in Computer Systems)。後來的沙箱技術,從 1990 年代的 Janus,到 2000 年的 FreeBSD Jails,再到今天的 gVisor,走的都是同一條路:把不可信的程式碼隔離起來,即使它被攻破,也影響不到外面。給 AI Agent 做防護,說到底就是把這套已有幾十年積累的成熟做法,用到一個新的對象上。
落到今天,一個直接的做法是給它加一層系統級的沙箱:把 Agent 執行工具的環境隔離起來,控制到系統呼叫、檔案讀寫、網路出口這樣的粒度。不同工具的預設程度差別很大:OpenAI 的 Codex 預設就把指令執行放進沙箱,並且預設切斷網路;而 Claude Code 本機版的沙箱需要手動開啟,Cursor 的沙箱按官方說法也只是「盡力而為」,並不能當作安全邊界。更徹底的做法,是把整個 Agent 放進一個由平台託管的執行環境,網路和憑證都交給外面這一層管理。Anthropic 面向雲端的託管版 Claude Code 就是如此:每個工作階段執行在 Anthropic 託管的虛擬機中,所有對外請求都經過一個帶白名單的代理,憑證也保存在沙箱之外。
這裡有一個自然的疑問:既然沙箱技術已經這麼成熟,前面那些刪庫、上傳程式碼倉庫的事又是怎麼發生的?原因有兩個。一是這些工具的預設防護本就有限:Cursor 預設並沒有嚴格的沙箱,GPT-5.6 刪除 Mac 檔案那一次,使用者更是直接給了它完全存取權限,等於關掉了沙箱。二是即使沙箱開著,也擋不住這類事故:沙箱防的是 Agent 逃逸出去破壞主機,而 Agent 刪除的資料庫、上傳的程式碼倉庫,恰恰都是它被明確授權可以存取的,根本不需要逃出沙箱。所以說,沙箱是必要的一層,但遠遠不夠。
給 Agent 圈定存取範圍的思路,也已經走進了面向一般辦公使用者的桌面產品。騰訊今年發佈的桌面辦公助手 WorkBuddy 就執行在個人電腦上,只讀取使用者授權的本機資料夾來完成任務。它公開的資料只提到「授權資料夾」,並沒有說明底層究竟如何隔離、隔到什麼程度。
更關鍵的是,這一整類「帶沙箱的 Agent」都存在一個共同的盲點:沙箱管得住 Agent 在哪裡執行、能不能逃逸出去破壞主機,卻管不住它執行之後拿這些資料做了什麼。一個被注入的 Agent,走的全是被明確放行的通道,看上去和正常執行沒有任何區別。有安全研究者在評價 Google 的 GKE Agent Sandbox 時指出:這是「隔離沙箱」,而非「行為沙箱」,它決定 Agent 在哪裡執行,卻看不住它執行時具體做了什麼。
正因為沙箱只能管住 Agent 在哪裡執行、管不住它拿資料做什麼,Google DeepMind 提出了一個更徹底的思路:從設計上就把大模型當作一個不可信的部件,在它外面加一層固定的、不依賴 AI 判斷的系統,來決定它每一步能不能執行。他們的 CaMeL 把使用者可信的指令先編譯成一段程式,交給一個不含 AI 的直譯器執行;這個直譯器會追蹤每一份資料的來源,在每次呼叫工具之前,按權限規則決定是否放行;而真正接觸外部可疑內容的那個模型,完全沒有呼叫工具的權力。這套辦法,能在相當一部分任務上做到「可證明的安全」。
沙箱之外的難題:Agent 執行必需的敏感資料
不過,無論是沙箱還是 CaMeL,都繞不開一個更難的問題,這也是整件事裡最難處理的一個環節。
沙箱把 Agent 和主機隔離開了,卻沒有在 Agent 工作必需的資料周圍建立防護。程式碼、.env、它要查詢的那個資料庫,都和它處在同一個環境裡;而 Agent 要工作,就總得有一個對外的出口。於是一個被注入的 Agent,照樣能順著這個放行的出口,把它能讀到的資料傳出去。這一點 Anthropic 自己的沙箱文件也承認:只要允許網路出口,Agent 能讀到的資料就有可能被帶走,因為白名單只按網域放行,並不檢查流出的內容。
那麼,這些 Agent 工作離不開的資料,又該如何保護?可以分成三種情況,一種比一種棘手。
第一種,是明確的憑證,比如一個 API 金鑰。Agent 並不需要理解這個金鑰的內容,只是用它來發請求。那就可以讓模型自始至終只看到一個佔位符,等真正要發請求時,再由外面一層受管的執行環境把真金鑰替換進去。就算有人用提示詞把「金鑰」誘導出來,拿到的也是一個無效的假值。這一類,在工程上基本可以解決。
第二種,是 Agent 必須親自讀取、分析的資料。一個做財務分析的 Agent,如果不給它財務資料,它就無法工作。這種情況就沒法簡單替換了。一個折衷的辦法,是單獨執行一個高度隔離的子 Agent,只讓它接觸敏感資料,最後只把一個結論傳出來。可這裡有一個繞不過去的問題:誰也無法保證這個結論本身不敏感。洩密往往是經過改寫、藏在語意裡的,用關鍵字根本比對不到。隔離能縮小出事的範圍,卻無法真正杜絕。
第三種,是更徹底的辦法,叫資訊流追蹤:給每一份資料打上標籤,全程追蹤它流向哪裡,在它要流出去的那一刻攔截下來。微軟的 Fides 走的就是這條路,用資訊流控制追蹤每一份資料的流向,原理上最乾淨。可它的代價也最大:拖慢效能、影響可用性、標籤越來越多,還需要有人去撰寫和維護這些規則。在安全和可用性之間,這裡的取捨最難。
AI Agent 安全的系統工程:隔離、管控與溯源
這些辦法各有短板,沒有哪一種能單獨解決問題:護欄會被繞過,沙箱擋不住資料,資訊流追蹤代價過高,子 Agent 隔離也無法保證結論不敏感。
但安全這門學科歷來如此:沒有絕對的「安全」或「不安全」,能做的是不斷抬高攻擊成本、縮小事故的影響範圍。
所以,對於真正想把 Agent 做成企業級產品(ToB)的團隊,並不存在一勞永逸的萬能辦法。可行的做法,是把三件事結合起來。第一是隔離:用系統層的沙箱和外部約束,嚴格限定 Agent 能做什麼。第二是策略管控:用最小權限和固定的規則,約束它在這個範圍內具體能存取什麼。第三是責任溯源:用日誌和可追蹤機制,保證一旦真的出事,能查清是哪一步、哪一方的問題。
前兩件是事前預防,第三件常被忽略,卻同樣重要。護欄防的是別讓壞事發生,日誌保證的是一旦發生能查清楚,兩者誰也替代不了誰。現實中有一個明顯的落差:很多公司都報告過疑似或確認的 Agent 安全事件,但真正把 Agent 當作一個需要單獨授權、單獨擔責的「身分」來管理的,還很少。這個空白,正是今天 Agent 安全最現實的短板。
AI Agent 正在從「能回答問題」走向「能替人做事」。Agent 越自主,使用者要託付給它的就越多:決定權、資料,還有各種密碼和憑證。只指望模型自己學會克制,或者給它多寫幾百條護欄規則,這些辦法都停留在模型內部,和模型處在同一個層級,擋不住前面說的那些問題。企業要讓 Agent 真正可用,就必須把防線建在模型之外:先用沙箱限定它能操作的範圍,再用最小權限約束它在範圍內能存取的資料,同時把每一步都記入日誌,一旦出事能追溯到源頭。這三層結合在一起,才稱得上一個企業可用的 Agent 安全方案。