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) |
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)"
);
// 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
);
}
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.
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);
policyHash in ERC-712 signatures binds actions immutably 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.
Compatible with ERC-4337 wallets and existing standards. No breaking changes.
Copyright and related rights waived via CC0.