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.
How does composability privilege escalation actually happen — is there a concrete scenario to illustrate it?
A simplified illustrative scenario: you authorize an agent to, within Protocol A (a lending protocol), borrow another asset worth up to 70% of your collateral — this authorization alone looks reasonable, matching a common safe ratio for lending protocols; separately, you also authorize the agent to, within Protocol B (a leveraged trading protocol), trade with up to 3x leverage on assets on hand — this authorization alone is also within a reasonable range. But if the asset Protocol A lends out can be seamlessly deposited directly into Protocol B for further leveraging, your agent could theoretically, through the combined action of first borrowing from A then depositing that borrowed asset into B for leverage, achieve an actual exposure multiplier far exceeding any single cap you originally set.
This kind of combination might not even be something the agent development team itself anticipated (since Protocol A and Protocol B are usually developed by completely separate teams, neither specifically studying the other's protocol logic), and it's even harder for you as a user to think in advance to check for this kind of cross-protocol combined effect.
What's the practical impact of composability privilege escalation for everyday users, and how should it apply to evaluation and position planning?
If your agent holds authorization across multiple protocols simultaneously, it means the actual exposure ceiling you're carrying might not equal the sum of each protocol's spending cap you set individually — it depends instead on the maximum theoretical effect achievable once these protocols combine with each other, a number usually much harder to estimate and fully verify in advance than what you'd intuitively add up. When evaluating any DeFAI agent capable of multi-protocol interaction, it's worth directly asking the team: has it conducted a dedicated risk assessment or stress test specifically for the multi-protocol-combined-use scenario, rather than only assessing each protocol's individual risk separately.
In practice, a more practical mindset is treating an agent holding authorization across multiple composable protocols as itself an additional, hard-to-precisely-quantify risk amplification factor — when planning your position, it's better to set your total commitment somewhat more conservatively than the number you'd get by summing each protocol's individually assessed risk, using this extra margin to account for combined effects you couldn't fully anticipate in advance. This is also a concrete application of a principle emphasized repeatedly throughout this series — the less transparent and harder to fully verify a layer is, the more conservative your position should be.
In the traditional DeFi industry, a flash loan attack is one of the earliest and most widely known concrete cases of composability-driven risk — attackers exploit the ability to compose calls to multiple protocols within a single transaction, using a flash loan to obtain a large sum, operating across protocols within that same transaction to create a price manipulation or logic vulnerability no single protocol's designer ever anticipated, then locking in profit and repaying the loan. This kind of incident has prompted the industry to start placing greater emphasis on dedicated auditing of cross-protocol interactions.
Understanding composability privilege escalation helps users recognize that assessing each protocol's risk individually doesn't equal assessing overall risk, filling in the cross-protocol interaction dimension a single-protocol mindset easily overlooks; but this risk is fundamentally hard to fully enumerate, since the number of possible combinations can grow exponentially as protocol count increases — even an ordinary user, or a professional auditing firm, can hardly guarantee they've covered every possible combined scenario, leaving only more conservative position planning as a partial mitigation for this hard-to-fully-eliminate uncertainty.