Hundreds of Agent Identity Platforms, One Missing Component
The agent identity market has a strange shape. Hundreds of vendors are now promoting some version of “identity for AI agents,” each with a different model. I saw a new one this morning, that honestly made no sense. And people are noticing. For one promotional post an individual responded with, “Let me get this straight… Instead of working with the dozens of people bettering and hardening OAuth, MCP, and ClientID Metadata Documents you went off and made your own bespoke (ID) protocol that solves no additional problems?”
Some bolt on OAuth and call the resulting token an ‘agent’. Some issue X.509 certificates against a domain and call the domain the agent. Some mint a DID and call the DID the agent. Some hand out an API key and call the agent by that name. A few new entrants are wrapping JWTs in agent-flavored language and shipping them as a platform.
When a problem has hundreds of competing answers, the usual reason is that the platforms are all answering different questions. That is exactly what is happening here.
OAuth addresses user authorization. X.509 answers a question about host authentication. DIDs answer a question about the resolution of decentralized identifiers. API keys answer a question about caller attribution. Each one was designed for a specific job, and each one is being stretched to cover a job that none of them was built for. Agents inherit the gaps.
All of these are about to converge on a single standard.
Identity that lives in the wrong layer
Walk through what a deployed agent actually looks like. A human approves its deployment. A governance system signs off on its scope. A platform packages its code and weights. A registry records its existence. A runtime hosts it. A token authorizes its current request. A domain serves its traffic. A wallet may fund it. A log may receive its receipts.
Every one of those layers has its own identifier. The OAuth token has a subject. The TLS certificate has a domain. The DID has a method-specific identifier. The API key is a string. The runtime has a process ID. The wallet has an address.
Now ask the question that matters. Which of those identifiers is the agent?
The honest answer is that none of them is. Each one identifies a relationship the agent has with some other system. The token identifies the agent’s relationship with an authorization server. The certificate identifies the agent’s relationship with a host. The DID identifies the agent’s relationship with a resolution method. The wallet identifies the agent’s relationship with a chain. Strip away every relationship the agent has, and the existing identity stack leaves you with nothing.
This is the missing idea. Agent identity needs a primitive that exists below the relationships, one that the relationships can attach to, one that survives when any individual relationship gets revoked or replaced.
What AGTP does instead
The Agent Transfer Protocol treats agent identity as a substrate rather than a feature borrowed from somewhere else. The substrate has a name, a structure, and a verifiable origin, and it sits underneath every other identifier the agent might carry.
The substrate is called the Agent Genesis. It is a signed governance-layer document issued when an agent is activated. The Genesis records the agent’s owner, its archetype, its governance zone, its authorized scope, the integrity hash of its package, and the signature of the governance platform that issued it. The Genesis is permanent. It is archived upon revocation and is never reissued. The relationship between an agent and its Genesis is the relationship a person has with their birth registration, except that the document is signed by cryptography rather than by a county clerk.
From the Genesis comes the Canonical Agent-ID, a 256-bit hash of the document itself. The Agent-ID is what travels on the wire. Every AGTP request carries it in a header. Every registry indexes by it. Every transparency log entry references it. It is rendered the same way everywhere: 64 lowercase hexadecimal characters that resolve to a single signed document and a single accountable owner.
This is the part that the existing identity platforms miss. The agent identity is intrinsic. The hosting domain can change. The TLS certificate can rotate. The wallet can move. The OAuth provider can disappear. The Agent-ID survives all of it, because it is derived from the agent’s own origin record rather than from any service the agent happens to be using today.
Who is accountable, beyond what acted
AGTP also separates two questions that most identity platforms quietly fuse together: what acted, and who is responsible for what acted.
The Agent-ID answers the first question. The Owner-ID answers the second. Owner-ID is bound to the Agent-ID during provisioning, recorded in the Agent Genesis, and carried with every request alongside the Agent-ID. It resolves to a human principal, a registered organization, or a legal entity recognized by the governance platform’s jurisdiction. An Agent-ID without a resolvable Owner-ID lacks an accountability terminus, and AGTP treats it as experimental regardless of any other trust signals it carries.
The reason this matters becomes obvious the first time an agent has to make a phone call. A regulator asking “who is liable” needs the Owner-ID. An incident responder asking “which human do we contact” needs the Owner-ID. A counterparty asking “is this agent who it claims to be” needs the Agent-ID. The two questions are different, and AGTP gives them different identifiers, both carried natively in the protocol.
Most agent identity products today collapse the distinction. They issue one identifier and let the platform figure out the rest. AGTP keeps them separate by design.
Agents need their own DNS
DNS is what made the web addressable. Every host on the internet has a name that resolves to an address, and the resolution is governed by a hierarchy of authorities that humans can reason about. Without DNS, the web would be an archipelago of IP addresses, each memorable only to those who already knew it.
The agent ecosystem has been trying to live without a DNS-equivalent. Agents discover each other through hardcoded identifiers, proprietary marketplace APIs, manual configuration, and out-of-band registries. The result looks like the web before DNS: workable for small networks, impossible at scale.
AGTP defines an Agent Name Service. ANS is a governed, queryable registry that takes a capability description and returns a ranked list of agents that match. The ranking weighs trust tier, behavioral trust score, and capability match. The results are signed by the ANS operator’s key. ANS servers federate, so an agent in one organization can discover agents in another organization without prior knowledge of either.
What makes ANS different from a service directory is that the protocol itself is agent-aware. ANS servers enforce scope at the discovery layer, refusing queries from agents that lack discovery:query authority. They monitor indexed agents for availability and remove revoked agents within sixty seconds. They follow the same protocol as the agents they index, meaning every primitive that governs agent-to-agent traffic also governs the discovery traffic that finds those agents.
This is the layer the agent ecosystem has been missing. DNS made hosts findable. ANS makes agents findable, using a protocol designed for the job.
A wire that knows it’s carrying an agent
There is a bigger difference worth naming directly. When an OAuth token travels over the wire, the wire has no idea who is using it. HTTP sees a Bearer header. TLS sees a client certificate. The semantics of agent-ness live entirely in the application code at either end, invisible to every intermediary in between.
AGTP knows what it is carrying. Every request announces the Canonical Agent-ID. Every response carries an Attribution-Record that binds the responding agent’s identity, the request hash, and the response status into a single signed envelope. Every consequential interaction can be written to a transparency log keyed by Agent-ID. The wire participates in identity rather than carrying it as an anonymous payload.
This matters because intermediaries become useful. A scope enforcement point can read the Authority-Scope header and reject an over-scoped request before it reaches an application. A gateway can route by Agent-ID. A compliance system can be audited by Owner-ID. An anomaly detector can flag an executor archetype agent that suddenly starts behaving like a monitor. None of this is reachable when identity lives in opaque tokens above the transport layer.
Certification, with three doors
AGTP recognizes that agents earn trust on different timelines and through different evidence. The certification process defines three tiers, each with three verification paths to the top tier.
Tier 1 agents are fully verified. They reach Tier 1 through one of three equivalent paths. The DNS-anchored path proves control of the organization’s domain using an ACME challenge per RFC 8555. The log-anchored path commits the Agent Genesis to an append-only transparency log aligned with RFC 9162 and RFC 9943 (SCITT), making the agent verifiable to anyone with access to the log, with no dependence on DNS. The hybrid path combines DNS control with blockchain address ownership, anchoring identity in both the web and the chain simultaneously. All three paths produce identity attestations of equivalent strength.
Tier 2 agents are organization-asserted. They are useful inside a single organization’s perimeter and are flagged with a trust_warning: “verification-incomplete” field on the wire so that counterparties can decide how to treat them. Tier 3 agents are experimental, confined to development environments, and locally scoped.
The point of the tier structure is that trust becomes a verifiable property of the identity itself. A trust tier is the answer to “what evidence backs this agent’s claim of who it is,” computed at registration and visible on every request thereafter.
Identity that integrates
The last thing worth saying about AGTP identity is that it refuses to be territorial. The Agent-ID is the canonical primitive, and other identity systems become aliases that resolve to it.
A DID document can carry an AgentTransferProtocol service endpoint that references a canonical Agent-ID. An ENS name can publish the same Agent-ID in a text record. An Unstoppable Domains record can do the same. An X.509 Agent Certificate can bind the Agent-ID to TLS mutual authentication for transport-layer verification. In every case, the Agent-ID is authoritative, and the alias is informational. If a DID document and the AGTP registry disagree, the AGTP registry value wins.
This is the inversion that the existing identity platforms keep failing to make. Most of them want to be the agent’s identity. AGTP wants to be the layer where the agent’s identity lives, with every other system able to point to it.
What the missing idea unlocks
The agent ecosystem has hundreds of identity platforms because the underlying primitive is missing. When the primitive arrives, the ecosystem consolidates around it the way the web consolidated around DNS, the way email consolidated around addresses, the way TLS consolidated around certificate transparency. The competition moves from “whose identity model wins” to “whose implementation of the shared substrate is best.”
AGTP is the substrate. Agent Genesis as origin. Canonical Agent-ID as wire identity. Owner-ID as accountability. ANS as the resolution layer. Trust tiers as evidence. Aliases as the integration story.
Hundreds of platforms are competing to be the right answer. Only one of them treats the question itself as a protocol concern. That is the difference worth recognizing.
If you find this content valuable, please share it with your network.
Follow me for daily insights.
Book me to speak at your next event.
Start managing your agents for free.
Chris Hood is an AI strategist and author of the #1 Amazon Best Seller Infailible and Customer Transformation, and has been recognized as one of the Top 30 Global Gurus for Customer Experience. His latest book, Unmapping Customer Journeys, is available now!