Delegation Chain Risk

委任鏈風險是什麼，跟前面談過的單層授權風險有什麼不同？

本系列前面討論 會話金鑰 時，情境通常是「使用者 → 一個 Agent」這種單一層級的授權關係，評估重點是這一層的白名單、金額上限、有效期限設計得夠不夠嚴謹。委任鏈風險談的是更複雜的情況：如果這個 Agent 本身又基於 Agent 間結算 或任務委外的需求，把使用者原本授權給它的一部分權限，再轉授權給第二個 Agent（甚至第二個 Agent 又再轉授權給第三個），整條鏈上每一層轉授權，理論上都應該讓權限範圍逐層限縮（子 Agent 拿到的權限應該只是母 Agent 權限的一個子集），但實務上這個「逐層限縮」不會自動發生，需要每一層的技術實作都認真把關。

差異的核心在於：單層授權風險，你只需要評估一個環節；委任鏈風險裡，你面對的是一整條鏈，鏈上任何一環出現「權限沒有被正確限縮、甚至被意外放大」的設計缺陷，都會讓你最初以為的授權範圍名不符實。

委任鏈風險為什麼會發生，技術上哪些環節容易出錯？

最常見的問題出在「權限傳遞」的實作邏輯上。理論上，母 Agent 轉授權給子 Agent 時，應該精確地把自己被允許做的事情裡的一個子集傳給對方（例如母 Agent 能動用 100 元，只轉授權給子 Agent 動用其中 20 元的權限），但如果開發時的實作邏輯有疏漏，可能出現子 Agent 實際拿到的權限範圍等同於、甚至超過母 Agent 自己擁有的範圍——這聽起來不合邏輯，但在複雜的多層系統裡，權限檢查如果沒有在每一層都重新驗證，而是預設「上一層已經檢查過了」，就可能出現這種權限意外放大的漏洞。

另一個常見問題是「權限範圍在轉授權過程中變得模糊」——母 Agent 對子 Agent 的委任說明可能寫得不夠精確（例如籠統寫「協助處理跨鏈相關操作」而不是列出具體能互動的合約清單），這種模糊的委任描述，如果子 Agent 的實作直接把它解讀成「跨鏈相關的所有操作都可以做」，範圍就在轉授權過程中被不當放大了。

委任鏈風險實際上要怎麼評估，一般用戶有沒有辦法查證這整條鏈？

完整查證整條委任鏈的技術細節，對一般使用者來說門檻確實偏高，但有幾個間接的判斷方法可以參考：第一，直接詢問平台方或查閱技術文件，確認這個 Agent 是否有轉授權給其他 Agent 的能力，如果有，是否公開揭露了轉授權時的權限限縮邏輯（例如子 Agent 的權限是否保證只會是母 Agent 權限的子集，而不會相等或更大）；第二，查詢這個平台的智能合約是否有經過涵蓋「多層授權情境」的專門審計，而不是只審計「使用者對單一 Agent」這種最基本的情境；第三，如果平台方能提供實際的委任鏈視覺化工具（例如顯示這筆資金理論上可能流經哪些 Agent），這種透明度本身就是一個值得加分的訊號。

如果以上這些資訊都查不到，比較務實的做法是把「這個產品是否具備轉授權能力」本身當成一個需要額外提高警覺的因子，即使你無法逐一驗證每一層的技術細節，至少要知道自己的資金風險敞口，可能比表面上的「使用者對單一 Agent」授權關係更複雜。

委任鏈風險對一般用戶有什麼實際影響，該怎麼在部位規劃上納入這個考量？

如果你授權的 Agent 具備多層轉授權能力，代表你實際承擔的風險，不只取決於你直接評估、也相對熟悉的這一個 Agent，還額外取決於一整條你可能完全不了解、甚至平台方自己都沒有主動揭露的下游 Agent 鏈。這種風險的特性是「不透明」——你很難像評估單一 Agent 那樣，透過查看歷史交易紀錄、團隊背景等方式去個別評估委任鏈上的每一個環節。

實際的因應方式，除了前面提到的查證方法，更根本的態度調整是：面對具備複雜委任鏈能力的產品，你的部位規劃應該比面對單層授權的產品更保守，因為你能實際掌握與驗證的風險資訊比例更低。這跟本系列反覆強調的原則一致——資訊越不透明、你能自行驗證的環節越少，越應該把投入金額控制在「即使完全損失也能接受」的範圍內，而不是因為表面上看起來只有一層授權關係，就低估了實際的風險敞口。