ERC-8196: AI Agent Authenticated Wallet

ERCs
, ,
1

Hi everyone,

Following the progress on ERC-8004 (Trustless Agents) and the refinements to ERC-8126 (AI Agent Verification), I’d like to propose a new ERC: AI Agent Authenticated Wallet — policy-bound transaction execution and verifiable credential delegation for autonomous AI agents.

This standard acts as Layer 3 (Execute) in a composable trust stack:

  • Layer 1: ERC-8004 — Register → “Does this agent exist on-chain?”
  • Layer 2: Optional verification (e.g. ERC-8126) — “Is this agent trustworthy / free of malicious signals?”
  • Layer 3: This ERC — “Is this specific action authorized right now?”

The core idea is to enable secure, auditable delegation of control to AI agents without exposing private keys or allowing blind overreach.

Key elements:

  1. Policy-bound execution — Transactions only succeed with an EIP-712 signed proof that the action complies with a pre-defined policy (allowed actions, contracts, value limits, expiry, optional ERC-8126 min risk score).

  2. Immutable, hash-chained audit trail — Every action is logged with cryptographic integrity (previousHash chaining), grouped by sessionId, with on-chain correlation via txHash or Merkle roots (off-chain storage recommended for cost).

  3. Entropy commit-reveal — Prevents malicious hosts from influencing probabilistic agent decisions through repeated queries.

  4. Active containment (recommended) — Real-time monitoring, policy re-validation, and kill switch for violations.

  5. Legacy compatibility — TLSNotary attestations for verifiable credential delegation to existing websites without requiring new auth standards.

  6. Optional ERC-8126 gating — Policies can require low risk scores (especially clean Wallet Verification (WV) results) to block agents with sanctions, mixer usage, bot patterns, rapid forwarding, or clustering with tainted addresses.

The design depends on: EIP-155, EIP-191, EIP-712, ERC-4337, ERC-8004.

This proposal aligns with the Ethereum Foundation’s PhDFP-26 RFP D3 (“Agentic Economy: Verification, Delegation, and Host-Interference Mitigation”, opened February 9, 2026) by directly addressing agent-authenticated wallets, verifiable delegation, and host-interference mitigation.

Early feedback I’d like to hear:

  1. Does the policy structure cover the main constraints people need for safe agent delegation (actions, contracts, value, time, verification score)?

  2. Is the hash-chained audit trail (off-chain with optional on-chain roots) practical and sufficient for verifiability/dispute resolution?

  3. Entropy commit-reveal + active containment, useful enough to keep as recommended extensions, or should they be core?

  4. Any immediate concerns about nonce/replay protection, off-chain audit realism, or TLSNotary trust assumptions?

  5. How strongly should ERC-8126 WV be recommended for malicious-activity gating?

I’ll open a PR to the ethereum/ERCs repo. Looking forward to your thoughts, questions, and suggestions, this is meant to build directly on the great work already happening in 8004/8126.

Thanks for reading!

Leigh
@cybercentry
cybercentry.base.eth

2

Hello,

If you use ZK proofs, you can adapt ERC-8039(ZK Proof Verification for Smart Accounts). Especially for Policy-bound execution. It is a proof-system-agnostic interface for on-chain verification of succinct zero-knowledge proof by smart accounts.

Github: https://github.com/ethereum/ERCs/pull/1238/changes

ERC-8039 explanation: https://ethereum-magicians.org/t/erc-8039-zk-proof-verification-for-smart-accounts-programming-smart-account-logic-with-zk-circuits/27919

Reference implementation: GitHub - MicrochainLabs/microchain-zk-signers · GitHub

3

Hi @khemiriwalid,

Thanks for pointing to ERC-8039 as a potential fit for policy-bound execution.

The PHDFP-26 RFP D3 page lists Privacy & Scaling Explorations (PSE) as the leading group for zero-knowledge primitives and privacy-preserving protocols.

However, the RFP itself contains zero mentions of ZKP, zero-knowledge proofs, succinct proofs, privacy-preserving verification, on-chain ZK interfaces, or any ZK-based mechanism, even as optional, for agent-authenticated wallets, policy execution, delegation, audit trails, or host-interference mitigation.

It specifies verifiable proofs via EIP-712-style signed structures, TLSNotary for legacy credential delegation, hash-chained audit logs, entropy commitments for autonomy, and active containment—no ZK/ZKP in the scope or technical asks.

Since the RFP doesn’t require or encourage ZK primitives for this use case (despite naming PSE generally), we’re not building the agent wallet’s policy execution around it. EIP-712 structured signing remains the normative path—directly aligned with the RFP, proven in ERC-4337/7579, and ready for the April 1 deadline.

ERC-8039 can be noted in a non-normative “future privacy ideas” section.

If PSE signals interest in this direction or the proposal gains traction there, please ping me to revisit this.

Best,
Leigh
@cybercentry
cybercentry.base.eth

4

Hey @Cybercentry !

The PHDFP-26 RFP D3 also mentions:

Note: This RFP is meant as a high-level research direction. Applicants are encouraged to propose refinements, alternative approaches, or more detailed technical plans, which will be evaluated as part of the submission.

So researching a ZKP approach may be suitable, in fact it would be the best approach, except for the high cost associated with it.

