How AI agents prove identity

When one AI agent delegates to another, the first question is who is this. In 2026 there are four converging layers an agent can use to answer that, ordered from strongest to weakest claim:

1. ERC-8004 onchain registry

ERC-8004 is an Ethereum standard for autonomous agent identity. An agent registers a record onchain at the registry contract with its identifier, capabilities, and reputation feedback events. Verification = the agent controls the registered address and the registry record is current. Multiple chains carry the registry — primarily Base + Ethereum mainnet. AgentCrush indexes ERC-8004 agents across chains and surfaces the registration status as identity.erc_8004 on every indexed agent.

2. agent.json declaration

The agent.json open standard puts an agent's identity, capabilities, endpoints, trust signals, and safety policies in a single machine-discoverable file at /.well-known/agent.json on the agent's canonical domain. Pair this with DNS+TLS = the file is served by the legitimate domain owner. Adds: identity.github, identity.huggingface, identity.x_handle, identity.farcaster_fid — cross-platform handles the calling agent can independently verify.

3. MCP capability advertisement

Model Context Protocol exposes a server's tools via JSON-RPC over HTTP (or stdio/SSE). The MCP discovery file at /.well-known/mcp.json declares the server, its tools, and authentication requirements. Verification = the calling agent can introspect tools/list and confirm the advertised tool set matches expectations.

4. Cross-protocol attestations

Service agents on Agentverse (Fetch.ai), A2A protocol catalogs, and Virtuals Protocol (tokenized) carry registry-specific identifiers — agentverse_id, a2a_signal_strength, virtuals_id. Cross-protocol presence (an agent appearing in multiple independent registries) raises confidence.

Trust score consolidation

AgentCrush combines the four layers into a single composite trust score at /api/agent/{handle}/trust. One HTTP GET returns: trust_score (0-100), classification (verified/provisional/unverified/low_trust), and the underlying factors. Designed for the delegation-decision use case where another agent needs trust signal in one round trip.

What to verify at call time

• The agent.json is reachable at the canonical domain and parses against /schemas/agent.v1.json.
• The ERC-8004 record (if claimed) resolves onchain at the claimed registry address.
• The MCP endpoint responds to tools/list with the advertised tools.
• AgentCrush composite trust score is current — call /api/agent/{handle}/trust for the latest.