The AI Agent Trust Stack: ERC-8004, ERC-8126, and ERC-8196

Table of Contents

When an AI agent acts on behalf of a user (spending funds, calling contracts, accessing paid APIs), the obvious question is: how do you know this agent is safe? The Ethereum community has three standards that address different layers of that question. They don’t solve the whole problem, but they’re building toward a coherent stack.

The trust problem with autonomous agents

When a person signs a transaction in MetaMask, the signing party is unambiguous. When an AI agent executes transactions automatically, three distinct problems arise.

Identity. Agents from different organizations need a shared registry to interact. An agent claiming to be a “payment agent” is unverifiable without one. Without a common scheme, every platform builds its own allowlist, which fragments at scale.

Verification. Registration says an agent exists; it says nothing about whether it’s safe. The smart contract code may have a reentrancy bug. The wallet may have prior interactions with sanctioned addresses. A separate security assessment layer is needed, independent of the identity registry.

Execution scope. Giving an agent a private key means unconstrained access. Owners need to express delegation boundaries: this agent can swap up to $100 per day on these contracts, and nothing else. Those constraints need to be enforced at execution time, not just agreed upon informally.

Ethereum addresses these three problems with separate ERC standards. ERC-8004 handles identity. ERC-8126 (Final) handles verification. ERC-8196 (Review) handles execution policy. Each can be used independently, but high-value automated transactions benefit from all three.

ERC-8004: Trustless Agents

ERC-8004 provides a common registry for discovering and interacting with agents across organizational boundaries. It deployed on Ethereum mainnet on 2026-01-29 and has since been studied across Ethereum, BSC, and Base. The ethereum/ercs process status is Draft. Authors: Marco De Rossi, Davide Crapis, Jordan Ellis, Erik Reppel. It builds on ERC-721, EIP-712, EIP-155, and ERC-1271.

Three registries form the core:

Identity Registry. Agents are registered as ERC-721 NFTs. The tokenId is the agentId, and the tokenURI is the agentURI pointing to a JSON registration file. The global identifier looks like:

eip155:1:0x742...   (namespace:chainId:registryAddress)

The registration file contains the agent’s name, description, service endpoints, and supported trust models (reputation, crypto-economic, tee-attestation, etc.). Importantly, registration only provides discoverability. It doesn’t guarantee the agent is safe.

Reputation Registry. Clients post feedback on agents using tags like starred, reachable, uptime, responseTime. The registry is a generic bulletin board. Filtering to a trusted set of clientAddresses is the application’s responsibility. Without that, Sybil attacks are trivial.

Validation Registry. Stores on-chain records of validation requests and validator responses. The response field is 0–100 (binary validation can use 0=fail, 100=pass). The tag field classifies the verification method: tee-attestation, zkml, reexecution, etc.

ERC-8004 doesn’t mandate a single trust model. Low-stakes tasks and high-risk ones can use different verification approaches.

ERC-8126: AI Agent Verification

ERC-8004 records that an agent exists and who owns it. It says nothing about whether that agent is trustworthy. ERC-8126 is the verification layer: it defines the interface for external security assessment providers who evaluate a registered agent across wallet history, contract code, web endpoints, and media, then return a 0–100 risk score. Lower score means lower risk.

ERC-8126 moved to Final status on June 2, 2026. Authors: Leigh Cronian and Chris Johnson. It defines the interface for specialized security verification providers that assess an ERC-8004 registered agent.

The key design constraint: verifiers don’t accept raw parameters like walletAddress or url directly. They take an agentId and read the registration metadata through ERC-8004. This ties verification results to a registered agent identity rather than arbitrary parameters.

Five verification types compliant providers must implement:

  • ETV (Ethereum Token Verification): checks that the registered contract address is actually deployed and scans for known vulnerability patterns
  • MCV (Media Content Verification): checks agent images for AI-generation artifacts, provenance, and manipulation
  • SCV (Solidity Code Verification): scans Solidity code for reentrancy, flash loan attacks, and access control issues
  • WAV (Web Application Verification): validates HTTPS endpoints, TLS certificates, and common web vulnerabilities
  • WV (Wallet Verification): checks wallet history against threat intelligence databases, looks for mixer interactions and sanctioned address links

