智能體安全從一條規則開始：你的智能體絕不能持有你的憑證。這裡介紹38年歷史的 broker 模式來實現這一點。
智能體是混淆代理人。這是一個38年歷史的安全模式，答案同樣古老：在智能體與它需要呼叫的 SaaS API 之間，設置一個broker——一個可信、可觀察、可預測、可稽核、不可偽造、範圍受限、政策驅動、非 AI 的中介層——來持有你的智能體不該擁有的憑證。
在1988年，Norm Hardy 發表了一篇短文，描述了他在 Tymshare 時期遇到的一個真實事件。一個名為 FORT 的 Fortran 編譯器存放在名為 SYSX 的系統目錄下。為了收集使用統計，編譯器需要寫入(SYSX)STAT，因此作業系統授予 FORT「home files license」，允許它寫入 SYSX 內的任何檔案。系統的計費檔案(SYSX)BILL也在那裡。用戶在調用編譯器時可以指定一個檔名來接收可選的除錯輸出。有一天，一位用戶輸入了(SYSX)BILL。編譯器請求作業系統開啟該檔案進行寫入；作業系統根據 home files license 允許了這個操作。計費資料被覆蓋。編譯器完全按照設計運作。問題出在架構上。
Hardy 將其命名為混淆代理人問題：一個有特權的程式（代理人）擁有自己的權限；權限較低的呼叫者請它執行某事；代理人混淆了自己行使的是誰的權限，結果用的是自己的。解決方法是將權限完全從代理人手中移除，放到一個獨立的中介層，由它按需調用。這個中介層就是 broker。
三十八年後，你公司運行的每個智能體都是混淆代理人。而且大多數都沒有 broker 保護。
為什麼智能體讓安全問題更嚴重
Hardy 的 FORT 只有一個輸入通道：命令列。現代智能體有數十個：電子郵件內容、擷取的網頁、上傳的 PDF、MCP 伺服器的工具輸出、多智能體系統中其他智能體的訊息。任何進入 context window 的內容都能發出指令，而智能體設計上會將它們都視為合法。
這打破了傳統存取控制所依賴的一個假設：呼叫者控制輸入。在網頁應用中，呼叫者（已驗證的 session）和輸入（HTTP 請求內容）來自同一來源。對智能體而言，呼叫者是塑造提示詞的人，這意味著能寫郵件或操控搜尋結果的攻擊者也是呼叫者。
在2025年十一月，PromptArmor 的安全研究人員展示了這種情況在生產環境中的樣貌。他們在整合指南中用1像素字體隱藏了惡意指令。當開發者將 Google 的 Antigravity IDE 指向該頁時，智能體透過 shell 執行繞過了自身基於.gitignore的檔案保護，使用了cat。然後，它將.env檔案內容透過 Antigravity 的瀏覽器子智能體洩漏到攻擊者控制的webhook.site URL。用戶設置正確，沙盒也發揮作用，但智能體根本無法分辨用戶的請求和輸入的指令。
這與 Hardy 的 FORT 問題如出一轍：權限過大、輸入不可信、無法區分兩者。
社群早有答案，只是分散各處
這不是新問題。安全社群數十年來一直在提出解決方案：
能力導向安全（Dennis & Van Horn, 1966；後來的 E 語言和 Mark Miller 在 Google 的 Caja 工作）。原則是：不要根據身份或位置授予廣泛權限；而是針對每個程式可操作的資源，傳遞明確且不可偽造的能力。能力同時綁定「你能做什麼」和「你能對什麼做」，且無法被混淆。
Brokered Credentials（由 OWASP LLM Top 10 規範）。不要把 API 權杖放進 LLM 的 context。可信的中介層代表智能體發出請求；模型決定「做什麼」，broker 處理「怎麼做」。如果提示注入要求模型輸出憑證，什麼也拿不到，因為憑證根本不在那裡。
Phantom Token Pattern（Curity，最初用於微服務中的 OAuth）。智能體只持有一個不透明的 session handle，而不是實際的 bearer token。代理會驗證 handle，並在網路邊緣替換成真憑證再轉發。如果智能體洩漏其環境，攻擊者拿到的只是一個 session 結束就失效的字串。
即時憑證注入（如 Aembit 等 workload identity 系統）。每次呼叫都產生短效、範圍受限的憑證，而不是發放長效權杖。
這些方案在文獻中都不缺，只是預設值裡沒有。大多數智能體平台仍然直接把 OAuth 權杖交給模型，沒有 broker 層，只能祈禱沒事。
Zero 的 broker 如何運作
我們沒有發明上述任何模式。我們只是把它們整合進一個broker，預設為 Zero 上每個智能體運行。這就是那些模式描述的可信中介層，專為智能體平台打造。每次智能體對連接器的呼叫都經過它。每個連接器對應一個外部 SaaS（如 Slack、GitHub、Notion 等）。
broker 介於每個智能體與每個連接器之間。真憑證只存在於虛線的 broker 端。
你可以將其想像成三層。
1. 憑證隔離
智能體的沙盒永遠不會持有真實的連接器憑證。當你將 SaaS 連接到 Zero 時，OAuth 權杖或 API 金鑰只存放在 broker 端。沙盒只拿到一個佔位字串，它看起來像環境變數，方便現有工具繼續運作，但任何上游 SaaS 都不會接受它。
當智能體向已註冊的連接器主機發出請求時，broker 會比對請求、解析連接器的認證模板，並在網路邊緣注入真憑證。請求帶著有效認證發送到上游，智能體從未持有過任何有用資訊。即使提示注入導致智能體輸出環境變數，攻擊者拿到的也只是佔位符，不是 SaaS 權杖。
這就是 phantom token pattern 在智能體上的應用。
2. 連接器政策閘門
Zero 裡的連接器不該只是開關。每個連接器都描述它涵蓋的 API 基址及認證注入方式。若上游服務有穩定的 scope-to-endpoint 對應，也能描述每個方法和路徑對應的權限名稱。Slack 的 slack-api-ref 就是好例子。
所以當連接到 Slack 的智能體呼叫chat.postMessage時，broker 能將該請求對應到chat:write。讀取稽核日誌時，則對應admin.analytics:read。對每個智能體，permission_policies 定義這些權限名稱的行為：允許、拒絕或詢問。政策在 broker 層於認證注入前強制執行，而不是僅作為模型的提示。如果智能體嘗試呼叫被拒權限覆蓋的 API（可能因提示注入），該請求根本不會到達上游網路。
不是每個連接器今天都能做到這種解析。有些上游 API 沒有公開穩定的 scope-to-endpoint 對應。GitHub 的 GraphQL 就是典型例子：REST 端可以對應，GraphQL 端目前還不行。對這些連接器，broker 仍然控制憑證注入和網路路徑，權限閘門則退回到平台可強制的較粗粒度連接器或主機層政策。隨著上游資料補齊，我們會逐步完善。我們不會宣稱尚未實現的覆蓋範圍。
權杖不再帶有廣泛權限。權限根據智能體、依上游支援的解析度進行 broker 管理。這就是能力導向安全的一半答案。
3. 運作循環與稽核
最小權限原則只有在失敗模式可用時才有效。智能體會成長。六週後，一個原本只讀 Notion 的研究型智能體可能需要寫回摘要。常見的失敗模式是：智能體在沒有新權限時默默失敗，或操作員慌張下過度授權，之後再也沒收回。
被拒的連接器請求會返回結構化403：連接器、方法、路徑、基礎 URL，以及 broker 能識別時的權限名稱。智能體的系統提示會告訴它如何診斷拒絕原因，以及如何請求剛才碰到的那個權限，產生一個用戶或管理員一鍵授權的 URL。這讓權限升級路徑只針對實際請求的權限，而不會變成「全部授權」。
權限變更請求會進入佇列。擁有者和管理員可在儀表板審核，通過後即更新智能體政策，下次重試就能成功。大多數平台都跳過這個循環。沒有它，「最小權限」只停留在簡報上，無法落地。
同一 broker 路徑也供稽核使用。每次執行的網路日誌會記錄沙盒的 HTTP、TCP、DNS 及非 TCP 封包活動。連接器匹配的請求會包含結構化 broker metadata：連接器、可用時的權限名稱、允許/拒絕結果、認證解析資訊及計費標記。若有人問「這個智能體週二下午三點做了什麼？」，你可以從這些紀錄重建答案。預防措施總有遺漏，稽核紀錄才是事後追查的依據。
我們尚未解決的問題
即使有上述所有措施，擁有合法chat:write的智能體仍可能被說服在已有權限的頻道發送尷尬訊息。broker 只縮小影響範圍，無法完全消除風險。
另一半答案是高風險操作審批、輸出驗證，以及預設將工具回傳視為不可信。這些功能已在規劃中，尚未上線。任何聲稱已徹底解決混淆代理人問題的廠商都在賣你產品。
這應該是基本標配，而非特色功能
能力導向安全自 1970 年代就存在。Brokered credentials 已列入 OWASP LLM Top 10。Phantom token 早於 LLM 時代。這些方案不是因為沒人知道才缺席，而是早期智能體平台為了「讓 demo 能跑」而把安全推遲到後面，結果往往永遠沒補上。
下一代平台應該設更高標準。權杖不該進入模型 context。權限應逐智能體列舉。權限升級應經人工審批。每個動作都應全程可稽核。這些都不是新鮮事，卻應該成為最低標準。
當你選擇智能體平台時，問「安全嗎？」毫無意義，每家廠商都會說安全。更好的問題是：請給我看你的 broker，並說明當智能體請求未授權範圍時會發生什麼。
broker 預設保護 Zero 上的每個智能體。連接器清單、範圍對應、權限政策和 broker 邏輯都在 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：網頁能力導向安全，Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
引用的實際事件
- PromptArmor, Google Antigravity Exfiltrates Data, 2025年十一月
- Simon Willison, 相關報導與分析, 2025年11月25日
