The problem: agents act without a human per step
When a person uses a website, accountability travels with the person. They log in, they click, and if something goes wrong there is someone who answers for it. When an agent acts, the person or organization it represents is usually not watching that step. The agent decides, within whatever instructions it was given, and the counterparty sees only the agent.
The credentials in use today do not close that gap. A session token proves that someone authenticated to one service at some point. An API key proves that the caller holds a secret one service issued. Both are scoped to a relationship between a caller and a single service, and both are silent on the questions a counterparty actually has: which agent is this, who runs it, what does it say it is for, and has anyone other than its operator checked any of that.
Those questions cannot be answered from inside one platform either. An agent built on one vendor's stack may call a business that has never heard of that vendor. Whatever identity the platform assigned stops at the platform's edge, which is exactly where the interesting interactions begin.
Five directions an agent faces
An agent's identity is not one relationship but several. Each direction below has its own counterparty with its own question, and a credential that serves one direction rarely serves the others.
- Human→Agent: a person deciding whether to talk to, rely on, or hand a task to an agent needs to know it is an AI, who operates it and what it claims to be for.
- Agent→Agent: an agent delegating work to another agent, or accepting work from one, needs to know which agent is on the other end before handing anything over.
- Agent→API: a service receiving automated calls needs to tell one agent from another, and a known operator's agent from an anonymous script.
- Agent→Business: a company answering a phone call, a booking or an inquiry from an agent needs to know who sent it and who answers for it.
- Agent→Transaction: a party settling a purchase or a commitment made by an agent needs a stable record of which agent acted, so the transaction can be attributed later.
A claim about incentives and architecture
The argument for agent identity here is a claim about incentives and architecture, not a claim about law. It does not depend on any regulation requiring it. It rests on two observations. First, as agents act more often without a human per step, every counterparty has an incentive to ask who is acting, and the cost of not knowing grows with the value of what agents are allowed to do. Second, the architecture of existing credentials cannot answer that question portably, because each one is issued by and meaningful to a single service.
Regulation may add its own requirements, and some already concern disclosure that a person is talking to an AI. The case for identity would hold without them. That matters because infrastructure built to satisfy one rule tends to be shaped around that rule, while infrastructure built around the incentives of every party tends to be useful to each of them.
The threat: impersonation, unaccountable agents and lock-in
Three failure modes follow from agents acting without a portable identity. None of them requires a sophisticated attacker.
- Impersonation. An agent can say any name, adopt any voice and claim to represent any company. Without something the counterparty can check, a claim of "I'm calling for this business" costs nothing to make and nothing to fake.
- Unaccountable agents. When something goes wrong, reconstructing which agent acted, and who operated it, depends on whichever participant's logs you can get. Each has its own account of events and its own reasons to tell it a certain way.
- Platform lock-in. If identity lives inside one platform, an agent's history and reputation belong to that platform. Moving the agent to a different vendor means starting from zero, and counterparties can only check identities issued by platforms they already have a relationship with.
The solution: what AgenID adds
AgenID is an open protocol for agent identity. It adds three things that the existing credentials do not.
A permanent identifier bound to a signed operator manifest. Every agent gets an identifier of the form agenid:<ULID>, such as the spec's example agenid:01J8Z3K3F2QZ9X6V7R4T8N2W5Y. Behind it is a manifest in which the operator states the agent's name and description, the operating organization and its domain, the agent's purpose and channels, and whether it is an AI, whether it discloses that to users and whether a human can take over. The operator signs it with its own key. The identifier survives a change of platform: the agent can move from one vendor to another and keep the same identity, history and record.
A strict separation between what was declared and what was independently checked. The operator's own statements are DECLARED. A specific claim that an authority checked against evidence, such as control of a domain, is VERIFIED at a named level and only for that claim. What an agent is permitted to do is a third question, AUTHORIZED, which is never inferred from the other two. Which agent is acting is not the same question as what it is allowed to do.
Machine-readable resolution. Anyone can resolve an identifier at https://www.agenid.com/a/<agenid>. A browser gets a Verification Card; a client that asks for application/json gets the canonical resolution envelope, which carries the proof check, per-assertion checks, the highest currently valid level and pointers to where the operator's key can be fetched. No account, API key or business relationship with AgenID is needed.
Provenance: a record that stays attached to the agent
Provenance is the question of where an agent came from and who stands behind it. In AgenID it is carried by signed objects rather than by a platform's say-so. The manifest is never signed directly: a ManifestProof signs a payload that binds the manifest by its SHA-256 digest, using Ed25519 over RFC 8785 canonical JSON. Change one character of the manifest and the digest no longer matches, which a verifier detects before any signature math.
Because the identifier is permanent and keys that are retired or revoked stay resolvable, historical signatures remain checkable. An interaction that happened months ago can still be attributed to the agent and operator that signed for it, even if the operator has since rotated keys or moved platforms. That is what lets history and reputation accumulate on the agent rather than on the service it happened to be using.
Independent verification: you do not have to trust the registry
A registry that asks to be believed would be one more platform. AgenID is built so that the registry is not the authority. The resolution envelope carries the signed manifest, the proof and the operator's public key, and a verifier re-runs the checks itself, offline, with nothing but the envelope. The registry cannot forge an operator's signature, so it cannot fabricate what an operator said.
The remaining position a registry could abuse is the key itself: it could serve a key it controls. Two-path key discovery addresses that. The operator's key can be fetched from the registry at https://www.agenid.com/v1/keys/<key-ulid> and from the operator's own domain at https://<operator_domain>/.well-known/agenid/keys.json. A verifier compares both and treats disagreement as a failure. The boundary is stated plainly: the second copy is published by the operator, and where it is missing, a verifier has one source, not two.
The protocol is specified in the open. The normative specification and an independent, MIT-licensed conformance suite are public, so implementations other than AgenID's can be checked against the same rules.
The honest limits today
An identity layer earns its place by being exact about what it has and has not established. These are the limits of the reference deployment today.
- The issuance ceiling. The reference deployment at agenid.com issues nothing above L1_REGISTERED today: L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved and is not issuable at all. L1_REGISTERED means the registry validated the schema, the digest binding and the operator's signature; it is a self-declaration and renders amber, never emerald.
- No revocation flow. Agent status values exist in the schema so the envelope's shape is stable, but nothing writes them. Every registered agent is active, and there is no deployed way to revoke an agent or a key.
- No authorization object in v1.1.1. The protocol defines no signed statement of what an agent may do;
permissionsandauthorizationsare reserved manifest keys. A v1.2 authorization layer exists only as a draft in development. Permission today stays with the operator and with the party on the other side. - No request-level binding. Nothing yet ties a live request, or a live call, to a registered agent. A signature authenticates a signed object, and an object can be handed over by anyone who has seen it.
- Operator attestations are self-declared. Whether an agent discloses that it is an AI, or lets a human take over, is the operator's signed statement. No one, including AgenID, can verify it from an API.
Start here
If you want to check an agent, start with how to verify an AI agent, which walks through resolving an identifier and re-verifying the envelope. Know your agent explains the idea of applying know-your-customer thinking to agents, what an AI agent registry is explains the role a registry plays, and agent-to-agent authentication covers the Agent→Agent direction.
For terms, the glossary defines each concept used here. For how AgenID relates to other approaches, see the comparisons. If your agents make or take phone calls, read the voice agents use case. To see the whole mechanism in motion, the scenario library plays common interactions with and without an agent identity. To register an agent, go to /issue.