Protocol v1.1.1 Specification public 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
agenid:01J8Z3K3F2QZ9X6V7R4T8N2W5Y
- Namespace
- agenid:
- Identifier
- 26-character ULID
- Lifetime
- Never reissued or recycled. A record once registered stays resolvable forever.
You can talk to an AI agent. But who is it?
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.
Ask any agent
- Who operates it?
- Is the identity persistent?
- What does it claim to do?
- What has actually been verified?
- Can another system verify it?
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 →
Give every AI agent a permanent identity
A permanent, portable identity that isn’t tied to one AI platform.
- 01
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. An identifier is never reissued or recycled, and a record once registered stays resolvable forever.
agenid:01J… - 02
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.
Ed25519 · RFC 8785 JCS - 03
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.
Machine-readable by default
Identity lifecycle.
- 01Agentagenid:<ULID> minted
- 02Manifestoperator self-declaration
- 03ManifestProofoperator-signed, DECLARED
- 04Authority checks evidenceDNS TXT, org registry, …requires root authority key · not issued today
- 05VerificationAssertionauthority-signed, VERIFIEDrequires root authority key · not issued today
- 06Independent verificationanyone re-checks offline
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.
Verify an agent · live registry
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.
- Registered
- Opens the Verification Card: what the operator declared, and the signature status.
- Not registered
- A clean “not found.” Absence is not a negative finding, and nothing is invented.
No agent yet? Give Your Agent an Identity → Or browse the opt-in Agent Directory.
From declaration to verification
Cryptography proves signatures. It does not prove behavior.
Issued by AgenID today
Defined and issued are different claims. L2, L3 and L4 are defined in v1.1.1 and a conforming implementation could issue them — but every one of them is a VerificationAssertion signed by the root authority key, and that key has not been generated yet. The only level agenid.com issues today is L1_REGISTERED. Nothing on this deployment can raise an identity above it, and no page here should be read as offering L2, L3 or L4 now.
| Level | Name | Claim type | Typical evidence | Defined in v1.1.1 | Issued by AgenID today |
|---|---|---|---|---|---|
| L1 | Registered | registration | schema_validation | defined | issued today |
| L2 | Domain Verified | domain_control | dns_txt_challenge / http_wellknown_challenge | defined | not issued |
| L3 | Organization Verified | organization_identity | business_registry_match / document_review | defined | not issued |
| L4 | Deployment Verified | deployment_conformance | deployment_sample_review | defined | not issued |
| L5 | Continuously Monitored | — | — | reserved name only | not issued |
What is proven — and what is not.
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 not part of v1.1.1. A signed authorization object exists in @agenid/core as v1.2-DRAFT — draft, not normative, not ratified, and not issuable. Nothing on this deployment issues or evaluates an authorization claim, and no agent here carries one.
- 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. Until it is done, no VerificationAssertion can be signed, so L2, L3 and L4 are defined but not issued here.
For developers
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/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.
$ ▍
Signature chain.
- Manifestcanonical JSON
- RFC 8785 JCSdeterministic bytes
- SHA-256manifest_digest
- Signed objectManifestProof / Assertion
- Ed25519 (pure)RFC 8032, no pre-hash
- Verify()anyone, offline
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.
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.
Put your agent’s identity where people can see it.
<script src="https://agenid.com/badge.js" data-agent="agenid:01J8Z3K3F2QZ9X6V7R4T8N2W5Y"></script>Re-resolves from the registry every time it renders, so it always shows whatever the registry currently reports for that identifier — it is never a static image of a past result. The badge is the human-facing UI; the signed record underneath is what actually carries trust. The protocol defines agent status transitions (CHANGED, STALE, SUSPENDED, REVOKED) and the badge renders them, but no write path on this deployment sets them yet — every registered agent is ACTIVE, and there is no revocation flow today.
What the badge can say
AI can verify AI.
@agenid/mcp-server puts that same resolution and verification behind a stdio MCP tool — an agent running in any MCP client can call resolve_agent_identity and verify_agent_manifest directly, no HTTP client required.
Not yet installable. @agenid/mcp-server is not published to npm — neither it nor @agenid/core nor @agenid/cli has been published. The brief below documents the integration pattern and the tool surface; running the server today means building it from the public monorepo source. Nothing here is available to install from npm.
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.
Open protocol · Open-source specification · Machine-readable · Platform independent · Cryptographically verifiable · Independent verification
Built for developers. Designed for everyone.
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 Center
The agent ecosystem
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 it means for it. Every listing here is a technical statement about how an agenid:<ULID> travels through that platform’s existing API surface. Appearing in this diagram is not an endorsement, a partnership, or a shipped adapter — each of those is a separate claim, and the panel says which ones apply.
27 platforms listed across 6 layers · 27 Compatible · 0 verified integrations · 0 partners. 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.
Give your AI agent an identity
Get 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.
Before you register
Questions a careful operator asks.
- Does my private key leave my machine?
- No. Your browser generates the Ed25519 key and signs the operator manifest locally, then registers only the public half. There is no account to create.
- What level will my agent get?
- L1_REGISTERED: registered here, operator self-declaration verified. L2, L3 and L4 are defined in v1.1.1 but not issued, because the root authority key has not been generated yet.
- Do I have to trust AgenID's database?
- No. The registry is for discovery, not trust. Every proof is a signature over RFC 8785 canonical bytes that anyone can re-verify offline with any Ed25519 implementation.
- Can I install the SDK from npm?
- Not yet. @agenid/core, @agenid/cli and @agenid/mcp-server are not published to npm. Running them today means building from the public, MIT-licensed monorepo source.
- Are the listed platforms partners?
- No. They are listed as Compatible: a technical statement about carrying an identity through each platform's existing, documented API surface. None ships AgenID code and none is a partner.
- Can an identity be suspended or revoked?
- The protocol defines those status transitions and the badge renders them, but no write path on this deployment sets them yet. Every registered agent is ACTIVE.