ERC-8196 AI Agent Authenticated Wallet
Final · Accounts & wallets · created 2026-03-14
A wallet standard that only executes transactions when there is cryptographic proof that an AI agent complied with policies set by the asset owner. It allows authority to be delegated to an agent without handing over the private key.
Why it is needed
To delegate on-chain tasks to an autonomously operating AI agent today, there are only two bad options. If the agent holds funds and the private key directly, the hosting provider running the agent can steal the key. Conversely, if only authority is delegated, there is no enforceable limit, and there is no way to later verify whether the agent followed the rules. A malicious host can manipulate behavior by hiding the agent's output, delaying requests, or repeatedly asking a probabilistic agent the same question until a favorable answer comes out. There is also the problem of an agent with a history of sanctioned funds or mixer use retaining authority as-is, and replay attacks that reuse past valid proofs. This standard reduces these risks by enforcing policy verification inside the wallet contract.
What to implement
function revokePolicy(bytes32 policyHash, string calldata reason) external;: Revokes a registered policy, leaving a reason.
In depth
Position in the trust stack and enforced ERC-8126 verification
This standard is layer 2 (execution) of a modular trust stack for autonomous AI agents. Layer 1 (identity and verification) is handled by ERC-8126. Implementations MUST perform ERC-8126 verification before executing an agent action, looking up getLatestRiskScore using the policy's agentId and rejecting the action if the current score exceeds the policy's minVerificationScore. Lower scores mean lower risk, with 20 marking the Low Risk tier and 0 to 20 being the acceptable range. Off-chain components such as hosting services, wallet UIs, and relayers are also recommended to perform the same verification before submitting a transaction.
Policy structure
Required policy fields are policyId (unique identifier), agentAddress (authorized agent address), agentId (ERC-8126 lookup key), ownerAddress (asset owner), allowedActions (list of allowed actions, e.g. transfer, swap), allowedContracts (target contract whitelist), blockedContracts (blacklist), maxValuePerTx (maximum amount per transaction, in wei), validAfter and validUntil (activation and expiration times), and minVerificationScore (required minimum ERC-8126 verification score). maxValuePerDay (daily spending limit) is an optional field.
EIP-712 signatures and policy hash binding
An agent's action is signed as the AgentAction type, which includes the agent, action, target, value, data, nonce, validUntil, policyHash, and entropyCommitment fields. The delegation itself is signed as the Delegation type, which holds delegator, delegatee, policyHash, validUntil, and nonce. Both types include policyHash, so the signed action and delegation are immutably bound to a specific policy. Signature verification failure raises an InvalidSignature error.
Entropy commit-reveal
A probabilistic agent can be manipulated by a malicious host repeatedly sampling the same request and choosing the result that favors it. To prevent this, executeAction includes an entropyCommitment (entropy commitment value), and if the revealed value does not match the commitment, the request is rejected with an EntropyVerificationFailed error. However, the source acknowledges that host manipulation remains a probabilistic risk and recommends using multiple independent hosts for high value agents.
Hash-chained audit trail
Every audit entry MUST include a previousHash, linking it by hash to the prior entry. If a record in the middle is altered, the hash chain breaks, revealing the tampering. Implementations may choose to store entries off-chain, such as on IPFS, and periodically anchor a Merkle root on-chain, providing tamper detection without the cost of storing everything on-chain. Each entry is logged via an AuditEntryLogged event along with its sequence number, session ID, and action type.
Standard error codes
There are five common errors used across implementations: PolicyExpired (policy has expired), ValueExceedsLimit (amount limit exceeded), InvalidSignature (signer mismatch), EntropyVerificationFailed (entropy commitment and revealed value mismatch), and PolicyViolation (other policy violations and reasons). Errors carry contextual values such as the policyHash or limit so the cause of rejection can be identified.
Compatibility and design direction
Compatible with ERC-4337 account abstraction wallets and existing standards, with no breaking changes. Implementations are built as smart contracts such as ERC-4337 wallets or dedicated policy enforcement modules. The source leaves gas-efficient audit roots, threshold-based quarantine mechanisms, and enforcing CROPS (censorship resistance, open source, privacy, security) properties for high value agent scenarios as open questions. This standard has been finalized with Final status.
Things to watch out for
- Replay attack prevention: Expiration time checks and nonce uniqueness must be enforced so that past valid proofs cannot be replayed.
- Host manipulation risk: Host manipulation remains a probabilistic risk. Using multiple independent hosts is recommended for high value agents to reduce this threat.
- Pre-delegation verification and malicious signal checks: A recent ERC-8126 verification with a low risk score is required before delegation. Particular attention should be paid to a clean wallet verification result showing no sanctions, mixer use, bot patterns, rapid fund movement, or threat intelligence hits.
- Reject even with a good score if flags are present: Even if the overall risk score looks acceptable, delegation should be rejected or revoked if ERC-8126 wallet verification flags malicious activity such as sanctioned funds, clustering with malicious actors, or strong automation indicators.
- User sovereignty and active quarantine: The top priority is that the user retains final say over the agent and its actions, avoiding designs that create blind trust or unaccountable intermediation. Active quarantine mechanisms that can respond immediately to policy violations should be implemented wherever possible.