What Does an AI Agent’s On-Chain Identity Prove, and What Does It Not?

An AI agent's on-chain identity proves that a particular registration exists and who controls its identifier or linked wallet. It does not prove honesty, functioning capabilities, or that the same model is running today. Trust requires separate signals: endpoint verification, reputation, output validation, and constrained permissions.

Why does an agent need a portable identifier?#

Users need a stable way to distinguish a service from namesakes, find its endpoint, and connect past feedback. An on-chain registry creates a public identifier controlled by an owner. This helps discovery across organizations that share no directory or pre-existing trust.

How does ERC-8004 separate trust layers?#

Draft ERC-8004 proposes Identity, Reputation, and Validation registries. An identifier links to a registration file and verified agent wallet. Feedback is posted separately, while validators can record re-execution, zkML, TEE, or another check on specific work.

Why is registration not certification?#

The owner can update the URI or endpoint and can transfer the identity. The standard cannot guarantee that advertised capabilities work or are safe. Positive feedback is not absolute either: cheap Sybil addresses can imitate popularity when an aggregator does not evaluate reviewer quality.

What are the limits and risks?#

A new registration has little history, while an old one may have changed owners. A validator checks only the declared method and inputs, so the result cannot automatically cover another task. Payments and key access need spending limits, allow-lists, escrow, and a stop mechanism; identity is only one control layer.

What are the key takeaways?#

• Identity supports discovery but does not guarantee behavior.
• A record owner can update metadata and endpoints.
• Reputation remains vulnerable to Sybil activity and collusion.
• Validation checks specific work, not all future actions.
• Trust depth should match the value at risk.