PDV (Private Data Verification) generates a ZKP (zero-knowledge proof) so verification results can be shared without exposing sensitive details. QCV (Quantum Cryptography Verification) is an optional extension for long-lived sensitive data.

Risk scoring. Overall score is the average of applicable verification scores, on a 0–100 scale where 0 is safest. Low Risk is 0–20; Critical is 81–100. That’s a risk score, not a trust score: lower is better.

Final status means the spec is stable enough to implement against. It doesn’t mean existing verification providers are high quality.

ERC-8196: AI Agent Authenticated Wallet

Having an agent’s identity (ERC-8004) and risk score (ERC-8126) still leaves the execution scope problem open. A private key gives an agent unconstrained access to all funds in the wallet. ERC-8196 defines a policy structure that sits in front of execution: the owner registers permitted actions, a contract allowlist, per-transaction and daily spending limits, and an expiry time. The smart wallet checks the active policy before executing any agent request. The agent receives a scoped delegation, not a key.

ERC-8196 (Review) defines this execution layer. Author: Leigh Cronian. Instead of handing an agent a private key, the owner registers a policy that constrains what the agent can do.

Policy fields:

agentAddress    → the authorized AI agent
ownerAddress    → the asset owner / delegator
allowedActions  → ["transfer", "swap", ...]
allowedContracts → address[] allowlist
blockedContracts → address[] blocklist
maxValuePerTx   → per-transaction ceiling
maxValuePerDay  → daily spending limit
validAfter      → policy start time
validUntil      → policy expiry
minVerificationScore → max allowable ERC-8126 risk score

The minVerificationScore name is confusing. In ERC-8126, lower score means safer. So this field is actually a ceiling on acceptable risk. Set it to 20, and only Low Risk agents (score 0–20) can execute automatically.

Audit trail. Each audit entry includes previousHash, forming a hash chain. Entries can live on IPFS with periodic Merkle roots posted to ERC-8004’s Validation Registry. The chain detects tampering: delete or alter any entry and the subsequent hashes break.

EIP-712 signing. Actions and delegations use typed data signing, so users can read what they’re approving rather than signing a blind hash.

EIP-4337 compatible. Can be implemented as an account abstraction wallet or a policy enforcement module over an existing AA wallet.

How they fit together

ERC-8004  →  who is this agent? (identity, reputation, validation records)
     |
ERC-8126  →  is this agent safe? (wallet, code, web, media risk score)
     |
ERC-8196  →  is this specific action allowed by the owner's policy?
     |
     →  transaction execution

Each layer is independent. You can use ERC-8004 without ERC-8196. But for high-value automated transactions, using all three gives you a traceable path from “who is this agent” through “what is its risk score” to “did the wallet authorize this specific action.”

Honest caveats

  • ERC-8004 is deployed on mainnet but its ethereum/ercs process status remains Draft; the interface specification may still change.
  • ERC-8196 is in Review; its interface and security model may change.
  • A low ERC-8126 risk score reflects verification at a point in time, not a guarantee of good intentions.
  • Reputation is Sybil-attackable without careful client filtering.
  • Host manipulation isn’t fully eliminated by ERC-8196. The paper recommends multiple independent hosts for high-value agents.
  • Verification provider quality varies. A Final ERC-8126 spec doesn’t validate the providers implementing it.

Further reading

References

Tags :
Share :

Related Posts

Future AGI: Evaluate, Observe, and Improve AI Agents in One Place

If you have shipped an AI agent, this will sound familiar. The demo runs fine. Then it hits production, the hallucinations start, and you can’t tell what went wrong or why. So you bolt on one tool for evals, another for tracing, another for guardrails. The real problem is that none of them talk to each other, so the loop you need to actually fix things never closes.

Read More

Open Knowledge Format: A Shared Vocabulary for Agent Knowledge

When AI agents fail in production, the model is often not the problem. The missing context is. Table schemas, metric definitions, runbooks, join paths between systems, and API deprecation notices are scattered across catalog vendors, internal wikis, code comments, and personal notes. Every agent developer solves the same context assembly problem from scratch.

Read More