--- eip: 8196 title: AI Agent Authenticated Wallet description: Policy-bound transaction execution and verifiable credential delegation for autonomous AI agents author: Leigh Cronian (@cybercentry) discussions-to: https://ethereum-magicians.org/t/erc-8196-ai-agent-authenticated-wallet/27987 status: Draft type: Standards Track category: ERC created: 2026-03-14 requires: 155, 191, 712, 4337, 8004, 8126 --- ## Abstract This ERC defines a standard interface for AI agent-authenticated wallets. These wallets execute transactions only when accompanied by verifiable cryptographic proof that the action complies with a specific policy defined by the asset owner. It serves as **Layer 3 (Execute)** in a modular trust stack designed for secure autonomous AI agents: - **Layer 1 (Register)**: [ERC-8004](./eip-8004.md) - on-chain identity and registration - **Layer 2 (Verify)**: [ERC-8126](./eip-8126.md) - verification/risk scoring - **Layer 3 (Execute)**: This standard - policy-bound execution with immutable audit trail The design enables secure credential delegation without exposing private keys, prevents host manipulation of agent behavior, provides tamper-evident logging of all session activity, and ensures users retain final say over their agents and actions, as emphasized in the EF Mandate ("a user has the final say over their identities, assets, actions, and agents"). ## Motivation Autonomous AI agents introduce critical security challenges when performing on-chain actions: 1. **Hosting Trust Trap** - Hosts can steal private keys if agents hold funds directly 2. **Blind Delegation** - Credential delegation to agents lacks enforceable limits or auditable compliance 3. **Host Manipulation** - Malicious hosts can suppress outputs, delay requests, replay probabilistic queries, or influence agent behavior through repeated sampling 4. **Malicious Historical Activity** - Agents with prior sanctions, mixer usage, bot-like patterns, rapid forwarding, or clustering with tainted addresses pose ongoing risk 5. **Replay & Timing Vulnerabilities** - Valid proofs from the past can be reused, or timing manipulated to the host's advantage This ERC provides the execution layer in a composable trust stack to mitigate these risks: | Layer | Purpose | Standard | Core Question | |-------|--------------------------|---------------------------|----------------------------------------| | 1 | Register | [ERC-8004](./eip-8004.md) | "Does this agent exist on-chain?" | | 2 | Verify | [ERC-8126](./eip-8126.md) | "Is this agent trustworthy and free of malicious signals?" | | 3 | Execute | This ERC | "Is this action authorized right now?" | Key features include: - Cryptographically enforced policy compliance - Immutable, hash-chained audit trail for verifiable delegation - Entropy commit-reveal to counter host influence on probabilistic agents - Active containment mechanisms (recommended) for real-time violation response - Legacy credential delegation via TLS attestations - User sovereignty over agent actions via enforceable, auditable policy compliance, emphasising final user control over agents and actions The verification layer allows flexibility while strongly encouraging checks (e.g. via ERC-8126 Wallet Verification) against historical malicious behavior before granting control. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. ### Trust Stack Integration This ERC defines an on-chain smart contract interface (`IAIAgentAuthenticatedWallet`). Implementations are expected to be smart contracts (such as [ERC-4337](./eip-4337.md) account abstraction wallets or dedicated policy enforcement modules) that implement this interface. - Registration Check (ERC-8004): Implementations MUST verify that the agent is properly registered via ERC-8004 before registering or using any policy. - Verification Check (ERC-8126): Implementations MUST perform a verification check using ERC-8126 before executing any agent action. The policy’s `minVerificationScore` field MUST be enforced. Actions MUST be rejected if the agent’s current ERC-8126 score exceeds the `minVerificationScore` value set in the policy. Off-chain components (such as agent hosting services, wallet UIs, and relayers) SHOULD also perform the same registration and verification checks before submitting transactions or UserOperations. ### Agent Policy Structure Policies MUST include the following fields: | Field | Type | Required | Description | |------------------------|---------------|----------|-------------| | `policyId` | `bytes32` | Yes | Unique policy identifier | | `agentAddress` | `address` | Yes | Authorized AI agent address | | `ownerAddress` | `address` | Yes | Asset owner / delegator | | `allowedActions` | `string[]` | Yes | List of permitted actions (e.g. `["transfer", "swap"]`) | | `allowedContracts` | `address[]` | Yes | Whitelist of target contracts | | `blockedContracts` | `address[]` | Yes | Blacklist of contracts | | `maxValuePerTx` | `uint256` | Yes | Maximum value per transaction (in wei) | | `maxValuePerDay` | `uint256` | No | Optional daily spending limit (in wei) | | `validAfter` | `uint256` | Yes | Timestamp when the policy becomes active | | `validUntil` | `uint256` | Yes | Timestamp when the policy expires | | `minVerificationScore` | `uint8` | Yes | Minimum ERC-8126 verification score required (20 = Low Risk tier; scores 0–20 allowed; lower score = lower risk) | ### [ERC-712](./eip-712.md) Types bytes32 constant AGENT_ACTION_TYPEHASH = keccak256( "AgentAction(address agent,string action,address target,uint256 value,bytes data,uint256 nonce,uint256 validUntil,bytes32 policyHash,bytes32 entropyCommitment)" ); bytes32 constant DELEGATION_TYPEHASH = keccak256( "Delegation(address delegator,address delegatee,bytes32 policyHash,uint256 validUntil,uint256 nonce)" ); ### Core Interface // SPDX-License-Identifier: CC0-1.0 pragma solidity ^0.8.20; interface IAIAgentAuthenticatedWallet { event PolicyRegistered( bytes32 indexed policyHash, address indexed owner, address indexed agent, uint256 validUntil ); event ActionExecuted( bytes32 indexed policyHash, address indexed agent, address target, uint256 value, bytes32 auditEntryId ); event PolicyRevoked( bytes32 indexed policyHash, string reason ); event AuditEntryLogged( bytes32 indexed entryId, uint256 sequence, bytes32 sessionId, string actionType ); function registerPolicy( address agent, string[] calldata allowedActions, address[] calldata allowedContracts, address[] calldata blockedContracts, uint256 maxValuePerTx, uint256 maxValuePerDay, uint256 validAfter, uint256 validUntil, uint8 minVerificationScore ) external returns (bytes32 policyHash); function executeAction( bytes32 policyHash, address target, uint256 value, bytes calldata data, uint256 nonce, bytes32 entropyCommitment, bytes calldata signature ) external returns (bool success, bytes32 auditEntryId); function revokePolicy(bytes32 policyHash, string calldata reason) external; function getPolicy(bytes32 policyHash) external view returns ( address agent, address owner, uint256 maxValuePerTx, uint256 validUntil, bool isActive ); } ### Audit Trail (Hash-Chained) Each audit entry MUST include `previousHash` for integrity. Implementations MAY store entries off-chain (e.g. IPFS) with periodic on-chain Merkle roots posted to [ERC-8004](./eip-8004.md)'s Validation Registry. ### Error Codes error PolicyExpired(bytes32 policyHash, uint256 validUntil); error ValueExceedsLimit(uint256 value, uint256 maxValue); error InvalidSignature(address recovered, address expected); error EntropyVerificationFailed(bytes32 commitment, bytes32 revealed); error AgentNotRegistered(address agent); error PolicyViolation(bytes32 policyHash, string reason); ## Rationale - Separation of concerns: identity (ERC-8004) and verification (ERC-8126) decoupled from execution, with verification enforced via policy - `policyHash` in ERC-712 signatures binds actions immutably - Hash-chain audit provides tamper detection without full on-chain cost - Verification gating allows flexibility while encouraging trust standards like ERC-8126 This specification explores novel combinations of policy-bound signing, hash-chained auditing, and entropy commitments to enable verifiable agent autonomy under potentially hostile hosts, with open questions regarding gas-efficient audit roots, threshold-based containment mechanisms, and the enforcement of CROPS properties in high-value agent scenarios. ## Backwards Compatibility Compatible with ERC-4337 wallets and existing standards. No breaking changes. ## Security Considerations - Implementations should verify ERC-8004 registration before allowing any policy delegation. - Expiration checks and nonce uniqueness should be enforced to prevent replay attacks. - The hash-chained audit trail makes tampering detectable through broken hash links. - Host manipulation remains a probabilistic risk. For high-value agents, using multiple independent hosts is recommended to reduce this threat. - A recent verification via ERC-8126 with a low risk score is required before delegation. Special attention must be given to clean Wallet Verification (WV) results showing no signs of sanctions, mixer usage, bot-like patterns, rapid forwarding, or threat intelligence hits. - Wallets must reject or revoke delegations if the ERC-8126 Wallet Verification flags malicious activity (such as sanctioned funding, clustering with known bad actors, or strong automation indicators), even if the overall risk score appears acceptable. - User sovereignty must remain the highest priority. Designs should ensure users retain final control over their agents and actions, and avoid any mechanism that introduces blind trust or unaccountable intermediation. - The system should be designed with CROPS principles in mind: strong censorship resistance, verifiable security, and privacy preservation (minimizing on-chain data exposure through ERC-8126 gating). - Active containment mechanisms should be implemented where possible. These allow users to respond quickly to policy violations and help preserve sovereignty. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).