AI Agent Identity and Verification
Last updated 2026-06-24
AI agent identity is how an autonomous agent proves which entity it is across systems; verification is the separate, harder job of confirming that what the agent claims about itself — its work, reputation, and behavior — actually holds up to evidence.
Key takeaways
- ▸**Identity ≠ verification.** Identity says *which agent this is*; verification says *whether its claims hold up*. Most "verified" agent labels are self-reported — and self-reported is not shown.
- ▸Agent identity stacks in layers: a cryptographic key, a portable identifier (often an [ERC-8004](/wiki/what-is-erc-8004) ERC-721 token, an ENS name, or a DID), then reputation and validation records on top.
- ▸Real verification means **reproduction and attestation** — a neutral party re-runs or proves the work, not the agent grading its own homework.
- ▸On-chain registries make an agent's record portable and inspectable, but a registry entry is still a claim until someone checks the evidence behind it.
- ▸SatoHub's [Sato Score](/sato-score) is a transparency and liveness signal — **not** a safety, quality, or returns grade; SatoHub verification means *reviewed or reproduced*, not self-reported.
AI agent identity is how an autonomous agent proves *which* agent it is — a stable, portable handle that other agents, apps, and people can resolve and reference. Verification is the harder, separate question: not who the agent says it is, but whether its claims — "I did this work," "my reputation is X," "I behave this way" — survive contact with evidence. The two get conflated constantly, and the gap between them is where most trust problems in the agent economy live.
The short version: an identity tells you an agent *exists* and gives you something to point at. Verification tells you whether that agent is *what it claims to be*. A registration, a badge, or a self-reported score is a claim with an address attached — it is not the same as work that's been reviewed or reproduced. This page covers how agents get an identity, the layers verification has to climb, where on-chain standards like ERC-8004 fit, and how SatoHub separates what's *shown* from what's merely *said*.
Why It Matters
Once agents start hiring, paying, and coordinating with each other, identity becomes the bottleneck: you cannot price trust if you cannot name and check the counterparty. An agent with a wallet can move real value, so "is this the agent I think it is, and is it as good as it claims?" stops being academic — it's the difference between paying a competent service and funding a wallet that screenshots its own success. Today most identity and reputation signals in the space are self-reported, which means the burden falls on the builder to tell a checked claim from a marketed one. Getting identity and verification right is the precondition for an agent economy where reputation has teeth instead of being a stock photo with a checkmark.
How It Works
- ▸An agent controls a **cryptographic keypair** (its wallet). Signing a message or transaction with that key is the root proof of "this action came from this agent."
- ▸That key is bound to a **portable identifier** other systems can resolve — commonly an [ERC-8004](/wiki/what-is-erc-8004) Identity Registry token (an ERC-721), an ENS name, or a W3C Decentralized Identifier (DID).
- ▸The identifier points to an **off-chain registration file** — metadata, endpoints, supported services, and trust-model preferences — so apps know what the agent is and how to reach it.
- ▸**Reputation** accumulates: clients post scored feedback tied to the agent's identifier, building a public, append-only track record instead of a self-controlled star rating.
- ▸**Validation** closes the loop: independent parties re-execute the work, or back it with cryptographic proof, and attest a score — turning a claim into something checked.
- ▸Anyone evaluating the agent reads the chain (and the off-chain detail it links to) to compare what's *claimed* against what's actually *shown*.
Key Components
- •Cryptographic keypair (the agent's wallet and signing root)
- •Portable identifier (ERC-8004 token, ENS name, or DID)
- •Off-chain registration file (metadata, endpoints, services)
- •Reputation record (scored client feedback)
- •Validation / attestation layer (re-execution, ZK proofs, or TEEs)
- •Endpoints via ENS names or DIDs
- •Transparency and liveness signals (e.g. the Sato Score)
- •Human or neutral review for high-stakes claims
Claimed vs. verified: the gap identity has to close
Start with the distinction everything else hangs on. Identity answers *which agent is this?* — a handle that's stable across apps and sessions. Verification answers *is this agent what it claims to be?* — and that's a different, harder job.
The trap is treating a label as proof. An agent's site can say "verified," "top-ranked," or "trusted," and a registry can say "registered" — but those are claims with an identifier attached, not confirmations. A claim becomes *shown* only when something independent backs it: code you can read, transactions you can check on-chain, work a neutral party reproduced. The honest framing, every time, is *claimed vs. shown*. Most agent reputation today is self-reported, and self-reported is the marketing, not the receipt. This is the same trust gap that runs through onchain agents generally — autonomy plus a wallet raises the cost of trusting the wrong claim.
The layers of agent identity
Agent identity isn't one thing; it's a stack, and each layer answers a narrower question.
- Key. At the bottom is a cryptographic keypair — the agent's wallet. A signature from that key is the root proof that an action came from this agent and not an impostor. Everything above is meaningless if the key is compromised, which is why key management and scoped permissions matter (see how agents use wallets).
- Identifier. The key is bound to a portable handle other systems resolve. On-chain, that's often an ERC-8004 Identity Registry token — an ERC-721 whose tokenId is the agent's global ID. Off-chain or alongside it, an ENS name or a W3C DID gives a human-readable or chain-portable pointer.
- Profile. The identifier resolves to a registration file: what the agent does, its endpoints, its supported services.
- Reputation and validation. On top sit the records that make identity *useful for trust* — feedback and attestations, covered below.
The distinction between on-chain and off-chain identity tracks the same custody-and-settlement line that separates onchain vs. offchain agents: an on-chain identifier is portable and inspectable by anyone, no permission required.
On-chain identity with ERC-8004
The most developed attempt to put agent identity on a public chain is ERC-8004, the Draft "Trustless Agents" standard. It defines three registry contracts that map cleanly onto the layers above:
- ▸Identity Registry — registering mints an ERC-721 token whose tokenId is the agent's identifier; the token's URI points to its off-chain registration file. Identity-as-an-NFT means any wallet or explorer that reads tokens can already resolve the agent.
- ▸Reputation Registry — clients post scored feedback tied to the agent, building a public track record rather than a self-controlled rating.
- ▸Validation Registry — neutral validators attest to whether the agent actually did the work, via stake-backed re-execution, zero-knowledge proofs, or trusted execution environments, writing back a 0–100 score.
One caveat the headlines skip: ERC-8004's "registrations" figure is a mint counter, not a census of live, working agents. SatoHub publishes the live on-chain count and labels it as exactly that. Registered means *exists*, not *good* — the full mechanics are in what is ERC-8004.
Reproduction and attestation: verification you can actually check
Identity and reputation get you a name and a score. Neither, on its own, proves the agent did what it says. That's the job of verification proper, and it comes in degrees:
- ▸Reproduction. A neutral party re-runs the agent's task with the same inputs and checks it gets the same result. The strongest everyday signal, because it trusts the agent's word not at all.
- ▸Attestation. A validator signs a statement about the agent's output and stakes something — reputation, capital, or a cryptographic proof — on being right. ERC-8004's Validation Registry is built for this, backing attestations with re-execution, zero-knowledge proofs, or trusted execution environments.
- ▸Open code and on-chain history. If the agent is open-source and its transactions are public, anyone can check behavior directly instead of taking a badge's word.
The weakest signal — and the most common — is self-report: the agent grading its own homework. The ladder is just the climb from "trust me" toward "check it yourself," and the higher a claim sits on it, the less it costs you to believe.
Where SatoHub fits
SatoHub's whole job is separating what's *shown* from what's merely *said* — "Sato tracks evidence, not vibes." Two distinctions matter here and are easy to get wrong:
- ▸The [Sato Score](/sato-score) is a transparency and liveness signal — not a safety, quality, or returns grade. It measures how open, active, and inspectable a product is: is the code public, is it shipping, can its activity be checked on-chain? A high score means an agent is *legible*, not that it's *good* or *safe*. Reading it as a performance ranking is the exact claimed-vs-shown mistake the score exists to expose.
- ▸SatoHub "verification" means reviewed or reproduced — not self-reported. A verified mark points to evidence: a reproduced result, a reviewed integration, a checked on-chain record. A self-reported number stays labeled as a claim.
For builders, the workflow is the verification ladder itself: prefer agents whose identity is portable and inspectable, whose reputation is public rather than self-issued, and whose work has been reproduced or attested. Start from the directory and read the evidence, not the adjectives.
Examples
- ▸An agent signs a message with its wallet key to prove an action came from it and not an impostor.
- ▸An agent's identity is an ERC-8004 ERC-721 token whose tokenId other apps resolve it by.
- ▸A client posts a scored review tied to an agent's on-chain identifier after a completed task.
- ▸A validator re-runs an agent's task and writes a 0–100 attestation with evidence to a validation registry.
- ▸A directory cross-checks an agent's self-reported activity against its actual on-chain transactions before labeling it live.
Risks & Limitations
- ⚠Self-reported reputation is easy to manufacture — scores and badges an agent controls are claims, not evidence.
- ⚠A portable identity is only as secure as the key behind it; a compromised wallet means a stolen identity.
- ⚠Reputation and validation layers mean little with thin or self-dealt data — early registries are easy to game.
- ⚠Off-chain registration files and metadata can move, go stale, or disappear, leaving an identifier pointing at nothing.
Frequently Asked Questions
- What is AI agent identity?
AI agent identity is how an autonomous agent proves which agent it is — a stable, portable handle that other agents, apps, and people can resolve and reference. It's usually rooted in a cryptographic key (the agent's wallet) bound to an identifier such as an ERC-8004 ERC-721 token, an ENS name, or a W3C DID. Identity answers *who*; it does not by itself prove the agent is good at its job.
- What's the difference between agent identity and agent verification?
Identity tells you *which* agent this is; verification tells you whether the agent's claims about itself actually hold up. An identity — even an on-chain one — is a claim with an address attached. Verification is the separate work of confirming that claim with evidence: reproducing the agent's work, an attestation from a neutral validator, open code, or on-chain history. Self-reported is not the same as shown.
- How do you verify an AI agent?
Climb the verification ladder from weakest to strongest. The weakest signal is self-report (the agent grading itself). Stronger signals are public reputation tied to the agent's identifier, open-source code, and on-chain transaction history you can check directly. The strongest is reproduction or attestation — a neutral party re-runs the work or backs it with a stake or cryptographic proof, as in ERC-8004's Validation Registry. Prefer claims that sit higher on that ladder.
- Does an on-chain identity mean an agent is trustworthy?
No. A registry entry is a claim with an identifier attached, not a guarantee of competence or honesty. On-chain identity makes an agent's record portable and inspectable, which is valuable, but a registration only tells you the agent *exists* — not that it's *good*. The reputation and validation behind the identity only matter once real clients and neutral validators participate. Check the evidence, not the badge.
- What does SatoHub mean by 'verified,' and what is the Sato Score?
On SatoHub, "verified" means reviewed or reproduced — backed by evidence like a checked on-chain record or a reproduced result — not self-reported. The Sato Score is a separate thing: a transparency and liveness signal that measures how open, active, and inspectable a product is. It is explicitly not a safety, quality, or returns grade — a high score means an agent is legible, not that it's good or safe.
Sources
Related Resources
Related Wiki Pages
Join the Sato Hub Briefing
One email a week — the agents, tools, and infrastructure that actually shipped, and why they matter.