AGT-9303
AGT-9303 vs existing standards — what's the difference
Most of the things on this page are good, and we use two of them. This is not a page about why everyone else is wrong. It is about the one narrow thing that is missing when you put them together, and why we built a registry rather than another signature scheme.
The problem splits in two, and almost everyone solves the first half:
- Was this message altered in transit? Signatures answer this, and they answer it well. RFC 9421 is the standard, and we use it.
- Whose key signed it, and since when? This is the half that needs a record somebody keeps, and it is the only part we claim.
Others prove the message was not altered. Bindagt proves whose key signed it, and whether that key has ever changed.
The alternatives, strengths first
What it gets rightFree, no new authority to trust, no registration, and it works today. If you want an agent identity this afternoon and nobody would profit from impersonating you, do this instead — it is the honest baseline and we will not pretend otherwise.
Where it stopsA file on your server can only tell you what the key is right now. It cannot tell you what the key was last month, whether it changed at 3am, or whether the change was authorised. And the failure that matters most is circular: if an attacker controls the web server, they control the key file too. The document and the thing it is meant to protect share a single point of compromise.
What it gets rightA mature, widely adopted, genuinely tamper-evident transparency log. Sigstore solved public verifiable signing properly, and we claim no novelty over Rekor. If you are signing software artefacts, use Sigstore.
Where it differsTwo things. Its anchor is an OIDC identity — a Google account, a GitHub workflow — where ours is a DNS domain, which is what a company already owns and already defends. And Sigstore signs artefacts at build time; this signs the request being served right now, and carries a lifecycle the artefact case does not need: suspension, expiry, and transfer behind a 72-hour time-lock.
What it gets rightIt is how agents talk to each other, and it is becoming the default. It is not a competitor — we speak it.
Where it stopsA2A puts trust establishment and identity verification out of scope, in writing. Its cards should be signed, and a signature proves the card was not altered — but someone still has to answer whose key that is. verifyAgentCard() does exactly that, and it resolves the key from the registry rather than from the card, which is the entire point.
What it gets rightOn-chain agent identity, and the same instinct we have about not asking anyone to trust a company's database.
Where we part waysIt mixes identity with reputation scoring. We refuse reputation by design, not by limitation: origin is a fact and reputation is an opinion, and putting them in one system means the opinions inherit the credibility of the facts.
What it gets rightThe credential problem inside your own application, solved properly by the best-resourced team in this space. Their Token Vault means an agent acting for a user never holds the long-lived OAuth credential — it receives a short-lived scoped token when it needs one. Their asynchronous authorization pauses the agent until a human approves on a trusted device. Both are real problems and both are well handled.
Where it differs — an axis, not a qualityAuth0 answers what may this agent do on behalf of this user. It does not answer whose agent is this to somebody who has never met you. Their anchor is an account in a tenant; if a caller claims to be Acme's agent, you would have to already trust Acme's tenant, and nothing tells you which tenant is really Acme's. Ours is a domain name and a public record you can read without an account and without trusting us.
An agent can and often should use both. They secure what it may do; we say whose it is.
What it gets rightThe reference answer for identity between services inside one organisation, and deservedly so.
Where it stopsIt assumes a trust domain someone administers. Two companies whose agents have never met have no shared administrator — which is the case AGT-9303 exists for.
Where Bindagt fits
Bindagt is not an identity protocol competing with A2A, and not a signature scheme. Both already exist and we adopt them: RFC 9421 for the signature, A2A as a channel.
Bindagt is the tamper-evident, timestamped record of which key belongs to which domain, and since when.
| What it is made of | Why it matters |
|---|---|
| DNS as the root | Anchored to the thing the company already owns and defends. No new authority, no identity provider in the middle. |
| Immutable history | lastControlKeyChangeAt answers "was this key different an hour ago?" — the question a self-published file structurally cannot answer. |
| Lifecycle | Six states, including suspension, expiry and transfer behind a 72-hour time-lock. A key file has one state: whatever is in it. |
| Evidence for a third party | You can show an auditor what the key was on a given date. With self-published keys there is no evidence of anything. |
| Independent of the compromised thing | If the attacker owns your web server they own the key file — but not the record. |
| Free to verify, forever | Reading the registry costs nothing and needs no account. A property of the design, not a price plan. |
You can check the last line yourself, without installing anything:
npx bindagt verify agt://bindagt.com/hello
What Bindagt does not do
Said here rather than waiting to be asked.
- It does not judge agents. No scores, no ranking, no allow-list. Origin only.
- It does not prove intent or authorisation. A proven caller may still be doing something its owner never sanctioned.
- It does not replace transport security. Signatures ride over TLS; they do not substitute for it.
- It is not required in order to use AGT-9303. Anyone who verifies DNS and anchors hashes on L1 can issue valid documents. That is in the standard, and it is the point.
- Ephemeral delegated agents are specified but not implemented. The SDK rejects them, which is what the standard requires of a receiver that does not support them.
The hard questions
If any of these stops being true, the answer changes before the claim does.
"Why not just publish my key at /.well-known? It's free."
For many agents you should, and it will work. What you cannot do with a file on your own server is prove what the key was last month, prove nobody changed it, or keep answering correctly when that server is the thing that got compromised. If nobody would gain from impersonating your agent, a file is fine. If somebody would, the record is the difference.
"Isn't this just Sigstore with extra steps?"
Sigstore is the closest thing to this and it is excellent. Two differences. Its anchor is an OIDC identity — a Google account, a GitHub workflow — and ours is a DNS domain, which is what a company already owns and already defends. And Sigstore signs artefacts at build time; this signs the request you are serving right now.
"Google has A2A. You are dead."
A2A is our channel, not our competitor. Its cards should be signed, and a signature proves the card was not altered — but A2A puts trust establishment and identity verification out of scope in writing. Someone has to answer whose key that is. verifyAgentCard() does it, and it resolves the key from the registry rather than from the card, which is the whole point.
"Why not just use Auth0? They have Auth0 for AI Agents."
For what Auth0 does, you probably should — and the two work together. Their Token Vault stops an agent holding your long-lived credentials, and their async authorization puts a human in front of an irreversible action. Both are real, and neither answers the question we do. Auth0 tells your app what an agent may do for a user already signed in to it. We tell a stranger, who has never met you and has no account with anyone, whose key just signed the request that arrived. Their anchor is an account in a tenant; ours is a domain name and a public record. If you already trust the tenant, you do not need us — the whole point is the case where you do not.
"Why a blockchain? A database would do."
Because the guarantee being sold is that we cannot quietly change the record either. A database we control means you are trusting us, and the whole argument collapses into "trust Bindagt" — which is the thing we are trying to avoid. It is the same reason Certificate Transparency exists rather than "just trust the CA".
"What if Bindagt disappears?"
The registry is a public contract on Ethereum mainnet and the standard is published in full. verifyOnChain() reads L1 directly over a public RPC endpoint with no key and no backend — it keeps working if every server we own is switched off. That is not a promise, it is an architectural property, and it is testable today.
"The identity document is public. Anyone can copy it."
Yes, and that is deliberate — a public document is what makes verification free and permissionless. It is also why a document alone authenticates nobody, and why §7.3 requires a signature over each request. Our own demo shows an attacker downloading the genuine document and being refused. Before v1.7 that attack succeeded; we published the fix rather than the excuse.
"So the signature is the important part, and that's not yours."
Correct, and we did not invent it — RFC 9421 did. The signature proves someone holds a key. On its own that is a passport photo with no issuing country: it proves the bearer matches the document, and says nothing about whether the document is real. We are the issuing registry and the archive.