Protocol v1.1.1 · Locked · MIT
AI agents need an identity.
AgenID gives every AI agent a permanent, portable identity that people, businesses, and other AI agents can independently verify.
Open protocol · Cryptographically verifiable · Platform independent
Who are you?
An AI agent shows up. Nothing about it says who operates it, or whether it's the same agent tomorrow.
Agents act. Nothing identifies them.
A production AI agent can book, pay, escalate, and speak for an organization — but it usually has no identity that outlives its session token or API key. When it moves platforms, changes configuration, or gets rebuilt, any accountability attached to it disappears with it. There is nothing permanent to point to.
Any claim can be made. Few can be checked.
A support agent can claim to represent your bank. A vendor can claim its bot is “verified” with nothing behind the word. Without a cryptographic proof that a specific party made a specific claim about a specific agent, verification is just a label — and labels can be forged, copied, or asserted by anyone.
- Who operates it?
- Is the identity persistent?
- What does it claim to do?
- What has actually been verified?
- Can another system verify it?
A permanent, portable identity that isn’t tied to one AI platform.
Portable Identity
Every agent gets an agenid:<ULID> that never changes — not when it moves platforms, not when its config changes, not when a deployment is retired. Revoked identities stay on record forever.
Cryptographic Proofs
Operator manifests and authority assertions are bound by pure Ed25519 signatures over RFC 8785 canonical bytes. Anyone can re-verify offline, without trusting AgenID's database.
Machine-to-Machine
The same URL answers a browser with a verification card and a program with the canonical JSON envelope. An agent can ask another agent who it is — and check the signed answer before it transacts.
Identity lifecycle.
A Deployment (one platform-scoped run of an Agent) is bound to the Agent by agent_id but never mutates it: retiring a deployment or migrating platforms creates a new deployment under the same permanent identity — accountability survives the move.
Cryptography proves signatures. It does not prove behavior.
None of these three states is ever inferred from another. That rule is enforced by key role at verification time, not by convention.
Proven, by signature
- · A specific operator key signed a specific manifest, at a specific digest (ManifestProof).
- · A specific authority key signed a specific claim, against specific evidence, for a specific manifest version and validity window (VerificationAssertion).
- · The signature is over RFC 8785 canonical bytes — reproducible by any independent implementation.
- · A tampered payload, wrong key, or wrong key role (operator signing an assertion, or vice versa) fails verification, not just convention.
Not proven — by design or not yet built
- · Verification ≠ compliance. A VERIFIED claim is bound to what its evidence type actually checked (domain control, org identity, a deployment sample) — never a general safety or legal guarantee.
- · L5 (L5_CONTINUOUSLY_MONITORED) is a reserved name only. No continuous-integrity claim exists in v1.1.1 — it cannot be issued.
- · AUTHORIZED (what an agent is permitted to do) is reserved for protocol v1.2. No signed object for it exists yet.
- · The production root authority key has not completed its HSM ceremony. The verification mechanism for trust anchors is fully specified and testable (§9.5) — the root key itself is a pre-launch operational step, not a protocol gap.
Verification levels
| Level | Name | Claim type | Typical evidence | Status |
|---|---|---|---|---|
| L1 | Registered | registration | schema_validation | issuable in v1.1.1 |
| L2 | Domain Verified | domain_control | dns_txt_challenge / http_wellknown_challenge | issuable in v1.1.1 |
| L3 | Organization Verified | organization_identity | business_registry_match / document_review | issuable in v1.1.1 |
| L4 | Deployment Verified | deployment_conformance | deployment_sample_review | issuable in v1.1.1 |
| L5 | Continuously Monitored | — | — | reserved name · not issuable |
Who is this AI agent?
Paste any agenid:<ULID> below. This calls the live registry, not a mock — an unregistered identifier returns a clean “not found,” not a fabricated result.
No agent yet? Register one to get an identifier you can resolve here.
Manifest to verified signature — every step reproducible.
RFC 8785 JSON Canonicalization Scheme (JCS) — signing_input = JCS(signed_object minus “signature”). The $schema field is part of the signed bytes.
Pure Ed25519 (RFC 8032) — the exact canonical bytes go to Ed25519 directly. No Ed25519ph, no external pre-hash. The only SHA-256 in the protocol is the manifest_digest data value, bound by the signature, not what is signed.
@agenid/core gives you identifiers, RFC 8785 canonicalization, the normative schemas, and the Ed25519 proof engine — the same code that passes the specification's deterministic test vectors byte-for-byte.
<script src="https://agenid.com/badge.js" data-agent="agenid:01J8Z3K3F2QZ9X6V7R4T8N2W5Y"></script>Renders the current verification level, live — a suspended or revoked identity changes everywhere it's embedded. The badge is the human-facing UI; the signed record underneath is what actually carries trust.
$ ▍
One URL, two representations.
GET /a/<agenid> answers a browser with the verification card UI and answers a request sent with Accept: application/json with the raw resolution envelope — manifest, proof, assertions, and key-discovery pointers, ready for a program or another agent to parse and re-verify before it transacts.
@agenid/mcp-server puts that same resolution and verification behind a stdio MCP tool — an agent running in Claude Desktop, Cursor, Windsurf, or a custom MCP client can call resolve_agent_identity and verify_agent_manifest directly, no HTTP client required.
The registry is for discovery, not trust.
AgenID's registry helps you find a manifest and its proofs. It is never the thing you have to trust: every proof is a signature over canonical JSON that you can re-verify yourself, offline, with any RFC 8785 + Ed25519 implementation — including one that shares no code with AgenID's own. The independent conformance suite exists to prove exactly that: the spec holds up when nobody is trusting AgenID's word for it.
Two-path key discovery
A key resolves two independent ways. Both must agree — a verifier that only checks TLS is trusting AgenID's infrastructure; a verifier that also checks the pinned root key is doing independent verification.
The platforms change. The identity doesn't.
AgenID is designed to work across the platforms where AI agents live. An agenid:<ULID> identifies the agent, never the model or platform underneath it — nothing in the protocol references OpenAI, Anthropic, Google, an open-source model, or any specific runtime. The identity survives a change of model provider, agent framework, or hosting infrastructure.
Hover, focus, or tap a platform to see exactly what “compatible” means for it. Every listing here is a technical statement about how an agenid:<ULID> travels through that platform’s existing API surface — never an endorsement, partnership, or shipped adapter.
25 platforms across five layers are listed as Compatible — a technical statement about carrying an identity through each platform's existing, documented API surface. None of them ships AgenID code, none is a partner, and no adapter package exists for any of them. See the full compatibility matrix.
Interoperability is tested, not assumed: the §8 deterministic test vectors — real Ed25519 signatures over RFC 8785 canonical bytes — let any language implementation prove it produces byte-identical output, independent of AgenID's own TypeScript reference implementation.
AI agents are becoming participants.
Human → Agent. Agent → Agent. Agent → API. Agent → Business. Agent → Transaction. As agents take on more of these roles, a persistent, independently verifiable identity stops being optional infrastructure and starts being load-bearing. Why agent identity, and why now →
The spec is the source of truth. Code follows it.
AgenID-protocol/spec is public and MIT-licensed — the protocol specification, five normative JSON Schemas, deterministic test vectors, and a public errata log. Changes to identity, cryptography, serialization, or verification semantics require a published erratum before any implementation follows. Two are on record: a key-identifier URI fix and a number-domain canonicalization rule (E1), and the namespace unification onto a single agenid.com domain (E2) — both applied, both re-verified against regenerated test vectors.
AgenID-protocol/conformance is a separate, public, MIT-licensed test runner with zero AgenID knowledge — 34 of 34 checks pass, verified in CI on every push.
What brings you here?
Developers
SDK, API, MCP server, and docs to attach a verifiable identity to an agent you're building.
Read the Quick StartBusinesses
Give the agents you deploy a permanent identity and accountability trail — and verify agents you didn't build.
Verify an AgentAI Platforms
Identity infrastructure for the agents built on your platform — see what's actually integrated today.
See the EcosystemEnterprise
Verification methodology, key management, and conformance — everything the Trust Center discloses openly.
Open the Trust CenterGet AgenID.
Name your agent and your browser does the rest: it generates an Ed25519 key, signs the operator manifest locally, and registers the public half. You get a resolvable identifier and a Verification Card in about a minute — no account, and no private key ever leaves your machine.
Issues L1_REGISTERED — registered here, operator self-declaration verified. Not a third-party check of the operator, the domain, or the organization.