admin
AI agents can propose and execute on-chain actions, but a convenient signature is not the same thing as a safe, reviewable permission. EIP-7702 adds a transaction mechanism through which an externally owned account may designate executable code. That creates useful wallet experiences and a demanding operational question: what happens when the delegate is buggy, unavailable or malicious? This runbook separates protocol facts from product controls. It does not imply that EIP-7702 itself supplies budgets, user confirmation, or an agent policy engine.
Start with the delegation trust boundary
The EIP-7702 specification, created on 7 May 2024 and marked Final, describes a new transaction type for setting code behavior at an externally owned account. It is a mechanism, not a universal approval framework. Before activating an AI wallet, identify the exact delegation target, its deployed bytecode hash, who can upgrade the implementation, and the conditions under which execution should be denied. Create a separate inventory for the owner key, agent runtime, sponsor or relay, destination contracts, and any admin upgrade path. A seemingly harmless change in a relay can affect transaction availability; a change in delegate logic can affect asset safety. Product documentation should state which components are controlled by the user and which by a service provider. A contract address alone does not answer those questions.
Display a typed authorization rather than a marketing promise
The EIP-712 standard, created on 12 September 2017, specifies typed structured-data hashing and signing. Product teams can use structured signing patterns to display domain, network, action, destination and expiration in a human-reviewable interface, while respecting the exact signature semantics required by the chosen wallet and protocol. Do not imply that every EIP-7702 authorization is itself an EIP-712 message; its wire format must be implemented according to EIP-7702. The practical design principle is consistent disclosure. Before an agent can move funds, explain the account that will be affected, the code that will act, the maximum economic exposure and how long the permission lasts. A user approving a trading strategy should not unknowingly approve unlimited NFT transfers or unrelated account operations.
Define budgets outside the base protocol
An AI agent may be correct at choosing a contract yet wrong about amount, token decimals or slippage. Treat spending constraints as independently testable product policy: an allowed-chain set, target-address allowlist, asset-specific daily cap, cumulative session cap and emergency pause. Put the hard checks in a component that the agent cannot rewrite by prompting itself. Distinguish a request budget from actual settled value, and count partial execution, failed transactions and refunds consistently. For example, a hypothetical $100 daily ceiling should include already committed transactions still awaiting finality, not merely the last successful transfer. Test a rapid sequence of transactions that individually remain below the limit but collectively exceed it. The risk model should also include gas sponsorship abuse, replayed requests, malformed chain identifiers and counterparties with upgradeable contracts. These are product engineering controls, not automatic protocol guarantees.
Simulate adverse network and contract states
Before sending a transaction, compare the agent’s intent with a simulation of likely execution. However, simulations depend on state assumptions and cannot guarantee the exact eventual result. Build test fixtures for a changed pool price, a revoked allowance, token decimals mismatch, malicious callback, unavailable RPC provider, and a delegate contract returning unexpected data. Run the same action through at least two independent checks where economically justified, and show users when certainty is low. An approval screen should indicate if the destination or calldata changed after the agent composed the proposed action. Persist the raw proposed transaction and the simulated outputs in a limited-retention evidence record. Neither a successful simulation nor an impressive benchmark substitutes for a reviewed delegate implementation, and a test passing on one chain does not establish safety on another.
Rehearse recovery before production use
Recovery design should be decided while the account still has no valuable assets. Document the path for replacing an unsafe delegate where the relevant account and protocol semantics permit it, and distinguish this action from revoking token approvals, canceling off-chain agent jobs or rotating service credentials. Those are separate operations. In a staging environment, deliberately take the agent server offline, compromise a test delegate, lose a relay connection and trigger an emergency pause. Confirm the owner can inspect assets and complete the recovery route using a separate trusted device or wallet interface. Measure recovery time and the amount at risk during the process. Do not market a one-click reset if it leaves token approvals intact or if a compromised owner key can simply reauthorize the same malicious code. Publish the limitations of recovery plainly.
Publish measurable controls and an incident ledger
Operational reporting is more valuable than declaring an agent wallet safe. Track unauthorized-action attempts blocked, simulation disagreements, customer-canceled proposals, allowance exceptions, stuck transactions and time from detection to containment. Keep sensitive addresses and trade data only as long as necessary; separate aggregate reliability metrics from identifiable transaction evidence. For each incident, retain the chain, transaction hash, delegate code version, signed authorization context, policy decision and relevant timestamps. Review the ledger after contract upgrades and chain forks. A useful release gate might require zero unauthorized executions in a scripted adversarial suite, a successful recovery exercise, and a verified budget accounting path. Those are proposed acceptance criteria, not measured claims about any deployed wallet. Agent autonomy should expand only after the audit trail shows it behaves predictably under failure.
Illustrative process recommendations are editorial analysis, not protocol guarantees or measured production results.
