Security Boundaries for Scoped Agent Delegation

A Research Direction Analysis

Motivation

The traditional Web3 security model assumes a human in the loop: a user reviews a transaction, clicks "sign," and a single atomic action executes on-chain. Autonomous agents shatter this assumption. A single signature—or a single compromised key—can authorize an unbounded cascade of downstream actions. The AiXBT bot hijack, which resulted in the theft of 55 ETH, is a concrete illustration: an attacker who gains control of an agent's signing authority inherits all of that agent's permissions, with no containment boundary. The fundamental research question is: how do we formally define, enforce, and verify scoped authority for autonomous agents operating in adversarial economic environments?

1. Capability Scope as a Type System

We propose modeling agent permissions through a capability calculus—a formal type system where every agent action has a type that encodes what the agent is allowed to do, on which assets, under what conditions.

Define a capability C as a tuple (Resource, Operation, Constraint):

  • Resource: the target (e.g., a specific token contract, an NFT collection, a DeFi protocol).
  • Operation: the permitted action (e.g., transfer, approve, swap, stake).
  • Constraint: bounds on the action (e.g., max value, time window, counterparty whitelist).

Capabilities compose via standard type-theoretic operations. An agent's scope is the set of capabilities it holds. Crucially, capabilities are not ambient authority—they must be explicitly granted, cannot be fabricated, and can be attenuated (narrowed) but never amplified. This mirrors the object-capability model from systems security (e.g., E language, Cap'n Proto) but applied to on-chain agent authorization.

The type system would reject at delegation time any agent configuration that requests capabilities outside its parent's scope, providing a static safety guarantee before any transaction executes.

2. Session Types for Agent-Wallet Interactions

Session types, originating from process calculi (Honda, 1993), guarantee that two communicating parties follow a predefined protocol. Each message type and ordering is specified statically; deviation is a type error.

The analogy to agent-wallet interaction is direct. An agent's interaction with a smart contract wallet can be modeled as a session:

Agent-Wallet Session:
  1. Agent requests capability attestation
  2. Wallet checks scope, returns signed capability token
  3. Agent submits action within scope
  4. Wallet validates action against capability, executes or rejects
  5. Session closes or continues with updated state

Session types ensure that an agent cannot skip step 2 and jump to step 3, cannot submit two actions when only one is authorized, and cannot hold a session open indefinitely. Multiparty session types extend this to delegation chains: if Agent A delegates to Agent B, the three-party session (User-Wallet, A, B) has a global type that all parties must respect.

This framework also naturally encodes progress guarantees—an agent cannot deadlock a wallet by holding capabilities without acting, since the session type can enforce timeouts as protocol transitions.

3. Budget Constraints as Linear Types

Spending authority is inherently consumable: once 10 ETH of a 10 ETH budget is spent, no further spending should be possible. This maps precisely to linear types, where a value must be used exactly once.

Model a budget B(amount, token) as a linear resource. When an agent spends from the budget, it consumes a portion and produces a residual:

spend : B(n, ETH) → (Transaction, B(n - k, ETH))   where k ≤ n

The linear discipline guarantees that budget cannot be duplicated (preventing double-spend of authority) and cannot be silently discarded (forcing explicit revocation or return). This is more than a runtime check—it is a structural property of the authorization system. A linear type system for budgets would make it impossible to express a program that overspends, rather than merely detecting overspending after the fact.

Affine types (use-at-most-once) may be more practical, allowing unused budget to expire without explicit consumption.

4. Cascading Prevention: Bounding Delegation Depth and Breadth

When agents can spawn sub-agents and delegate authority to them, the delegation structure forms a DAG (directed acyclic graph). Without bounds, a compromised agent at depth 1 can create thousands of sub-agents, each with a fragment of authority, making revocation and auditing intractable.

