Composability Privilege Escalation

What is composability privilege escalation, and how does it differ from the delegation chain risk discussed earlier in this series?

When this series broke down delegation chain risk earlier, it addressed the same agent re-delegating authority downward to other agents, forming a vertical authorization chain, with risk coming from whether authority got properly narrowed during re-delegation. Composability privilege escalation addresses a completely different horizontal relationship: your agent separately requests independent authorization from Protocol A and Protocol B — each authorization looks reasonable on its own (both within your set spending cap, say), but because Protocol A and Protocol B are underneath composable with each other (exactly the DeFi ecosystem's core "snap together like Lego bricks" characteristic), your agent could exploit the combination of these two authorizations to achieve a compound action you never individually evaluated or expected to happen at all.

This means the risk doesn't come from any single protocol's authorization design being insufficiently rigorous — it comes from never having thought to examine what new possibilities emerge when these two independent, seemingly unrelated authorizations come together at all.

Why does composability privilege escalation exist — is this an inevitable cost of the DeFi ecosystem?

The DeFi ecosystem was originally designed to be highly composable so developers could freely snap different protocols' functions together like Lego bricks, creating complex financial applications no single protocol could achieve alone — this composability is exactly one of DeFi's most important innovative advantages over traditional finance. But the flip side of this advantage is that a user's risk-assessment mindset originally designed around a single protocol can completely fail to hold up in a scenario where multiple protocols are used in combination — you might have carefully assessed Protocol A's risk and carefully assessed Protocol B's risk, but never thought to assess what new risk emerges from using A and B together.

This isn't entirely a technical flaw that can be fixed — it's more like structural complexity inherent to the composability characteristic itself. The more protocols there are and the more ways they can be combined with each other, the more unexpected interactions can theoretically emerge — this complexity will keep growing as the DeFi ecosystem continues developing, not something a single protocol's or a single agent's design can fully solve.

コンポーザビリティによる権限昇格は実際どのように起こり、それを説明する具体的なシナリオはありますか？

簡略化された説明用のシナリオを挙げると：あなたはエージェントに、プロトコルA（貸出プロトコル）内で、あなたの担保に対して同等価値の70%まで別の資産を借り出す権限を承認する——この承認は単独で見れば合理的で、一般的な貸出プロトコルの通常の安全比率に合致している。あなたは別途、エージェントにプロトコルB（レバレッジ取引プロトコル）内で、手元の資産に対して最大3倍のレバレッジ取引を行う権限も承認する——この承認も単独で見れば合理的な範囲内である。しかしプロトコルAから借り出された資産が、シームレスに直接プロトコルBに預け入れられてさらにレバレッジをかけられる場合、あなたのエージェントは理論上、「まずAで資産を借り出し、その借り出した資産をBに預け入れてレバレッジをかける」という組み合わせ動作を通じて、あなたが元々設定したどの単独の上限をもはるかに超える実際のエクスポージャー倍率を達成できてしまう。

この種の組み合わせは、エージェント開発チーム自身も予想していなかった可能性がある（プロトコルAとプロトコルBは通常全く別々のチームによって開発されており、互いに相手のプロトコルロジックを特に研究することはないため）。ユーザーであるあなたにとっては、この種のクロスプロトコルの組み合わせ効果を事前に確認しようと考えることはさらに難しい。

コンポーザビリティによる権限昇格は一般ユーザーにどのような実際の影響を与えますか？評価とポジション計画にどう応用すればいいですか？

あなたのエージェントが複数のプロトコルに同時に承認を持っている場合、あなたが実際に負っているエクスポージャーの上限は、個別に設定した各プロトコルの金額上限の合計と等しくない可能性があり、代わりにこれらのプロトコルが互いに組み合わさった後に理論上達成できる最大の効果に依存する。この数字は通常、直感的に足し合わせる数字よりもはるかに見積もりにくく、事前に完全に検証しにくい。マルチプロトコルの相互作用が可能などのDeFAIエージェントを評価する際も、このチームに直接尋ねる価値がある：各プロトコルの個別のリスクを評価するだけでなく、「複数プロトコルを組み合わせて使用する」というシナリオに対して専門のリスク評価やストレステストを行ったことがあるかどうかである。

実際に応用する際は、より実践的な心構えは、エージェントが複数の組み合わせ可能なプロトコルに同時に承認を持っていること自体を、追加の、正確に定量化しにくいリスク増幅要因として扱うことである。ポジション計画の際は、各プロトコルの個別のリスクを評価して合計した数字よりも、投入総額をやや保守的に設定する方がよく、この追加の余裕をもって、事前に完全には予測できない組み合わせ効果に対応する。これは本シリーズで繰り返し強調してきた原則のここでの具体的な応用でもある——透明性が低く完全には検証しにくい環節ほど、より保守的なポジションで対応すべきである。