Readable typed-data requests are a useful upgrade from hexadecimal signing prompts, but readability is not security. An AI agent wallet may present a neatly formatted spending instruction while a verifier still accepts it on the wrong chain, twice in succession, or after its intended expiry. EIP-712, created in 2017, standardizes structured-data hashing and domain separation; the specification explicitly does not include replay protection. EIP-155, created in 2016, provides replay protection for a separate transaction-signing context. The engineering task is to test the entire permission boundary, not to infer safety from a recognizable standard number.

Write down the authority before the payload

Specify the signer, the AI agent requesting authorization, the intended operation, target contract, asset and value limits. A natural-language instruction such as ‘pay the usual supplier’ is insufficient: the signed data must identify the exact destination, token, quantity and constraints that the execution system will enforce. Define permitted changes separately from immutable fields. Record who is allowed to cancel a pending instruction and whether the signature authorizes one operation or a bounded series. Build a negative test list that attempts to turn a harmless instruction into a larger transfer. The system should reject parameter changes even when the UI still looks plausible. Successful signature recovery proves only the signer, not that the transaction is commercially justified.

Bind the EIP-712 domain to the real verifier

The domain may include name, version, chainId, verifyingContract and optional salt. Reconstruct those values from trusted deployment configuration at verification time. Do not accept the domain submitted by an untrusted relay as the sole source of truth. Create paired tests where the same payload and signature appear on another network, another verifying contract and another protocol major version. Expected rejection must be asserted at the actual contract or authoritative off-chain verifier rather than only at a web form. If a deployment relies on a proxy, document which address is the logical verifying contract and how upgrades affect compatibility. Display the application name and network clearly when requesting human approval.

Use nonces and deadlines against same-domain replay

EIP-712 domain separation alone does not stop the same valid instruction being executed repeatedly. Include a nonce or other uniquely consumable authorization identifier in the signed struct and update its state atomically. Reject a signature after the nonce is consumed, including when two workers race to submit identical actions. Include a deadline and evaluate it under the transaction’s actual execution context. Decide whether canceled and expired nonces can ever be reused; an unsafe reset can resurrect old signatures. For scheduled AI agent actions, define whether user consent must be renewed after a delay and how an emergency stop invalidates outstanding authorizations. Keep the nonce ledger independent from LLM conversation history.

Separate EIP-155 transaction protection from message signing

EIP-155 binds certain Ethereum transactions to a chain ID through transaction signature encoding. An EIP-712 message may be verified off-chain or consumed by a smart contract; it needs its own domain and nonce enforcement. Both mechanisms matter, but neither substitutes for the other. An integrator should test changes of chain before signing, between signing and simulation, and between simulation and settlement. Also test wallets whose signer is a contract account and wallets where the user signs through another authorized mechanism. A successful ECDSA check is not enough to prove a smart-account signature’s policy is satisfied. Make the wallet adapter expose which verifier decided validity.

Account for upgrades, forks and delegated execution

Proxy upgrades can change the meaning of a signed message without changing the verifying contract address. Version the instruction schema and decide whether older authorizations remain valid. Test deployments cloned to testnets, forks with conflicting chain configuration, migration to a new contract, and delegated agent keys whose privileges have been revoked. On a fork, domain values and contract state may initially resemble the original environment, so document the actual threat model rather than promising universal isolation. Human approval receipts should include the domain values, signed hash, permitted action and timestamp. They should not expose seed phrases or unnecessary private conversation transcripts.

Run a reproducible signature abuse matrix

Create fixtures for valid signature, changed amount, substituted recipient, wrong chain, wrong contract, replayed nonce, expired permission, protocol downgrade and simultaneous submissions. Record expected outcome before testing; capture transaction simulation results and final chain traces separately. Measure both false acceptance and legitimate operations mistakenly blocked. Retest after smart contract or SDK upgrades. For AI agents, add an operational rule that high-impact actions require a visible scope preview and a second approval as appropriate. Classify a test as passed only if the final authoritative executor rejects the misuse, not because the client displays an error while the underlying transaction remains possible.

A secure AI agent wallet treats typed-data signing as a structured permission request. Chain binding, verifier consistency, nonce consumption and execution-time policy are the mechanisms that make that request enforceable. This is a technical test plan, not an assertion that any specific wallet is secure.

Illustrative cover photograph from Unsplash.

Sources (official documents, accessed 12 November 2026): EIP-712 specification (2017); EIP-155 specification (2016).