Every identity vendor in the IAM space ships the same architecture. A directory holds the records. Each entity gets an identifier assigned by the directory. Authentication produces a token. Authorization is policy attached to the identifier. Audit is application-layer logging that references the identifier. This architecture has run human identity for 30 years and workload identity for 10 years. It is what every IAM vendor is now retrofitting for agents.
The retrofit will fail, and the reasons are structural.
The IAM industry built its tools for a problem shape that fails to match agents. Humans show up at workstations with phones in their pockets. Workloads run inside organizational perimeters with metadata services nearby. Agents do something different. They cross organizational boundaries. They outlive their operators. They act on behalf of multiple principals at once. They negotiate contracts at runtime. They get retrained, transferred, federated, and audited across regulatory regimes. The directory-and-token model was never built to handle any of this, and asking it now produces the same kind of failure mode that HTTP produces when stretched into agent transport. The substrate is wrong, and the fixes that get layered on top create new attack surfaces faster than they close the old ones.
AGTP is a different architecture. The identifier is content-derived rather than assigned. The identity is a structured set of artifacts rather than a row in a database. The protocol itself enforces it rather than leaving it to applications. This article walks through what those choices mean in practice, why they matter specifically for agents, and why no IAM vendor has shipped them.
An ID is the smallest part of identity
The first thing to be honest about is that “identity” in the IAM industry has become a synonym for “identifier.” The product is an ID and a way to authenticate that someone is allowed to use it. The Okta directory holds your user record. The Entra ID directory holds your principal. The SailPoint platform manages who has access to what. Every conversation about identity collapses into a conversation about IDs.
For humans and workloads, this collapse is mostly fine. The human’s identity outside the workplace is somebody else’s problem. The workload’s identity is short-lived and operator-defined. The directory’s view is sufficient for the directory’s purpose.
For agents, the collapse breaks. An agent’s identity must have sufficient structure to answer questions the IAM industry has never asked.
What is the agent’s origin? Who issued it into existence and signed off on its being permitted to operate? The Genesis answers this. It is a signed document recording the agent’s archetype, the registrar that issued it, the owner accountable for it, the activation timestamp, and the verification path that backs the registration.
What is the agent’s current operational state? The Manifest answers this. It is a separately resolvable document declaring the agent’s capabilities, methods, scope acceptance, policies, and current lifecycle state. The Manifest can be refreshed independently of the Genesis as the agent’s operational profile evolves.
What has the agent done? The Attribution Log answers this. Every consequential interaction produces a signed Attribution-Record that names the agent, the principal who authorized the action, the counterparty, and the result. The records flow into append-only transparency logs aligned with RFC 9162 and SCITT (RFC 9943).
What has been verified about the agent? The Trust Tier answers this. Tier 1 means full cryptographic verification through one of three documented paths. Tier 2 means organizational assertion. Tier 3 means experimental. The tier travels with the Manifest and is visible to every counterparty.
How has the agent behaved? The Behavioral Trust Score answers this. It is computed from the Attribution Log activity, signed by ANS operators, and surfaced in discovery responses. The score is no vendor’s proprietary risk number. It is a verifiable summary of the agent’s recorded behavior across the network.
Where did the agent come from? The Genesis Lineage answers this. As the agent’s underlying model gets retrained, its owner changes, or its governance zone evolves, the lineage chain records each transition. The lineage is the provenance document that lets a regulator three years from now reconstruct what happened.
What can the agent currently do? The Authority-Scope, declared for every request and bound to the Agent-ID through certificate commitments, answers this question. The scope is more than a directory entry. It is a wire-level claim the protocol enforces before the application runs.
Eight different artifacts, each answering a different question. The Agent-ID is the handle into all of them. It is the smallest part of identity rather than the whole. Treating the ID as identity, as the IAM industry has been doing for thirty years, leaves the other seven parts in vendor-proprietary formats or nowhere at all.
Why the ID has to be canonical
The IAM industry assigns IDs. The directory operator decides what your user object’s ID is, what its GUID looks like, what its DN string contains. The ID is whatever the directory says it is. Change directories, and the ID changes. Lose the directory, and the ID is gone. Trust the directory, and the ID is trustworthy. Distrust the directory, and the ID is nothing.
For humans, this is acceptable because humans have other forms of identity that outlive any single directory. Social security numbers, passports, biometrics. The IAM directory is one view of the human, and the human persists across many such views.
For agents, this is unacceptable. The directory’s view IS the agent. Lose the directory, lose the agent. Change operator policy, change the agent’s identity. The directory is a single point of failure for the agent’s existence.
AGTP takes the opposite approach. The Agent-ID is the SHA-256 hash of the canonical bytes of the Agent Genesis document. The identifier exists because the document exists. Nobody assigns it. Nobody can change it without changing the document. Anyone with a copy of the Genesis can verify the identifier by hashing.
This is the same primitive that Bitcoin uses for addresses, that Git uses for commits, that IPFS uses for content. Content-derived identifiers have specific properties that assigned identifiers lack.
Self-certifying. Verification works by hashing. The identifier and the content are inseparable. If somebody hands you an Agent-ID and a Genesis, you can verify the binding in milliseconds without contacting any third party.
Tamper-evident. Any change to the Genesis produces a different Agent-ID. Forgery requires either solving the hash function (computationally infeasible) or producing a new Genesis (which is a new agent).
Portable. The identifier travels with the document. It has no binding to a database, a host, or a domain. Moving an agent across infrastructures preserves its identifier exactly.
Operator-independent. No issuing authority can revoke or reassign an Agent-ID. The identifier exists for as long as the Genesis exists. Registrars federate to preserve the Genesis attestations, but no single registrar holds the identifier in trust.
Globally unique without coordination. 256 bits of cryptographic hash gives collision resistance well beyond any plausible population of agents. Two different Genesis documents will never produce the same Agent-ID, regardless of who issued them or where they live.
Surveillance-resistant. The identifier reveals nothing about the issuing authority. It is just bytes. An observer who sees an Agent-ID on the wire learns nothing about which registrar produced it, which jurisdiction it was registered in, or who owns it. All of that information lives in the Genesis, available only to parties the agent chooses to share it with.
These are properties the IAM industry has never needed for humans or workloads, and properties no major IAM vendor ships for agents.
What AGTP does that nobody else does
Okta has agent support that wraps an OAuth client into a service principal. Microsoft Entra has agent identity that surfaces in the Azure portal as a managed identity. Auth0 offers machine-to-machine grants that can be repurposed as agent credentials. Each one extends a primitive that was built for a different actor type. None of them ships the architecture agents actually need.
Six specific things AGTP does that no major IAM platform does:
Content-derived canonical identifiers. The Agent-ID is a hash of the Genesis. No vendor in the IAM space ships content-derived agent identifiers. Everyone assigns IDs from a directory.
Wire-level identity headers. Agent-ID, Owner-ID, and Authority-Scope are mandatory headers on every AGTP request. The protocol enforces verification before the application runs. No IAM vendor pushes identity into the transport. They keep it at the application layer where the directory can stay in charge.
Three separate principals. Agent-ID, Owner-ID, and acting principal serve as three distinct identifiers that answer three different questions: what acted, who is responsible, and who authorized. The IAM industry collapses these into a single identity record, destroying the accountability chain a regulator actually needs.
Signed Attribution-Records to transparency logs. Audit is a protocol output rather than an application convention. The records are structured the same way across every implementation and flow into logs whose integrity is cryptographically protected. The IAM industry’s audit story is per-vendor logging that requires bilateral integration to compose across organizations.
Trust tiers with explicit verification paths. Tier 1 means full cryptographic verification through DNS-anchored, log-anchored, or hybrid trust paths. The tier is verifiable by anyone with access to the public trust roots. The IAM industry has no equivalent. Verification depth is whatever the vendor says it is.
Federated, scope-enforced, signed discovery. ANS makes agents findable across organizations through a protocol-native discovery layer. Results are signed, ranked, scope-enforced, and federated while preserving provenance. The IAM industry’s discovery story is a vendor-controlled marketplace accessed through proprietary APIs, with no cross-vendor compatibility.
Protocol-composable identity. The Agent-ID, Owner-ID, and Authority-Scope ride alongside existing standards instead of replacing them. An AGTP identity passes straight through MCP, OAuth, and A2A without being re-minted at each boundary, so the same verifiable principal survives every hop of an agent's call chain. The IAM industry treats each protocol as its own island, issuing a fresh token and a fresh identity at every handoff, which severs the accountability chain at exactly the seams where cross-system attribution matters most.
Each of these is a deliberate architectural commitment that the IAM industry would have to rebuild its products to deliver. The retrofit approach (extend OAuth, extend service principals, extend the directory) cannot reach any of them, because the substrate is wrong.
The structural difference
The IAM industry treats identity as a directory problem. Their core competency is running directories, attaching policies to directory entries, and producing tokens that reference those entries. Everything they build assumes the directory is the source of truth.
AGTP treats identity as a protocol problem. The core competency is moving signed artifacts between agents in a way that allows each recipient to independently verify the artifacts. The protocol is the source of truth, and any directory built on top of it is an index to verifiable claims that exist outside the directory.
This is the same kind of structural difference that distinguished SMTP from proprietary mail systems in the early days of networking. The proprietary systems held mail in their own databases. SMTP carried mail as self-contained envelopes that any compliant server could read. The proprietary systems lost. The architecture that put the content on the wire won.
The same pattern will play out for agent identity. The IAM industry holds the records in its directories. AGTP carries the content as self-contained, content-addressed, signed artifacts. Vendors that adopt the AGTP substrate can continue to run directories as indexes into the verifiable substrate. Vendors that store their identities exclusively in proprietary directories are running the proprietary-mail-system playbook in a network where the protocol wins.
The substrate question gets answered the same way every time. The substrate that makes the content verifiable without the directory’s permission becomes the substrate. AGTP made that choice for agents. The rest of the industry is still answering with directories.
What this means for the field
Agent identity is being built right now. The choices being made today will compound over the next decade, much as the choice between SMTP and proprietary mail compounded over the eighties and nineties. Vendors building on directory primitives will produce systems that work inside their products and fragment at every boundary. Vendors building on canonical identifiers and protocol-level verification will produce systems that compose across operators, jurisdictions, and timescales.
The IAM industry is large, well-funded, and committed to the directory model. The directory model worked for humans. It worked for workloads. It will continue to work for those use cases. For agents, the directory is the wrong shape, and no amount of retrofitting changes that.
The Agent-ID must be canonical because the entity must outlive the directory. The Genesis, Manifest, Attribution Log, Trust Tier, Behavioral Score, and Lineage must all be first-class because agent identity is a richer artifact than user identity. The protocol must carry the verification because the application layer cannot do so consistently across organizations.
These are structural commitments. AGTP made them. The IAM industry will catch up or be replaced, just as every infrastructure layer does when a new substrate proves out.
Top comments (0)