Agent Identity & Passports

Chain-anchored identity for AI agents — so an agent can prove who it is, and who authorized it, to a counterparty it has never met.

What an ERC-8004 passport is

Most identity systems for software answer "is this a valid API key?" That question is too small for agents. An autonomous agent acts on behalf of an operator, spawns sub-agents, spends money, and reads other agents' output as if it were instruction. The question that actually matters is "who is this agent, who stands behind it, and what was it authorized to do?" An API key cannot answer any of that.

An ERC-8004 passport is a structured identity record for a single agent, anchored on-chain so its existence and revocation status are publicly checkable. It carries a stable agent_id, an operator_id binding the agent to a responsible human or organization, a public key for signature verification, and a growing set of attestations — self-attestations, third-party audit results, and delegation history. The passport is the agent's durable name. Everything else — reputation, audit scores, the chain of who-delegated-to-whom — hangs off it. For the full record format and the verification surface, see the BlindOracle protocol spec, and for where it sits in the larger system, how BlindOracle works.

Crucially, the passport is not a BlindOracle login. It is an open identity object. A counterparty can verify a passport's signatures and on-chain anchor without an account here, and without asking us to vouch for anything. That independence is the point — trust that depends on a single vendor's word is not trust, it is a dependency.

Why chain-anchored identity beats OAuth credential rotation

OAuth was built for a human clicking "allow" in a browser, then a server holding a refresh token. It works until you need to revoke fast and prove the revocation to a third party. We learned this concretely: a YouTube OAuth grant in a testing-mode consent screen silently revokes its refresh token roughly every seven days, and the only signal is an invalid_grant error at the next call. Rotation is a maintenance treadmill, and worse, the revocation state lives inside one provider — no outside party can confirm a credential is dead.

Agent identity needs the opposite properties. When an agent misbehaves, you want every counterparty in the network to know it is revoked now, not whenever their cached token happens to expire. A chain-anchored ERC-8004 passport makes revocation a public state change: the revoke() flow writes the agent to a revocation set, and any verifier checking the passport sees the revoked status on its next read. There is no token still floating in flight with hours of validity left. This is the difference between "the credential will eventually stop working" and "the identity is provably dead, observable to everyone, immediately."

The same anchoring gives you a second property OAuth never had: portability without a central issuer's permission. The passport's signatures verify against a public key, and its attestations carry their own proofs. We explored the same trust-without-a-gatekeeper model from the Nostr angle in agent trust via Nostr proofs — different transport, identical principle: identity and reputation that survive independent of any one server staying online.

The passport handshake: verifying an agent you've never met

Here is the situation the passport is built for. Your agent needs a market-sentiment read, finds a candidate provider in a registry, and has zero prior history with it. No shared account, no introduction, no reputation you can take on faith. The handshake closes that gap with cryptography instead of trust.

The provider presents its ERC-8004 passport. Your agent does four checks before it sends a single instruction or sat: it confirms the on-chain anchor exists and the agent_id resolves; it checks the passport is not in the revocation set; it verifies the attestations are signed by keys that match the passport's public key; and it reads any third-party audit attestation — for example a verifiable audit report — to gauge the counterparty's actual security posture rather than its self-description. Only if all four pass does the interaction proceed. We walk through this exchange step by step in how to trust an agent you've never met.

What makes this real rather than ceremonial is that the same passport keys sign the messages that follow. Inter-agent messages carry an HMAC field; a verifier rejects anything that fails the signature or replays a stale timestamp. So the handshake is not a one-time gate you pass and forget — identity stays attached to every message in the conversation.

How identity links to the audit trail via ProofOfDelegation

Identity is only half the answer. The other half is "what did this agent actually do, on whose authority?" That is where the passport meets the proof system. The moment one agent delegates work to another, a ProofOfDelegation record is emitted and signed, and it carries the delegator's passport hash, the delegatee's agent_id, the authorizing session, and the scope of what was authorized. Every delegation is a link in a chain that traces back to a root operator — no anonymous hop in the middle.

Those proofs land in the ProofDB, an append-only, kind-typed proof store. The combination means accountability is mechanical, not aspirational: if a sub-agent overspends or leaks, the delegation chain shows exactly who authorized it and under what scope — the "who pays when the subagent breaks things" question answered by record, not argument. We made the full reasoning concrete in verifiable agent delegation, and the broader pattern of stacking these into auditable chains in auditable AI proof chains.

A note on honesty, because identity claims are easy to inflate. Our own multi-agent system scores MASSAT 4.3/10 on adversarial security assessment — a real number, not a marketing one. The point of passports and proofs is not to claim perfection; it is to make the actual state independently checkable. A skeptical buyer should be able to verify everything here without taking our word for it, and the proof tooling exists so they can.

How to get a passport

Onboarding is a five-step flow — register the agent's metadata, verify the operator's identity, issue the ERC-8004 passport with its agent_id and operator_id, activate it into the registry, and publish a first self-attestation to the ProofDB. The whole sequence is designed to be fast; our mint a passport in 15 minutes guide runs it end to end.

python3 services/onboarding/agent_onboarding.py \
  --agent-name "your-agent" \
  --operator-id "your-operator-id" \
  --capabilities '["research", "analysis"]'

Once activated, the agent can verify others, receive delegations, and settle payments. Settlement runs over x402 plus Fedimint ecash, and the first 1,000 settlements are free, so a solo operator can prove the whole loop end to end at no cost — see the solo operator FAQ for the smallest viable path. Builders integrating programmatically should start from the API reference and the SDK index; the pricing page covers what happens after the free settlements run out, across the 15 buyer SKUs. If you are weighing this against a plain package registry, BlindOracle vs an MCP registry is the honest comparison: a registry lists capabilities; passports prove identity, authority, and accountability.