agent-permissions

A mechanism that lets a user (or the system itself) immediately halt all of a <a href="/en/glossary/defai-fundamentals/defai/">DeFAI</a> agent's automated actions — typically a final layer of manual intervention retained outside the normal permission scope, used to respond to abnormal agent behavior or emergency market conditions.

Authorizing an agent fundamentally involves two completely opposite design philosophies: an allowlist defaults to nothing is permitted, with only explicitly listed actions allowed to execute; a denylist defaults to everything is permitted, with only explicitly listed actions forbidden. These two designs produce completely opposite outcomes when facing a new scenario never considered before — a foundational design choice that determines an authorization system's actual security boundary.

The situation where an agent's authorization to two or more independent protocols each looks reasonable on its own, but because these protocols are composable underneath, an interaction you never anticipated exists between them — combined together, these authorizations can achieve an effect far beyond what you originally expected when authorizing any single protocol alone. A permission risk that stems from the compositional nature of the DeFi ecosystem itself, not a design flaw in any one link.

When an agent a user has authorized further re-delegates part of its authority to other agents or sub-systems, a permission-design flaw at any single link in that entire delegation chain can leave the actual final scope of authority far broader than what the user originally understood and agreed to — this risk arising from multi-layer re-delegation is called <a href="/en/glossary/agent-permissions/delegation-chain-risk/">Delegation Chain Risk</a>.

When authorizing an agent to execute an operation, two fundamentally different architectural choices exist: single-agent authorization lets one agent independently hold complete authority to sign a transaction, with any operation executing once that one agent alone agrees; multisig authorization requires a certain threshold number of multiple independent agents (or a combination of agents and humans) to all agree before an operation executes. The two architectures have a fundamentally different actual consequence when a single link goes wrong.

When an agent delegates part of its own authorized permission further down to a <a href="https://aiagent-bible.com/en/glossary/multi-agent/subagent/" target="_blank" rel="noopener">Sub-agent</a> to execute a specific task, the <a href="https://claudecowork-me.com/en/glossary/plugin-workflows/sub-agent/" target="_blank" rel="noopener">Sub-Agent</a>'s actual permission scope should theoretically be a subset of the original authorization — but the actual inheritance mechanism design determines whether the sub-agent could end up with permission exceeding the parent agent's original authorized scope. Every layer of a <a href="/en/glossary/agent-permissions/permission-inheritance-chain/">Permission Inheritance Chain</a> is a component where scope expansion or a vulnerability could show up — the longer the chain, the more components that need careful checking.

The time elapsed between a user triggering an instruction to revoke an agent's authorization (revoking a <a href="/en/glossary/agent-permissions/session-key/">Session Key</a>, for example) and that revocation actually taking effect on-chain, with the agent completely losing its ability to sign — during this window, the agent can theoretically still submit and complete transactions. A concrete time variable often overlooked when assessing how reliable a kill switch mechanism actually is.

A temporary, scope-limited signing key a user grants to an agent, restricted to a preset permission boundary and usually time-limited — used in place of handing over the main wallet's <a href="https://crypto-bible.com/en/glossary/wallet-and-security/private-key/" target="_blank" rel="noopener">Private Key</a> directly.