admin
Delegation is not authorization for every future action
AI agents that trigger onchain actions create an uncomfortable gap between a user’s broad instruction and the exact transaction that finally executes. Ethereum’s EIP-7702 enables an externally owned account to delegate code execution behavior, but it does not by itself decide which shopping order, subscription renewal or service payment the user has approved. Treating delegation as universal user consent is an architectural mistake. The EIP-7702 specification, created May 7, 2024, describes authorization tuples, chain identifiers, nonces and delegation behavior. An application must build its own boundaries on top. For an AI commerce example, permission to use an approved smart-account implementation is a separate act from permission to spend a particular amount. The interface must describe those acts in different words, and the agent executor should enforce both at transaction time rather than relying on an earlier conversational promise.
Model the three authority layers independently
A threat model becomes clearer when authority is divided into three layers. The first is code delegation: what implementation the externally owned account points to and on which chain. The second is policy authority: which operation types, destination contracts, time windows and spending limits the user has agreed to. The third is execution authority: which service, signer or session key may submit a concrete action. These layers can have different lifetimes. A user might retain a trusted wallet implementation for months but authorize one AI task for only a few minutes. Never infer a reusable allowance from a one-time signature. The implementation should record the policy version and task identifier alongside each execution request, then verify them against current onchain state. A UI history item ought to distinguish rejected, simulated, submitted, reverted and finalized actions, since displaying all of them as completed purchases misleads users.
Read the actual authorization tuple and its consequences
EIP-7702 defines an authorization tuple that includes chain_id, address, nonce and signature-related fields. These fields are not a human-readable list of approved merchants or amounts. The target address identifies delegated code; its presence must therefore be assessed as an implementation trust decision. Ethereum.org’s EIP-7702 guide notes that delegation can be reset by delegating to the null address and that the original private key retains control. Neither statement should be distorted into a guarantee that every side effect can be reversed. A transaction that already transferred value may be irreversible even if delegation is subsequently removed. This distinction must appear in wallet onboarding and emergency documentation. The engineering acceptance criteria should confirm the exact bytecode and contract address rather than trusting an agent’s description of what its wallet can do.
Put budgets in executable policy rather than prompts
An LLM instruction such as “never spend more than fifty dollars” is not a sufficient financial control. Construct a policy object with token identity, chain, destination allowlist, single-action maximum, daily aggregate maximum, expiry and permitted methods. Validate arithmetic using onchain token decimals and conservative exchange-rate assumptions when a fiat-denominated limit is unavoidable. Keep a budget ledger that reserves expected spending before broadcasting and reconciles settled outcomes after receipts arrive. Concurrency matters: two agents can each see the same remaining allowance and overspend without atomic reservation. Failed simulations must release reservations according to an explicit timeout policy. A realistic test suite includes replay attempts, chain mismatch, token fee changes, split orders, reorgs and a malicious description supplied through a retrieved web page. These scenarios exercise authorization, not the persuasive power of a chatbot.
Design revocation to include queues and stale sessions
When a user revokes a task, the scheduler should stop creating new proposed transactions and invalidate outstanding session authority. But a transaction already submitted to a network may still settle. The UI therefore needs three labels: future actions blocked, pending actions under observation, and already finalized actions. A safe revoke flow surfaces that residual exposure without promising cancellation that Ethereum cannot deliver. If the code delegation changes, the application should re-read the onchain delegation state before executing queued tasks. The offchain task service must not use a cached account state indefinitely. For emergency response, operators need a documented kill switch for their executors and a visible audit trail showing when the final execution was accepted. Avoid storing raw wallet secrets in agent prompts, long-term memories or ordinary analytics systems.
A security test matrix for product teams
Evaluate at least six scenarios before launch. Begin with a normal low-value purchase and compare human-readable consent to the encoded transaction. Next attempt a destination outside the allowlist, a total above the budget, and a method prohibited by policy. Then revoke a delegation while an action remains queued and repeat the test on another chain. Finally inject a malicious instruction into a supplier page and confirm that the agent can describe it but cannot elevate its execution authority. Record expected rejection reasons and actual onchain outcomes for every test. Use a local simulation or test network for destructive cases, and describe results as test evidence rather than universal security claims. EIP-7702 expands what familiar accounts can do, but secure AI-agent commerce still depends on explicit economic consent, careful implementation review and continuously enforced transaction boundaries.
