Register at /issue. The identifier is part of what you sign, and you can look it up afterwards at /verify.

Glossary · Identity

The AgenID identifier: a permanent name for an AI agent

Updated 2026-09-23

Every registered agent has exactly one identifier, of the form agenid:01J8Z3K3F2QZ9X6V7R4T8N2W5Y (an illustrative value). It is the handle everything else hangs from: the manifest, the operator's proof, any verification assertions and the public Verification Card.

The identifier deliberately carries no meaning. It does not encode the operator, the platform or the agent's name, so none of those can be read into it or spoofed through it.

Definition

An AgenID identifier is the permanent, non-semantic name of an AI agent in the AgenID protocol, written agenid: followed by a 26-character ULID. It is assigned once, never reissued and never re-keyed when the agent changes platform.

Also known as: agent_id

How it works in AgenID

The grammar is fixed: ^agenid:[0-9A-HJKMNP-TV-Z]{26}$, where the tail is a ULID in Crockford base32. Registration checks uniqueness before commit. Related namespaces follow the same pattern: keys are agenid:key:<ULID> with their own ULID, and authorities are agenid:authority:<node>. Resolve any agent at https://www.agenid.com/a/<agenid> for the Verification Card, or ask for JSON to get the resolution envelope.

The same identifier appears everywhere the agent is presented: on the Verification Card, in the JSON envelope, in the badge embed and in the shield image at /badge/<agenid>/shield.svg. A relying party that records it can resolve the agent again later and see the same subject, whatever platform the agent was using at the time.

Why it matters

Platform IDs belong to platforms. An agent that moves between voice providers would lose its history if its identity were the provider's ID. The specification forbids using a platform-native ID as, or inside, an AgenID identifier, and a deployment gets its own separate identifier, so the agent's identity survives migration. The agent delegation scenario shows why a stable handle matters when agents act for each other.

What it does not mean

Holding an identifier says nothing about trustworthiness and nothing about what the agent is allowed to do. It names the subject; the signed manifest and any assertions are what a verifier evaluates. Malformed identifiers are rejected with invalid_identifier rather than guessed at.

Frequently asked questions

Can an identifier be transferred or reused?

No. It is immutable for the life of the record and is never reissued to another agent.

Where do I get one?

Is the identifier secret?

No. It is public by design. Security rests on the operator's private key, not on the identifier being hidden.

What agenid.com issues today

The reference deployment at agenid.com issues DECLARED and L1_REGISTERED only. L2_DOMAIN_VERIFIED and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved by the specification and is not issuable at all.

Identity is not permission

Which agent is acting and who declared it is one question. What that agent is allowed to do is another, and it stays with the party on the other side and with the operator. Protocol v1.1.1 defines no signed authorization object.

Sources

AgenID protocol specification (public repository)

Agent-to-agent delegation

Give your agent an identity

Register an agent in the browser — the signing key is generated on your device and never sent to AgenID — or resolve an existing AgenID and re-check its signature yourself.