Could you explain how exactly do you prove that an action is compliant with a policy using EIP-712? Would you have a set of constraints to verify what an agent could do? How is that maintained/updated and how do we give more capabilities to the agent if needed?

5

Good morning @ziemen4, thank you for the feedback and your question. The EF RFP has now been detached from this ERC, based on feedback from Office Hour #94:

EIP/ERC implementors aren’t beholden to the EF’s policies, so you might want to make the case for your proposal on its own merits.

We will, however, continue to research ZKPs in line with:

Privacy & Scaling Explorations (PSE) - https://pse.dev/: Leading research group for zero-knowledge primitives and privacy-preserving protocols.

1. How exactly do you prove that an action is compliant with a policy using EIP-712?
The asset owner registers a policy on-chain, which generates an immutable policyHash. The agent then signs an EIP-712 AgentAction struct that includes this exact policyHash (along with the action, target, value, data, nonce, etc.). The wallet contract verifies the agent’s signature and checks that the action fully complies with the policy tied to that policyHash before calling executeAction(…). (See Specification > [ERC-712] Types and Core Interface in the proposal.)

2. Would you have a set of constraints to verify what an agent could do?
Yes — the policy itself is the set of constraints. It MUST include: allowedActions, allowedContracts, blockedContracts, maxValuePerTx, optional maxValuePerDay, validAfter/validUntil, and minVerificationScore (ERC-8126). These are all stored on-chain against the policyHash. (See Specification > Agent Policy Structure.)

3. How is that maintained/updated, and how do we give more capabilities to the agent if needed?
Policies are immutable once registered (for a strong audit trail). To update or give the agent more capabilities, the owner calls registerPolicy(…) again with the new/expanded rules, which returns a fresh policyHash. The agent then starts signing actions with the new hash. Old policies can be revoked at any time via revokePolicy(…). (See Specification > Core Interface, including registerPolicy and revokePolicy, plus Rationale.)

Best,
Leigh
@cybercentry
cybercentry.base.eth

6

Hello @Cybercentry . When you state “See Specification”, what specification are you referring to? With access to that I can give a more coherent answer, thanks!

7

Hi @ziemen4, yes that’s the ERC-8126 Specification, at PR 1606.

Best,
Leigh
@cybercentry
cybercentry.base.eth

8

Thanks for your reply!

1. How exactly do you prove that an action is compliant with a policy using EIP-712?
The asset owner registers a policy on-chain, which generates an immutable policyHash. The agent then signs an EIP-712 AgentAction struct that includes this exact policyHash (along with the action, target, value, data, nonce, etc.). The wallet contract verifies the agent’s signature and checks that the action fully complies with the policy tied to that policyHash before calling executeAction(…). (See Specification > [ERC-712] Types and Core Interface in the proposal.)

I guess you should consider who is the party that can update the policy, this binding property is only secure as long as no one can create malicious policies in the first place.

I believe that for main constraints the data given is somewhat sufficient, though there may be complex attacks where the information given to the execute(…) method is not enough. Note that on-chain policy checks are both public (an attacker can see them) and potentially costly. A ZKP approach for policy verification yields privacy and succinctness, with an added overhead on proving cost. For that use-case the interface would change, so it would be a different ERC altogether.

> 2. Would you have a set of constraints to verify what an agent could do?
Yes — the policy itself is the set of constraints. It MUST include: allowedActions, allowedContracts, blockedContracts, maxValuePerTx, optional maxValuePerDay, validAfter/validUntil, and minVerificationScore (ERC-8126). These are all stored on-chain against the policyHash. (See Specification > Agent Policy Structure.)

A policy cannot be a set of constraints, a policy is data, but constraints are limitations or restrictions which must be imposed in runtime (when executing!). Therefore, it seems that the ERC does not define what constraints one should have but rather what data is required for whoever implements the interface to create a set of proper constraints. Would that be right?

> 3. How is that maintained/updated, and how do we give more capabilities to the agent if needed?
Policies are immutable once registered (for a strong audit trail). To update or give the agent more capabilities, the owner calls registerPolicy(…) again with the new/expanded rules, which returns a fresh policyHash. The agent then starts signing actions with the new hash. Old policies can be revoked at any time via revokePolicy(…). (See Specification > Core Interface, including registerPolicy and revokePolicy, plus Rationale.)

Is there one policy or multiple policies? Here you frame it as if there is a single policyHash but I may be misreading. Either way, not much to add but just the security issues on policy registration/revocation as these are critical operations.

9

Hey @ziemen4,

Thanks a lot for the detailed and sharp feedback. I really appreciate you taking the time to go through it so thoroughly.

Your points on policy registration/revocation security, the distinction between policy data vs. runtime constraints, potential on-chain limitations (and the ZKP alternative), and the need for careful access control on high-privilege operations are all spot on. They’ve already helped sharpen my thinking.

I’ll make sure this gets added to our RFI Matrix, so it’s properly tracked when the deeper research phase kicks off.

If anything else comes to mind (especially around zk-based verification flows given your background, or specific attack vectors on the EIP-712 binding), feel free to keep the thoughts coming; they’re genuinely helpful.

Thanks again!

Best,
Leigh
@cybercentry
cybercentry.base.eth

10

Hey @Cybercentry glad it was helpful. You can see more information in GitHub - ziemen4/zkguard · GitHub and a write-up will be available soon with more details. Feel free to contact me for anything you may need!