SKIP TO CONTENT
AI AGENTS6 minStandards That Ship / Ep. 10 · Stage 10-4

Agent Card and ERC-8004: How to Check They Belong Together

Anyone can register an agent and point it at somebody else’s card. One file on the card’s domain tells you which entry it accepts.

XIN
Pixel-art night scene at a city gate: a small robot courier holds up a glowing sealed card while a gatekeeper compares its seal to a carved stone registry tablet. A thin cyan thread links card and tablet, and the gate stays shut.

IN 30 SECONDS

Binding an Agent Card to an ERC-8004 entry is checking the link both ways: the file names the card, and the card’s domain names the entry. Then you run eight checks and stop at identity.

KEY TAKEAWAYS · 3

  • You tie the card and the entry yourself: the registration file lists the card’s URL, and the card’s domain lists the entry back.
  • The return check is optional in the ERC-8004 Draft and not needed on a shared domain. Without the return check or a shared domain, anyone can point an entry at your card.
  • The last of the eight checks is to stop: you know who published the agent, not that it may act.
On this page

How do you tie the card to the on-chain entry?

IN SHORT Neither document points to the other with a signature, so you check the link yourself, in both directions.

WORDS TO KNOW

Agent Card
A small JSON file in which an agent describes itself. It may be signed.
ERC-8004 entry
An on-chain record from the ERC-8004 Draft: a transferable token with an owner and a link to a file.
Registration file
The file an ERC-8004 entry links to. It lists the agent’s services, such as its card URL.

The core A2A Agent Card A small JSON file in which an agent describes itself. It may be signed. See the glossary has no field for an on-chain registry. And an ERC-8004 entry An on-chain record from the ERC-8004 Draft: a transferable token with an owner and a link to a file. See the glossary, from a Draft that can still change (read the current file before you build), links to a registration file that lists the card’s URL.

BINDING CARD AND ENTRY

Sequence diagram: 4 participants: You, checking, On-chain registry, File host, Agent’s domainSequence diagram: 4 participants: You, checking, On-chain registry, File host, Agent’s domain. Step 1: You, checking to On-chain registry, Who owns agent 42? Where’s its file?. Step 2: On-chain registry to You, checking, Owner, link, wallet. Step 3: You, checking to File host, Fetch the file. Step 4: You, checking to itself, Find the A2A service. Step 5: You, checking to Agent’s domain, Check the signed card. Step 6: You, checking to Agent’s domain, Fetch its list of entries. Step 7: Agent’s domain to You, checking, Same registry and agentId.YOU, CHECKING > ON-CHAINREGISTRYWho owns agent 42? Where’s itsfile?ON-CHAIN REGISTRY > YOU,CHECKINGOwner, link, walletYOU, CHECKING > FILE HOSTFetch the fileYOU, CHECKING > YOU, CHECKINGFind the A2A serviceThis agentId and this cardURL?YOU, CHECKING > AGENT’SDOMAINCheck the signed cardYOU, CHECKING > AGENT’SDOMAINFetch its list of entriesUnless same domainAGENT’S DOMAIN > YOU,CHECKINGSame registry and agentId

Step 1. Read the registry. Get the owner, the link and the payment wallet.

Pick a step to see it move
  1. Read the registry Get the owner, the link and the payment wallet.
  2. Fetch the file Download the file the link points to.
  3. Forward check It must list this agentId and this exact card URL.
  4. Verify the card Check the card’s signature with the key you pinned (my policy).
  5. Return check The card’s domain must list the same registry and agentId back, unless it shares the file’s domain.
One verification pass, as I’d run it. The return check is the optional Endpoint Domain Verification from the ERC-8004 Draft.

IN PLAIN WORDS

The entry says “my card is here”. The card’s domain confirms “that entry is mine”, unless both share one domain.

For that optional return check, the domain publishes /.well-known/agent-registration.json with the same registry and agentId. If the card sits on the same domain as the Registration file The file an ERC-8004 entry links to. It lists the agent’s services, such as its card URL. See the glossary, the Draft says the check isn’t needed, because domain control is already shown.

Without either, anyone can register an agent and point it at somebody else’s card. Also, the Draft’s own example says A2A 0.3.0, while the current release is v1.0.1, from May 2026: trust the protocolVersion in the card’s supportedInterfaces.

Coming up next: What does a fake link look like in practice?

A worked example: same card, two entries

IN SHORT The same real card can sit behind two entries, and here only the return check tells you which one the card’s domain accepts.

A WORKED EXAMPLE

Illustrative numbers

PASSExample Ops’ agent, checked end to end

INPUT

Card
https://agent.example/.well-known/agent-card.json
Entry
agentId 42 on eip155:1:0x742...

WHAT HAPPENS

  1. The card’s signature verifies with the pinned key.
  2. The registration file lists agentId 42 and this card URL.
  3. agent.example’s agent-registration.json lists agentId 42 back.

OUTPUT

Result
bound: the card’s domain lists this entry
Still to check
mandate and live caller

NOT BOUNDSomeone else registers agentId 977, pointing at the same card

INPUT

Entry
agentId 977, another owner
Card
same URL as above

WHAT HAPPENS

  1. The card still verifies: it is the real card.
  2. The new file lists the card URL: the forward check passes.
  3. agent.example’s list names only agentId 42.

OUTPUT

Result
reject agentId 977 as this agent

Anyone can reuse a signed card and link to it. Only the card’s domain can publish the file that lists the entry back.

Coming up next: So in what order do you run all of this?

The checklist I’d run before trusting an agent

IN SHORT Eight checks I’d run in a fixed order, each with an action when it fails, and the last one is to stop: identity, not permission.

1. Card signature
One signature verifies over the canonical copy, with a key you pinned (my policy)
Unverified claims only
2. Key status
The key is current, not expired or revoked
Reject: the spec says such keys MUST NOT be used
3. Entry exists
The registry returns an owner and a link for the agentId, on the expected chain
No usable on-chain entry: card only
4. Forward link
Registration file lists this agentId and this card URL
Binding not established
5. Return link
Same domain, or agent-registration.json matches
May point at a card it doesn’t control
6. Ownership stable
No Transfer since your last review; payment wallet as expected
Re-vet: the operator may have changed
7. Reputation
Score filtered by reviewers you trust
Ignore unfiltered scores
8. Stop here
You know who published the agent
Mandate and caller checks come next

ITEM GET

Never let the document pick its own trust anchor

A card that names its own key URL, an entry that names its own card, a score from unnamed reviewers: each verifies cleanly and proves nothing alone.

FAQ

No. It shows who registered the agent, who owns the registration and which file it points to. ERC-8004 is a Draft that says it cannot cryptographically guarantee that advertised capabilities are functional and non-malicious. Authority comes from a mandate: who delegated, for what scope, cap and expiry.

Sources, re-read on 7 October 2026: ERC-8004 (Draft), A2A specification v1.0.1. Not legal advice.

STAGE CLEAR

What you now know

  • You bind a card and an entry by checking the link both ways.
  • The return check catches an entry that points at someone else’s card.
  • Eight checks in order end with a stop: identity, not permission.

Check yourself

Tap or click a question to see the answer.

The registration file sits on the card’s own domain, which has no agent-registration.json. Do you reject the binding?

Not for that reason. On a shared domain the Draft says the return check isn’t needed: domain control is already shown.

You finished every stage published so far in this series. Back to the series map

Adam Boudjemaa
Adam Boudjemaa

Web3 x AI engineer, former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft.

Have a project to ship or a role to fill?

Discuss your project or role

My work at the web3 x AI intersectionOpen-source tools I build

LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.