We propose three complementary mechanisms:

  • Depth bound (d): No delegation chain may exceed depth d. Enforced structurally—a capability token at depth d cannot produce child tokens.
  • Breadth bound (b): An agent at any depth may delegate to at most b sub-agents. Prevents fan-out attacks.
  • Attenuation requirement: Each delegation step must strictly narrow the capability scope. A sub-agent can never hold more authority than its parent. Combined with finite resources (linear budgets), this guarantees convergence—delegation trees are bounded in total authority regardless of topology.

These properties are enforceable on-chain via a delegation registry contract that tracks the DAG and rejects delegation transactions that violate the bounds.

5. Relation to Existing Infrastructure

EIP-7702 (set EOA code) enables externally owned accounts to temporarily adopt smart contract logic, providing a mechanism for EOAs to enforce capability checks without migrating to full smart contract wallets. An agent operating under EIP-7702 could have its signing authority mediated by in-line validation logic that checks capability scope before execution.

MetaMask Delegation Toolkit implements a practical delegation framework with caveats (enforcers) that restrict delegated authority. The toolkit's caveat system is an informal version of the capability model described above. Formalizing its semantics—proving that caveats compose correctly, that revocation is complete, that no caveat bypass exists—is a direct research opportunity.

Smart contract wallets (ERC-4337, Safe, Kernel) already support modular validation and execution logic. They are the natural enforcement layer for capability-scoped delegation: a wallet module can maintain the delegation DAG, check linear budget constraints, and enforce session protocols. The gap is between current ad-hoc permission systems and the formally grounded model proposed here.

6. Formal Verification Opportunities

A well-typed delegation DAG admits formal verification:

  • Safety: "No agent can execute an action outside its capability scope." Provable by type soundness of the capability calculus.
  • Budget conservation: "Total spending across all agents in a delegation tree never exceeds the root budget." Provable via linear type preservation.
  • Revocation completeness: "Revoking a node in the DAG invalidates all descendants." Provable by structural induction on the DAG.
  • Liveness: "An agent with valid capabilities can always make progress." Provable via session type progress theorems.

Tools like TLA+, Isabelle/HOL, or Lean could encode these properties. For on-chain enforcement, runtime verification via ERC-4337 validation modules provides a pragmatic middle ground—not full formal proof, but mechanized checking at transaction time.

7. Open Research Questions

  1. Expressiveness vs. safety trade-off: How restrictive can capability scopes be before agents become too constrained to perform useful multi-step DeFi strategies? Can we characterize the Pareto frontier?

  2. Dynamic re-scoping: Can an agent request expanded capabilities mid-session, subject to user approval or automated policy? How do session types handle protocol evolution?

  3. Cross-chain delegation: When an agent operates across multiple chains (e.g., bridge + swap + lend), how do capability scopes compose across heterogeneous trust domains?

  4. Incentive alignment: Can we design mechanisms where agents are economically incentivized to operate within scope, beyond mere enforcement? (e.g., staking authority bonds that are slashed on scope violation)

  5. Privacy-preserving delegation proofs: Can an agent prove it is operating within scope without revealing its full capability set? ZK proofs over capability attestations could enable this.

  6. Empirical capability analysis: What capability profiles do real-world agents (trading bots, yield optimizers, social agents) actually need? Can we derive minimal capability sets from historical transaction data?

  7. Revocation latency: In delegation DAGs with on-chain enforcement, what is the worst-case time between a revocation decision and effective cessation of all descendant activity? Can this be bounded?

Conclusion

Scoped agent delegation sits at the intersection of programming language theory, distributed systems security, and mechanism design. The tools exist—capability models, session types, linear types, formal verification—but they have not been systematically applied to the autonomous agent + blockchain setting. The practical infrastructure (EIP-7702, delegation toolkits, smart contract wallets) is maturing in parallel. The research opportunity is to bridge these worlds: build a formally grounded, practically deployable framework that makes cascading agent failures structurally impossible rather than merely unlikely.