Composability Privilege Escalation

可組合性權限提升是什麼，跟本系列前面談過的委任鏈風險有什麼不同？

本系列前面拆解 委任鏈風險 時，談的是同一個 Agent 把權限往下轉授權給其他 Agent，形成一條垂直的授權鏈，風險來自轉授權過程中權限有沒有被正確限縮。可組合性權限提升談的是完全不同的水平關係：你的 Agent 分別對協議 A 跟協議 B 各自申請了獨立的授權，這兩份授權各自看都合理（例如都在你設定的金額上限內），但因為協議 A 跟協議 B 本身在底層是可以互相組合使用的（這正是 DeFi 生態「像樂高積木一樣可以自由拼接」的核心特性），你的 Agent 可能利用這兩份授權的組合，達成一個你從未單獨評估過、也從未預期會發生的複合操作。

這代表風險不是來自任何單一協議的授權設計不夠嚴謹，而是來自你從未想過要去檢視「這兩個獨立、看似無關的授權，湊在一起會產生什麼新的可能性」這個問題本身。

為什麼可組合性權限提升會存在，這是 DeFi 生態的必然代價嗎？

DeFi 生態最初被設計成高度可組合，是為了讓開發者能像組裝樂高積木一樣，把不同協議的功能自由拼接使用，創造出單一協議無法達成的複雜金融應用，這種可組合性正是 DeFi 相較於傳統金融最重要的創新優勢之一。但這個優勢的另一面，就是使用者原本針對「單一協議」設計的風險評估思維，在面對「多個協議組合使用」的情境時可能完全失效——你可能已經仔細評估過協議 A 的風險、也仔細評估過協議 B 的風險，卻從未想過要評估「A 加 B 一起用」會產生什麼新風險。

這不完全是可以被「修好」的技術缺陷，而更像是可組合性這個特性本身帶來的結構性複雜度——協議數量越多、彼此之間能組合的方式越多，理論上能產生的意外互動也越多，這種複雜度會隨著 DeFi 生態的持續發展而持續增加，不是單一協議或單一 Agent 的設計問題能完全解決的。

可組合性權限提升實際上會怎麼發生，有沒有具體的情境可以說明？

一個簡化的示意情境是：你授權 Agent 在協議 A（一個借貸協議）裡，能把你的資產作為抵押品借出等值 70% 的另一種資產，這個授權單獨看很合理，符合一般借貸協議的常見安全比例；你另外也授權 Agent 在協議 B（一個槓桿交易協議）裡，能把手上的資產做最多 3 倍槓桿的交易，這個授權單獨看也在合理範圍。但如果協議 A 借出的資產，能直接被無縫存入協議 B 繼續加槓桿，你的 Agent 理論上可以透過「先在 A 借出資產、再把借出的資產存進 B 做槓桿」這個組合動作，達成遠超過你原本設定的任何一個單獨上限的實際曝險倍數。

這種組合方式，可能連 Agent 開發團隊自己都沒有預料到（因為協議 A 跟協議 B 通常是由完全不同的團隊各自開發，彼此不會特別去研究對方的協議邏輯），你作為使用者更是難以事先想到要去檢查這種跨協議的組合效果。

可組合性權限提升對一般用戶有什麼實際影響，該怎麼應用在評估與部位規劃上？

如果你的 Agent 同時對多個協議都有授權，這代表你實際承擔的曝險上限，可能不等於你逐一設定的每個協議金額上限加總，而是取決於這些協議彼此組合後，理論上能達成的最大效果——這個數字通常比你直覺加總出來的數字更難預估，也更難事先完整查證。評估任何具備多協議互動能力的 DeFAI Agent 時，值得直接詢問這個團隊：是否曾經針對「多協議組合使用」這個情境，做過專門的風險評估或壓力測試，而不只是分別評估每個協議各自的風險。

實際應用時，比較務實的心態是：把「Agent 同時授權多個可組合協議」本身視為一種額外的、難以精確量化的風險放大因子，在部位規劃時，寧可把總投入金額設定得比「單獨評估每個協議風險後加總」的數字更保守一些，用這種額外的緩衝空間，去因應你事先無法完整預料的組合效果。這也是本系列反覆強調的原則在這裡的具體應用——資訊越不透明、越難完整查證的環節，越應該用越保守的部位去對待。