ERC-8196: AI Agent Authenticated Wallet

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 - on-chain identity and registration
• Layer 2 (Verify): ERC-8126 - 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	"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:

• 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 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 Types

Core Interface

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's Validation Registry.

Error Codes

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.