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:
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").
Autonomous AI agents introduce critical security challenges when performing on-chain actions:
This ERC provides the execution layer in a composable trust stack to mitigate these risks:
| Layer | Purpose | Standard | Core Question |
|---|---|---|---|
| 1 | Register | ERC-8004 | "Does this agent exist on-chain?" |
| 2 | Verify | ERC-8126 | "Is this agent trustworthy and free of malicious signals?" |
| 3 | Execute | This ERC | "Is this action authorized right now?" |
Key features include:
The verification layer allows flexibility while strongly encouraging checks (e.g. via ERC-8126 Wallet Verification) against historical malicious behavior before granting control.
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.
This ERC defines an on-chain smart contract interface (IAIAgentAuthenticatedWallet). Implementations are expected to be smart contracts (such as ERC-4337 account abstraction wallets or dedicated policy enforcement modules) that implement this interface.
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.
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) |
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's Validation Registry.
policyHash in ERC-712 signatures binds actions immutablyThis 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.
Compatible with ERC-4337 wallets and existing standards. No breaking changes.
Copyright and related rights waived via CC0.