AI 代理程式的安全從一條規則開始：你的 AI 代理程式絕不應持有你的憑證。以下是強制執行這條規則、已有 38 年歷史的中介層模式。
AI 代理程式是「糊塗的副手」。這是一個有 38 年歷史的安全模式，而解決方案同樣古老：在代理程式與它需要呼叫的 SaaS API 之間，放置一個中介層——一個可信任、可觀測、具確定性、可稽核、不可偽造、範圍受限、由策略驅動、非 AI 的中間層——由它持有代理程式不應擁有的憑證。
1988 年，Norm Hardy 發表了一篇短文，描述了他在 Tymshare 任職期間的一個真實事件。一個名為 FORT 的 Fortran 編譯器，存放在名為 SYSX 的系統目錄中。為了收集使用統計資料，編譯器需要寫入 (SYSX)STAT，因此作業系統授予了 FORT「主目錄檔案授權」，允許它寫入 SYSX 內的任何檔案。系統的帳單檔案 (SYSX)BILL 也存放在那裡。使用者呼叫編譯器時，可以提供一個檔案名稱來接收選用的除錯輸出。某天，一位使用者提供了 (SYSX)BILL。編譯器要求作業系統開啟該檔案進行寫入；作業系統看到主目錄檔案授權，便允許了。帳單資料因此遭到覆寫。編譯器做的正是它被設計來做的事，問題出在架構上。
Hardy 將此命名為糊塗的副手問題：一個擁有特權的程式（副手）持有自身的授權；一個權限較低的呼叫者要求它執行某項操作；副手搞不清楚自己是在代表誰行使授權，結果動用了自己的授權。解決方法是將授權完全從副手身上移除，放到一個獨立的層級後面，由該層級按需仲介呼叫。這個層級就是中介層。
三十八年後，你的公司運行的每一個 AI 代理程式都是一個糊塗的副手。而其中大多數都在沒有中介層的情況下運行。
為什麼 AI 代理程式讓安全問題更加嚴峻
Hardy 的 FORT 只有一個輸入管道：命令列。現代 AI 代理程式則有數十個：電子郵件內容、擷取的網頁、上傳的 PDF、來自 MCP 伺服器的工具輸出、多代理系統中其他代理程式的訊息。任何進入上下文視窗的內容都可以發出指令，而且代理程式在設計上會將它們全部視為合法指令。
這打破了傳統存取控制所依賴的一個假設：呼叫者控制輸入。在 Web 應用程式中，呼叫者（已驗證的工作階段）和輸入（HTTP 請求主體）來自同一個地方。對於代理程式而言，呼叫者是塑造提示詞的任何人，這意味著能夠撰寫電子郵件或植入搜尋結果的攻擊者，同樣也是呼叫者。
2025 年 11 月，PromptArmor 的安全研究人員展示了這在實際環境中的樣貌。他們將惡意指令以 1 像素字體隱藏在一份整合指南中。當開發者將 Google 的 Antigravity IDE 指向該文件時，代理程式透過呼叫 cat 繞過了自身基於 .gitignore 的檔案保護機制，接著透過 Antigravity 自己的瀏覽器子代理程式，將 .env 檔案的內容洩漏至攻擊者控制的 webhook.site URL。使用者的設定完全正確，沙箱也正常運作，但代理程式根本無法區分使用者的請求與輸入指示它執行的操作。
與 Hardy 的 FORT 如出一轍，數十年後依然：廣泛的授權、不可信任的輸入、無法將兩者分離。
社群已有解答，只是分散各處
這並非新問題。安全社群數十年來一直在撰寫解決方案：
基於能力的安全性（Dennis & Van Horn，1966 年；後來的 E 語言以及 Mark Miller 在 Google 的 Caja 研究）。核心原則：不要基於身份或位置授予環境授權；為程式被允許存取的每個資源傳遞明確、不可偽造的能力憑證。能力憑證將你能做什麼與你能對什麼執行操作綁定在一起，且不會與其他任何事物混淆。
中介層憑證（由 OWASP LLM Top 10 明文規定）。不要將 API Token 放入 LLM 的上下文中。由可信任的中間層代表代理程式發出呼叫；模型決定做什麼，中介層處理如何做。試圖讓模型印出其憑證的提示詞注入攻擊將一無所獲，因為憑證根本不在那裡。
幽靈 Token 模式（Curity，最初用於微服務中的 OAuth）。代理程式持有一個不透明的工作階段識別碼，而非真正的 Bearer Token。代理伺服器驗證識別碼，在網路邊緣換入真實憑證，再轉發至上游。即使代理程式洩漏了其環境變數，攻擊者得到的也只是一個在工作階段結束時就會過期的字串。
即時憑證注入（工作負載身份系統，如 Aembit）。每次呼叫時鑄造一個短期、範圍受限的憑證，而非發放長期 Token。
這些內容在文獻中並不缺乏，缺乏的是預設實作。大多數代理程式平台仍然直接將 OAuth Token 交給模型，中間沒有任何中介層，只是抱著僥倖心態。
Zero 的中介層如何運作
我們並未發明上述任何模式，而是將它們整合進一個單一的中介層中，並在 Zero 上為每個代理程式預設啟用。這正是那些模式所描述的可信任中間層，專為 AI 代理程式平台而建。代理程式對連接器發出的每一個呼叫都會經過它。每個連接器對應一個外部 SaaS（Slack、GitHub、Notion 等）。
中介層位於每個代理程式與每個連接器之間。真實憑證僅存在於虛線的中介層側。
可以將其視為三個層級。
1. 憑證隔離
代理程式的沙箱從不持有真實的連接器憑證。當你將 SaaS 連接至 Zero 時，OAuth Token 或 API 金鑰存放在中介層側。沙箱獲得的是一個佔位符字串，其外觀足以讓現有工具繼續正常運作，但任何上游 SaaS 都不會接受它。
當代理程式向已註冊的連接器主機發出請求時，中介層會比對請求、解析連接器的驗證範本，並在網路邊緣注入真實憑證。請求帶著有效的驗證資訊發送至上游；代理程式從未持有任何有用的東西。遭到提示詞注入的代理程式即使傾印其環境變數，攻擊者得到的也只是佔位符，而非 SaaS Token。
這就是幽靈 Token 模式，應用於 AI 代理程式。
2. 連接器策略閘道
Zero 中的連接器應該不只是一個開關。每個連接器描述其涵蓋的 API 基礎路徑，以及驗證應如何注入。若上游服務發布了穩定的範圍對端點映射，它還可以描述哪個具名權限涵蓋每個方法和路徑。Slack 的 slack-api-ref 就是一個很好的例子。
因此，當連接至 Slack 的代理程式呼叫 chat.postMessage 時，中介層可以將該請求映射至 chat:write。當它讀取稽核日誌時，對應的是 admin.analytics:read。對於每個代理程式，permission_policies 定義了這些具名權限的行為：允許、拒絕或詢問。策略在驗證注入之前由中介層強制執行，而非作為給模型的提示。如果代理程式嘗試發出被拒絕權限所涵蓋的呼叫（可能是因為遭到提示詞注入），該呼叫永遠不會到達上游網路。
並非每個連接器今天都能達到這種解析精度。部分上游 API 並未發布穩定的範圍對端點映射。GitHub 的 GraphQL 介面就是典型案例：REST 側可以映射，但 GraphQL 側目前尚無法。對於這些連接器，中介層仍然控制憑證注入和網路路徑，而權限閘道則退回至平台實際上能夠執行的、更粗粒度的連接器或主機層級策略。我們會隨著上游資料的完善持續補充，不會聲稱尚未建立的覆蓋範圍。
Token 不攜帶環境授權。授權由中介層按代理程式逐一仲介，精細度取決於上游所支援的程度。這就是解決方案中基於能力的那一半。
3. 操作迴圈與稽核
最小權限只有在失敗模式可用的情況下才能發揮作用。代理程式會成長。六週後，一個最初只從 Notion 讀取資料的研究代理程式，可能需要將摘要寫回去。其他地方常見的失敗模式是：代理程式在沒有新權限的情況下靜默運行並中斷，或者操作者在慌亂中過度授權，之後再也沒有收回。
被拒絕的連接器請求會返回一個結構化的 403 錯誤：連接器、方法、路徑、基礎 URL，以及中介層能夠識別時的對應權限名稱。代理程式的系統提示詞告訴它如何診斷拒絕原因，以及如何精確請求它剛剛觸及的權限，為使用者或管理員產生一個一鍵授權 URL。這樣可以確保權限升級路徑與被請求的確切權限綁定，而不會演變成「直接授予所有權限」。
權限變更請求會進入佇列。擁有者和管理員可以從儀表板批准或拒絕；批准的請求會更新代理程式的策略，下次重試即可通過。大多數平台跳過了這個迴圈。沒有它，「最小權限」就只會停留在簡報投影片上，而不會在生產環境中實際運行。
同樣的中介層路徑也提供稽核資料。每次執行的網路日誌記錄沙箱的網路活動，涵蓋 HTTP、TCP、DNS，以及針對非 TCP 流量的較低層級封包觀測。連接器匹配的請求包含結構化的中介層元資料：連接器、可用時的匹配權限、允許/拒絕結果、驗證解析元資料，以及計費標記。如果日後有人問「這個代理程式在週二下午 3 點做了什麼？」，你可以從這些記錄中重建答案。預防措施會有遺漏，稽核軌跡是你發現問題的方式。
我們尚未解決的問題
即使有了上述所有措施，一個擁有合法 chat:write 權限的代理程式，仍然可能被誘導向它已有存取權限的頻道發布令人難堪的訊息。中介層縮小了影響範圍，但並未消除它。
解決方案的另一半是高風險操作審批、輸出驗證，以及預設將工具返回值視為不可信任。這些工作在路線圖上，尚未進入產品。任何聲稱已端對端解決糊塗副手問題的人，都是在向你推銷某樣東西。
這應該是基準，而非特色功能
基於能力的安全性自 1970 年代就已存在。中介層憑證已列入 OWASP LLM Top 10。幽靈 Token 早於 LLM 時代。這些內容的缺失，並非因為沒有人知道答案，而是因為早期的代理程式平台以「讓 Demo 能跑」為優先，將安全性推遲到後續版本，而那個版本往往從未到來。
下一代平台應該追求更高的標準。Token 不應進入模型上下文。授權應按代理程式逐一列舉。權限升級應經過人工審核。每個操作都應可端對端稽核。這些都不是新穎的概念，全部都應該是基準。
在選擇代理程式平台時，問「它安全嗎？」毫無意義，每個廠商都說「是」。更好的問題是：讓我看看你的中介層，並帶我了解當代理程式請求一個它沒有的範圍時會發生什麼。
中介層預設位於 Zero 上每個代理程式的前端。連接器清單、範圍映射、權限策略和中介層邏輯全部存放在 Zero 的原始碼儲存庫 中。發現我們尚未涵蓋的連接器？請提交 Issue。
參考資料
基礎文獻
- Norm Hardy，The Confused Deputy: (or why capabilities might have been invented)，ACM SIGOPS Operating Systems Review 22(4)，1988 年。DOI 10.1145/54289.871709
- Dennis & Van Horn，Programming Semantics for Multiprogrammed Computations，CACM 1966 年（能力系統的奠基論文）
- Mark Miller 等人，Caja：Web 的基於能力安全性，Google
- OWASP LLM Top 10
- Curity，幽靈 Token 模式
引用的真實事件
- PromptArmor，Google Antigravity Exfiltrates Data，2025 年 11 月
- Simon Willison，報導與分析，2025 年 11 月 25 日
