AI agents increasingly interact with smart-contract accounts, but an ordinary recovered-address check is not sufficient for every signer. This runbook focuses on ERC-1271 contract signature validation together with EIP-712 typed intent, policy limits and test cases. The analysis is based on the original Ethereum Improvement Proposals (ERC-1271, created 25 July 2018; EIP-712, created 12 September 2017) and current OpenZeppelin interface documentation, reviewed 12 November 2026.

Contract wallets need a different signature test

Many agent-wallet demonstrations assume that a signature can be recovered to an externally owned account address. That assumption fails for contract wallets whose authorization can involve multiple owners, policy modules or time-dependent rules. ERC-1271 was created to standardize how a contract reports whether a supplied hash and signature are currently valid. Its core interface returns the specific success value 0x1626ba7e when verification passes. This is not an instruction to trust any wallet calling itself an AI agent. It means that a verifier must ask the contract’s actual validation logic instead of relying exclusively on an ECDSA recovery result. A secure integration detects the signer account type at the time of verification, handles unexpected return data, and refuses signatures for which an explicit policy cannot be established.

Make the intent readable with EIP-712

EIP-712 defines a typed structured-data signing method with a domain separator. A useful agent instruction should expose the chain ID, verifying contract, intended action, spending cap, expiration, nonce and target asset in a form a human can review before authorizing it. Do not imply that the standard itself prevents replay: its security considerations explicitly leave application-level replay handling to the protocol. Teams should define a typed message that is no broader than the action being authorized. A permission for one token swap must not silently become permission for every future transaction or every network. Because the domain separator includes context such as chain and contract, failures to check the displayed target are especially dangerous in multi-chain interfaces. Typed data increases interpretability; it does not eliminate social engineering.

Build a validation matrix across account states

Test at least six states in a local fork or controlled testnet. First, verify a valid signature from the currently authorized owner. Second, remove that owner and check whether the exact same signed instruction becomes invalid when the wallet policy requires it. Third, add a second signer with a threshold and confirm that one signature is insufficient. Fourth, move to another chain and check domain separation. Fifth, use an expired instruction with a correct cryptographic signature and require the application policy to reject it. Sixth, simulate a contract that reverts, returns the wrong magic value or consumes a high gas budget during signature checks. Some ERC-1271 implementations are context-sensitive; a UI that cached “valid forever” is therefore incorrect. Record each result alongside block number, contract code hash, and policy configuration.

Do not confuse signature approval with execution approval

A signature can establish authorization without proving that a transaction should execute under current market or platform conditions. An AI agent planning a swap must still validate maximum slippage, fee ceilings, token address, approval duration, recipient allowlists and live balance. Restrict the tool that converts a signed intent into a transaction. In production, represent the workflow as proposed, human-reviewed when required, validated, submitted, confirmed or rejected. Each transition needs an audit event and a bounded timeout. Emergency pause should stop new submissions but cannot necessarily undo a transaction already confirmed on-chain. Avoid vague messages such as “your wallet has been secured”; show the actual limitation and the remaining risk. Price movements after signing deserve a new pre-execution simulation, not automatic blind execution.

An illustrative budget policy for agent signatures

Consider a hypothetical wallet that permits no more than $100 worth of one approved stablecoin per day, a five-minute signed-action lifetime, and a single target protocol. This example is a product policy, not a blockchain rule or a guarantee of a dollar price. Normalize token decimals, base the valuation on a disclosed pricing method, and enforce an absolute token-amount cap as a fallback when a price feed is stale. If the agent attempts a $150 transfer or a second $80 action after spending $50, the policy rejects it even if the ERC-1271 call returns the valid signature magic value. A well-designed authorization layer treats cryptographic validity as one necessary condition within a larger decision. Log the policy reason without recording unnecessary private user data.

Release gate and incident recovery

The sign-off checklist should contain a local reproduction of owner rotation, chain mismatch, stale nonces, insufficient thresholds, wrong contracts and unexpected ERC-1271 responses. Compare the wallet’s on-chain result with the application’s off-chain simulation, and treat disagreement as a deployment blocker. Contract signatures can behave differently after upgrades or policy changes; recalculate validity close to execution instead of assuming a previous result remains authoritative. Preserve enough metadata to reconstruct the authorized action without archiving secret keys. When a suspicious action is detected, revoke the relevant session capabilities and pause downstream automation while investigators determine whether any transaction was final. These controls are the difference between demonstrating that an AI agent can obtain a signature and operating a wallet that a human can meaningfully supervise.

Sources

1. Ethereum Improvement Proposals, ERC-1271, created 25 July 2018.
2. Ethereum Improvement Proposals, EIP-712, created 12 September 2017.
3. OpenZeppelin Contracts, IERC1271 interface, living official documentation, accessed 12 November 2026.

Illustrative policy amounts are not financial or security assurances. Photo: Kanchanara / Unsplash.